Security Advisory 961040 provides mitigations and workarounds for a newly-public post-authentication heap buffer overrun in SQL Server, MSDE, and SQL Express. This blog post goes into more detail about the attack surface for each affected version and the overall risk from this vulnerability.
As listed in the advisory, the following products have the vulnerable code:
- SQL Server 2000
- SQL Server 2005 SP2
- MSDE 2000 (Microsoft SQL Server 2000 Desktop Edition)
- SQL Server 2005 Express Edition
Let’s look at the attack surface for this vulnerability for each platform:
| Product | Requires Auth? | Listens on network? (default) | Runs as (default) | Result of successful exploitation |
|---|---|---|---|---|
| SQL Server 2000 | Yes | Yes | SYSTEM | Any user who can connect to and authenticate to the SQL Server can run code as SYSTEM. |
| SQL Server 2005 SP2 (SP3 is not affected) | Yes | Yes | Service account specified during install | Any user who can connect to and authenticate to the SQL Server can run code as the account specified during installation. |
| MSDE 2000 | Yes | No | SYSTEM | Any local user able to initiate a connection from the local machine running MSDE and authenticate to the SQL instance can run code as SYSTEM. |
| SQL Server 2005 Express | Yes, Builtin\Users granted logon rights by default | No | Network Service | Any local user able to initiate a connection from the local machine running SQL Express and authenticate to the SQL instance can run code as NetworkService. All accounts in Builtin\Users group can authenticate using integrated authentication by default. |
So as the table above shows you have to be authenticated to exploit this vulnerability. Additionally, by default, MSDE 2000 and SQL Server Express 2005, which are redistributed and used by Microsoft and third party applications, can’t be exploited remotely. But it’s important you not ignore this vulnerability for a couple of reasons.
As we said, an unauthenticated attacker cannot exploit this vulnerability directly. However, if an attacker finds a SQL injection vulnerability in the web application connected to your database, he could combine the SQL injection vulnerability with this vulnerability and run code “without authenticating”. Technically, the attacker did authenticate – he just used your compromised web application to authenticate for him. Of course, if an attacker does compromise your web application using SQL injection, he can take a number of actions anyway.
Secondly, remember our October advisory and blog post about service isolation? That vulnerability allowed an attacker to escalate from code running as NetworkService to LocalSystem. Unfortunately, this SQL vulnerability allows any user logged on to a machine running SQL Express to escalate to SYSTEM by leveraging the SQL vulnerability to get to NetworkService and then the service isolation vulnerability to get to SYSTEM.
Thus, we highly encourage you to apply the workaround listed in the security advisory to block this attack and let us know if you have questions.
The affected stored procedure will have no impact for the majority of customers. It is called as a trigger for user modifications during transactional replication with updatable subscriptions. So if your SQL installation does not include replication, the workaround will have no effect other than to protect you from this vulnerability. The workaround will also have no impact on your database installation if you use transaction replication with read-only subscriptions, bi-directional, or peer-to-peer settings. It is only transactional replication with updatable subscriptions that is impacted.
One caveat about the stored procedure workaround: If an attacker connects to the database as sa (or a member of the sysadmin server role), denying execute permission to public will not be effective in stopping them from executing the stored procedure. Of course, if someone has sysadmin rights in SQL Server, they likely have other ways to gain administrator privileges on the server already.
If you don’t want to use the raw SQL in the advisory, you can apply the change using GUI tools. Here are screenshots for the SQL Server Enterprise Manager (SQL 2000) and SQL Server Management Studio (SQL 2005) changing the setting from GRANT to DENY.
Update 12/25/08: Added caveat about workaround being ineffective against attackers connecting as sa / sysadmin
Jonathan Ness and Bruce Dang, SVRD Bloggers
*Posting is provided “AS IS” with no warranties, and confers no rights.*