Microsoft Security Bulletin MS02-020 - Moderate
SQL Extended Procedure Functions Contain Unchecked Buffers (Q319507)
Published: April 17, 2002 | Updated: February 28, 2003
Originally posted: April 17, 2002
Updated: February 28th, 2003
Who should read this bulletin: Database administrators using Microsoft® SQL Server™
Impact of vulnerability: Run code of attacker's choice
Maximum Severity Rating: Moderate
Recommendation: Apply the patch immediately to affected systems
- Microsoft SQL Server 7.0
- Microsoft SQL Server 2000
SQL Server 7.0 and 2000 provide for extended stored procedures, which are external routines written in a programming language such as C. These procedures appear to users as normal stored procedures and are executed in the same way. SQL Server 7.0 and 2000 include a number of extended stored procedures which are used for various helper functions
Several of the Microsoft-provided extended stored procedures have a flaw in common - namely, they fail to perform input validation correctly, and are susceptible to buffer overruns as a result Exploiting the flaw could enable an attacker to either cause the SQL Server service to fail, or to cause code to run in the security context in which SQL Server is running. 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. Firstly, the attacker could attempt to load and execute a database query that calls one of the affected functions. Secondly, if a web-site or other database front-end were configured to access and process arbitrary queries, it could be possible for the attacker to provide inputs that would cause the query to call one of the functions in question with the appropriate malformed parameters.
- 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.
- The vector for exploiting this 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.
|Internet Servers||Intranet Servers||Client Systems|
|SQL Server 7.0||Moderate||Moderate||Moderate|
|SQL Server 7.0||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 would limit the ability to exploit the vulnerability and the damage that could be achieved by a successful attack.
Vulnerability identifier: CAN-2002-0154
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 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.
Download locations for this patch
Microsoft SQL Server 7.0:
The patch for this issue is available in the SQL 7.0 Cumulative Security patch at http://support.microsoft.com/default.aspx?scid=kb;en-us;318268&sd=tech
Microsoft SQL Server 2000: The patch for this issue is available in the SQL Server 2000 Cumulative Security patch at http://support.microsoft.com/default.aspx?scid=kb;en-us;316333&sd=tech
Additional information about this patch
The SQL Server 7.0 and SQL Server 2000 patch can be installed here: http://technet.microsoft.com/en-us/sqlserver/bb331729.aspx.
No. The SQL Server service only needs to be restarted after applying the patch.
Verifying patch installation:
SQL Server 7.0:
- To ensure you have the fix installed properly, verify the individual files by consulting the date/time stamp of the files listed in the file manifest in Microsoft Knowledge Base article at http://support.microsoft.com/default.aspx?scid=kb;en-us;318268&sd=tech
SQL Server 2000:
- To ensure you have the fix installed properly, verify the individual files by consulting the date/time stamp of the files listed in the file manifest in Microsoft Knowledge Base article at http://support.microsoft.com/default.aspx?scid=kb;en-us;316333&sd=tech
Patches are available for each supported SQL Server Language.
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
- Microsoft Knowledge Base article Q319507 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.
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.
- V1.0 (April 17, 2002): Bulletin Created.
- V1.1 (February 28, 2003): Updated download links to Windows Update.
Built at 2014-04-18T13:49:36Z-07:00