Microsoft Security Bulletin MS02-007 - Moderate

  • Article

SQL Server Remote Data Source Function Contain Unchecked Buffers

Published: February 20, 2002 | Updated: May 09, 2003

Version: 1.2

Originally posted: February 20, 2002
Updated: May 09, 2003

Summary

Who should read this bulletin: Database administrators using Microsoft® SQL Server™.

Impact of vulnerability: Run code of attacker's choice on server

Maximum Severity Rating: Moderate

Recommendation: Apply the SQL Server patch immediately to affected systems

Affected Software:

  • Microsoft SQL Server 7.0
  • Microsoft SQL Server 2000

General Information

Technical details

Technical description:

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 through the use of 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.

Mitigating factors:

  • 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.

Severity Rating:

Internet Servers Intranet Servers Client Systems
SQL Server 7.0 Moderate Moderate Moderate
SQL Server 2000 Moderate Moderate Moderate

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. While the vulnerability could potentially allow an attacker to run code on the server, best practices should limit the ability to exploit the vulnerability and the damage that could be achieved by a successful attack.

Vulnerability identifier: CAN-2002-0056

Tested Versions:

Microsoft tested SQL Server 7.0 and 2000 to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

Frequently asked questions

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.

Patch availability

Download locations for this patch SQL Server 7.0:

  • The patch for this issue is available in the SQL Server 7.0 Cumulative Security patch

SQL Server 2000:

  • The patch for this issue is available in the SQL Server 2000 Cumulative Security patch

Additional information about this patch

Reboot needed:

No. The SQL Server service only needs to be restarted after applying the patch.

Superseded patches:

MS01-060

Verifying patch installation: SQL Server 7.0:

  • To ensure that you have properly installed the fix, run the following command from the command prompt:

    • "SELECT @@VERSION" (without the quotation marks)

    If the patch has been correctly installed, the resulting output will indicate the version number as "SQL Server 7.00 - 7.00.1021" or greater.

  • To verify the individual files, consult the date/time stamp of the files listed in the file manifest in Microsoft Knowledge Base article Q317979.

SQL Server 2000:

  • To ensure that you have properly installed the fix, run the following command from the command prompt:

    • "SELECT @@VERSION" (without the quotation marks)

    If the patch has been correctly installed, the resulting output will indicate the version number as "SQL Server 8.00 - 8.00.0578" or greater.

  • To verify the individual files, consult the date/time stamp of the files listed in the file manifest in Microsoft Knowledge Base article Q317979.

Caveats:

A potential side effect of this patch on systems that use non-logged bulk insert operations against an empty table is possible data corruption. Knowledge Base article Q320434 provides additional details on this issue.

Localization:

The patches can be applied to all supported SQL Server languages. Localized Readme.txt files are included in the packages for installation instructions in all supported languages.

Obtaining other security patches:

Patches for other security issues are available from the following locations:

  • Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
  • Patches for consumer platforms are available from the WindowsUpdate web site.

Other information:

Support:

  • Microsoft Knowledge Base article Q317979 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
  • Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions:

  • V1.0 (February 20, 2002): Bulletin Created.
  • V1.1 (March 29, 2002): Caveats section updated to include information regarding possible issue with patch and bulk data transfers.
  • V1.2 (May 09, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00 </https:>