SQL Server Remote Data Source Function Buffer Overflows
21 Feb. 2002
One of the features of Structured Query Language (SQL) in SQL Server 7.0 and 2000 is the ability to connect to remote data sources. One capability of this feature is the ability to use "ad hoc" connections to connect to remote data sources without setting up a linked server for less-often used data-sources. This is made possible using OLE DB providers, which are low-level data source providers. This capability is made possible by invoking the OLE DB provider directly by name in a query to connect to the remote data source.
An unchecked buffer exists in the handling of OLE DB provider names in ad hoc connections. A buffer overrun could occur as a result and could be used to either cause the SQL Server service to fail, or to cause code to run in the security context of the SQL Server. SQL Server can be configured to run in various security contexts, and by default runs as a domain user. The precise privileges the attacker could gain would depend on the specific security context that the service runs in.
An attacker could exploit this vulnerability in one of two ways. They could attempt to load and execute a database query that calls one of the affected functions. Conversely, if a web site or other database front-end were configured to access and process arbitrary queries, it could be possible for an attacker to provide inputs that would cause the query to call one of the functions in question with the appropriate malformed parameters.
* Microsoft SQL Server 7.0
* Microsoft SQL Server 2000
* The effect of exploiting the vulnerability would depend on the specific configuration of the SQL Server service. SQL Server can be configured to run in a security context chosen by the administrator. By default, this context is as a domain user. If the rule of least privilege has been followed, it would minimize the amount of damage an attacker could achieve.
* Both vectors for exploiting the vulnerability could be blocked by following best practices. Specifically, untrusted users should not be able to load and execute queries of their choice on a database server. In addition, publicly accessible database queries should filter all inputs prior to processing.
What is 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 using "ad hoc names" for connections that may be established less often.
What is 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.