Problem
The February 2009 Microsoft Security Bulletin included an updated Executive Summary (MS09-004) referring to a highlighted vulnerability with Microsoft SQL Server allowing an authenticated user to escalate privileges to those of SYSTEM, thereby taking control of the server. This vulnerability was originally published (as KB961040) in December 2008. The recently-released third service pack for SQL Server 2005 resolves the issue and systems patched to the SP3 level are not susceptible to the exploitation. The issue for many companies, mine being one, is that this announcement comes so soon after the release of SQL Server 2005 SP3. Approximately forty percent of our SQL Server databases are internally-developed. The remainder of the databases I administer, approximately 500 total, were purchased from outside sources. Typical of third-party software, the vendor response to testing and certifying their products on SQL Server service packs are all across the spectrum of responsiveness. Some certify early, even more have yet to certify on SQL 2005 RTM. What can be done to protect your SQL Server 2005 instances when it is not able to be patched to SP 3? In the case of the current threat there is a workaround.
Solution
First of all let it be clear, the user must be authenticated in order to run the exploit in question. However, a hacker that is able to authenticate to your SQL server instance via SQL Injection from a web application would be able to run this exploit. Secondly, the exploit is issued via passing an unverified parameter into a specific extended stored procedure. The procedure in question is sp_replwritetovarbin.
Information regarding the purpose of sp_replwritetovarbin is hard to come by. According to the Microsoft Security Research & Defense website: “it is called as a trigger for user modifications during transactional replication with updateable subscriptions.” This means that if you are not using Transactional Replication with Updateable Subscriptions you can simply revoke rights for the public role to execute sp_replwritetovarbin. Better yet you can drop the extended stored procedure all together. If the user is able to authenticate to the SQL Server instance as a SysAdmin user they could always add the stored procedure back to the instance, but if they are able to do such then you have larger problems that need to be dealt with.
To revoke the execute permissions from public you can either use SQL Server Management Studio or execute Transact-SQL. This applies to both SQL Server 2000 or SQL Server 2005 (both vulnerable to the exploit.) Both methods are outlined below.
Revoke rights to execute sp_replwritetovarbin via SQL Server Management Studio
- Connect to the SQL instance
- Navigate through the Object Explorer to System Databases/master/Security/Roles/Database Roles.
- Right click on public; select Properties
- Select Securables from the Properties form
- Navigate to the sp_replwritetovarbin extended stored procedure and un-check the granted Execute permission.
What is far easier would be to execute the following Transact-SQL code to accomplish the same results:
-- deny access to public USE [master] GO DENY EXECUTE ON [sys].[sp_replwritetovarbin] TO [public] GO -- if you also want to drop sp_replwritetovarbin extended stored procedure USE [master] GO EXECUTE dbo.sp_dropextendedproc 'sp_replwritetovarbin' GO
Next Steps
- Review the Microsoft Knowledgebase articles to confirm your exposure to the current threat outlined in this tip.
- Consult your vendors and internal development teams. Have they certified their SQL Server databases for the latest service pack?
- If you are unable to patch your SQL instances to SQL 2005 SP3, and are not using Transactional Replication with Updating Subscribers then use the workaround from this tip.
- Information on SQL Server Injection attacks are available from MSSQLTips here.
