opc.three (3/24/2013)
Michael L John (3/21/2013)
I stand corrected.BUT I also stand by the statement because unfortunately poor security seems to be the norm. It seems as if DBA's are so busy with everything else that security is overlooked.
I will amend the statement to be:
"xp_cmdshell CAN be a security risk"
Nope, you had it right the first time!
Leaving xp_cmdshell enabled exposes the system to the option for people in the sysadmin Role to access the server's file system using someone else's credential, namely the SQL Server service account. That leaves a gaping hole in the auditability of a system, which for me constitutes a security exposure and a threat to the system.
I would leave xp_cmdshell disabled and put up every roadblock and auditing option (e.g. Policy Based Management) to keep it disabled, and log attempts to enable it. It's just not worth it. There are so many better options out there than to allow cmd-shell and file system access through your database engine.
He didn't have it right the first time and you know it. If someone get's in as "SA", then it won't matter or even slow down an attacker if it's disabled. Only people with "SA" privs can execute xp_CmdShell directly. People should not be given permissions to execute it directly for any reason. They should only be given privs to execute procs that may contain it.
Turning it off does not increase security in any way, shape, or form. Yeah... having it turned off will slow down an attacker... for about 3 ms.
xp_CmdShell isn't a security risk. Bad security is the only security risk. To think you're safe just because you have xp_CmdShell turned off is like the proverbial ostrich hiding his head. You must have proper security or you will be hacked. Turning off xp_CmdShell is not what proper security is about.
--Jeff Moden
Change is inevitable... Change for the better is not.