This post is part of our SQL Server security blog series, 30 SQL Server Security Checks in 30 Days. We’re publishing a new security check every day in the month of June. Visit our sp_CheckSecurity page to learn about our free SQL Server tool you can download and run to check your own server.
It’s rare to see OLE Automation procedures enabled on a SQL Server instance. Most folks aren’t using these specially system procedure because they didn’t have a need to use them, have a compliance requirement that prohibits using them, or they tried using them and had adverse results. As the Microsoft documentation on OLE Automation stored procedures notes:
“Don’t directly or indirectly call Automation procedures from any SQL Server common language runtime (CLR) objects. Doing so can cause SQL Server to crash unexpectedly.”
But if this setting is enabled in any of your SQL Server instances, you need to consider it similarly to the xp_cmdshell setting. By that I mean: this is probably not a problem, but you should try to figure out why the setting is enabled, and how its associated system stored procedures are being used.
What can OLE Automation procedures do?
OLE, which stands for Object Linking and Embedding, allows one application to link objects in another application. This often means interacting with COM objects, which stands for Component Object Model, that are standard software components in many applications.
If the permissions for the service account for SQL Server are high enough, this can become a problem. For example. if the service account is in the local Administrators group, which is not uncommon, the permissions used for executing anything with the OLE Automations are effectively limitless. This includes copying anything, enabling or disabling anything, and even downloading and installing anything.
Who can execute OLE Automation procedures?
Similar to xp_cmdshell though, there are two security considerations you need to know about enabling OLE Automation procedures before freaking out.
- Only principals in the sysadmin role can execute any of these procedures.
- Only principals with CONTROL SERVER permissions can enable or disable this setting.
This generally limits the vulnerability of OLE Automation procedures to principals who already have the highest permissions inside of SQL Server.
Also like the xp_cmdshell setting, we can disable OLE Automation procedure to try to limit the vulnerability, but this a practically worthless step since members of the sysadmin role can re-enable it whenever they want. And there are other options for keeping the setting disabled like Policy-Based Management server-level trigger triggers, but users in the sysadmin role can disable any of these features as well. You could even try revoking permissions on the associated procedures…but, of course a member of the sysadmin group could grant the permissions right back.
That being said, it is possible to explicitly grant execution permissions to principals outside of the sysadmin role by using GRANT EXECUTE on any of the associated stored procedures in the master database. However, if you’re doing that then you’re basically taking extra steps to increase your vulnerability. Please don’t ever think this is a good idea.
What should you do if OLE Automation procedures are enabled?
To see if OLE Automation procedures are enabled, you can run this script.
SELECT value_in_use FROM sys.configurations WHERE [name] = 'Ole Automation Procedures';
Like xp_cmdshell, the threat of OLE Automation procedures isn’t from the setting being enabled, but rather from who has the permissions to execute them. Like so many other security concerns in SQL Server, this vulnerability can be best mitigated by auditing the members of the sysadmin role and constraining it to only necessary principals.
