What's the scope of the vulnerability?
This is a privilege elevation vulnerability. If an attacker successfully exploited the vulnerability, she could gain complete control of an affected database server. This would give her the ability to take any desired action on the server.
Exploiting the vulnerability would be a daunting challenge:
| • | It only affects SQL Servers that are configured in a mode that Microsoft recommends against using. |
| • | It could only be exploited by a user who already had authorization to access the database |
| • | The attacker would need to time her attack to occur immediately after an administrator performed a database operation. |
What causes the vulnerability?
The vulnerability results because of an error in one particular SQL query method. When SQL Server is configured to operate in Mixed Mode, an attacker could potentially use this query method to gain access to a cached connection that once belonged to an administrator. If the attacker successfully did this, she would gain administrative control over the database server.
What do you mean by a query method?
Query methods are commands provided by SQL Server for interrogating a database. The vulnerability at issue here is only exposed via one of the hundreds of query methods in SQL Server, and even then only when the server is configured to operated in Mixed Mode.
What is Mixed Mode?
SQL Server supports two modes for authenticating users, Mixed Mode and Windows Authentication Mode. In Mixed Mode, clients are authenticated using Windows credentials if possible; otherwise, the client authenticates via SQL Server Authentication, using username and password information that is stored locally in the SQL Server database. The most common use of Mixed Mode is when SQL Server is hosted on a Windows® 95 or 98 machine.
In contrast, Windows Authentication mode requires authentication to be performed using Windows NT® (or Windows 2000) credentials. This is far more secure, and Microsoft strongly recommends that Windows Authentication Mode be used whenever possible. Customers who use Windows Authentication Mode would not be affected by this vulnerability.
You said that the vulnerability could enable an attacker to reuse a cached connection. What is a cached connection?
Before a user can levy requests on a SQL Server database, a connection between the user and the server must be established. When the SQL session is complete, the connection is broken. However, SQL Server retains the connection in a cache for a short period for performance reasons - if the same user creates a new connection, the cached one can be reused rather than creating it anew. This vulnerability could enable an attacker to reuse someone else's cached connection - specifically, one that was created by an administrator.
So, this vulnerability could enable an attacker to recover an administrator's cached credentials, but only if the server were operating in Mixed Mode?
Yes. If the attacker used the particular query method that contains the error, and the server were operating in Mixed Mode, and a connection belonging to an administrator happened to be in the cache at the time of the attack, the attacker could designate that the query be performed using the administrator's cached connection.
What would this enable the attacker to do?
The ability to execute a query method using an administrator's connection would grant administrative privileges to the query. This would enable the attacker to take any desired action on the database, thereby giving her an opportunity to add, create or modify any data in the database. In addition, because queries can be used to execute programs called extended stored procedures, exploiting the vulnerability could also enable the attacker to run code of her choice on the machine. This would give her de facto control of the server.
How difficult would it be to exploit this vulnerability?
It could be quite difficult. As we discussed above, it would require that the server be configured in a particular way and that the attacker have pinpoint timing. Neither of these factors would be under the attacker's control, so it's likely that this vulnerability could only be used against targets of opportunity.
Who could exploit the vulnerability?
The particular query method at issue here can only be used by authenticated users. As a result, the attacker would need authorization to levy queries against the database in order to exploit the vulnerability. This is significant for two reasons: it limits the number of users who could attack a vulnerable machine, and it means that the attacker's actions could be audited.
What does the patch do?
The patch eliminates the vulnerability by restoring proper operation to the affected query method, thereby preventing it from reusing other users' cached connections.
What if I don't want to apply the patch -- is there a workaround?
Yes, however, this workaround should only be used if you cannot upgrade to SQL Server 7.0 SP3 and apply the patch provided -- and if you are not currently using replication or do not use or intend to use ad hoc named queries.
Using SQL Server Enterprise Manager:
1. | Click on the security tab under the SQL Server instance. |
2. | Right click on the linked servers to bring up the general properties tab. |
3. | Select the radio button next to "Other Data Source" and then pick "Microsoft OLE DB Provider for SQL Server" in the Provider Name drop down list. |
4. | Click the "Provider Options" button |
5. | Add a check to "disallow Ad Hoc queries" check box. |
