What's the scope of the vulnerability?
This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability 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 functions provided by SQL Server contain unchecked buffers. Specifically in functions that are associated with connecting to remote data sources through "ad hoc names". By calling any of these functions with specially chosen parameters, an attacker could cause a buffer overrun condition to occur.
What are "ad hoc names"?
SQL Server provides the ability to connect to pull information from remote data sources on a variety of platforms to allow for data warehousing, analysis, and aggregation. Connections to remote data sources can be accomplished in one of two ways. By establishing a "linked server" connection for regular, ongoing connections, or through the use of "ad hoc names" for connections that may be established less often.
What's wrong with the functions?
The functions impacted by this vulnerability have the same defect: they fail to properly validate that information which is passed will fit into the buffer that has been provided. Because of this, an attacker could provide text 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 alter the SQL Server software while it was running.
If the attacker provided random data as the text, 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 one of the affected functions 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?
If an attacker were unable to load and run a query of their choosing, they could attempt to exploit this vulnerability by using 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 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 calls to the affected functions - 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 implanting proper checking into the affected functions.
