What's the scope of the vulnerability?
This is a buffer overrun vulnerability and is found in common in several of the Microsoft-provided extended stored procedures. An attacker who successfully exploited this vulnerability in one of the affected extended stored procedures would gain significant control over the database and possibly the server itself. In a worst case, the attacker could add, change or delete data in the database, as well as potentially being able to reconfigure the operating system, install new software, or reformat the hard drive.
The scope of this vulnerability, however, would be significantly reduced if best practices were followed. Specifically:
| • | SQL Server can be configured to run in a security context accordance with the rule of least privilege. By default, SQL Server runs in the security context of a domain user, a context with very limited privileges on the server. If this were done, it would have the effect of limiting the potential actions an attacker could take in the event of a successful attack. |
| • | In addition to successfully exploit this vulnerability, the attacker would need to be able to load and run a query of his construction on the server, or be able to pass information of their choosing into an existing query on the system. Best practices recommends against both of these practices. |
What causes the vulnerability?
The vulnerability results because several of the extended stored procedures provided by SQL Server handle user input incorrectly, and don't check the length of the input before using it. This could result in a buffer overrun condition in the affected stored procedures.
What are SQL extended stored procedures?
Extended stored procedures allow you to create your own external routines in a programming language such as C. The extended stored procedures appear to users as normal stored procedures and are executed in the same way. Database queries can pass data to extended stored procedures which can return results and return status.
For instance, among the standard extended stored procedures included with SQL server are ones that provide e-mail functions. For example:
| • | xp_startmail, which starts a SQL Mail client session, and |
| • | xp_sendmail, which sends an e-mail or page. |
What's wrong with the extended stored procedures?
Some of the extended stored procedures provided by Microsoft fail to properly validate that the information which is passed will fit into the buffer that has been provided. Because of this, an attacker could provide input data that overruns the buffer and overwrites the memory within the SQL Server process itself.
What would this enable an attacker to do?
Depending on the specific data that the attacker chose, one of two effects could result:
| • | If the data were random data, the SQL Server process would fail. |
| • | If the were carefully selected, it could be possible for the attacker to run code in the context of the SQL server service account. |
If the attacker provided random input data, what would be required in order to restore normal operation?
The administrator would need to restart the SQL Server service.
If the attacker provided carefully selected data and altered the SQL Server software, what could the new software do?
It would depend on how SQL Server had been configured. By default, SQL Server runs in a non-privileged security context (specifically, as a domain user). An attacker who successfully exploited this vulnerability against a server configured in this manner would gain control over the database, but little else.
If, however, the administrator had configured SQL Server to run with higher privileges, a successful attack could possibly gain those additional privileges. Thus, the potential damage of a successful attack is proportionate to the degree to which the principle of least privilege has been followed in the configuration of SQL Server.
How might an attacker exploit this vulnerability?
There are several ways an attacker would try to exploit this vulnerability. The most direct attack vector would be for the attacker to construct a query that calls an affected function and performs a buffer overrun attack. However, to succeed at this, the server would have to be configured to allow an untrusted user to load and execute queries of their choice. Best practices strongly recommends against allowing untrusted users to load and run queries of their construction.
Is there any other way an attacker would try to exploit this vulnerability?
An attacker who couldn't directly load and execute a query might still be able to exploit the vulnerability if he could use a query that was already present on the system.
For example, if the database were part of a web-based search tool and one of the functions in question were called by the web site, an attacker could attempt to construct a query that would exploit this vulnerability. However, constructing a query like this would require the attacker to possess intimate knowledge about the internals of a web site's search function.
If a site had implemented web-based queries without proper checking of inputs, however, it could be possible for an attacker to embed database commands-including a call to the affected function-within the database query parameters. This shows the importance of validating input parameters before passing them to the database server for processing.
What does the patch do?
The patch eliminates the vulnerability by implementing proper checking on the affected extended stored procedures.
