Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Microsoft Security Bulletin MS01-060 - Moderate

SQL Server Text Formatting Functions Contain Unchecked Buffers

Published: December 20, 2001 | Updated: May 09, 2003

Version: 1.5

Originally posted: December 20, 2001
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
  • Denial of service

Maximum Severity Rating: 
Moderate

Recommendation:

  • Apply the SQL Server patch immediately to affected systems
  • Apply the C runtime patch only to systems judged to be at high risk.

Affected Software:

  • Microsoft SQL Server 7.0
  • Microsoft SQL Server 2000

General Information

Technical description:

SQL Server 7.0 and 2000 provide a number of functions that enable database queries to generate text messages. In some cases, the functions create a text message and store it in a variable; in others, the functions directly display the message. Two vulnerabilities associated with these functions have been discovered.

The first vulnerability results because of a flaw in the functions themselves. Several of the functions don't adequately verify that the requested text will fit into the buffer that's supplied to hold it. A buffer overrun could occur as a result, and could be used either to run code in the security context of the SQL Server service or to cause the SQL Server service to fail. 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.

The second vulnerability results because of a format string vulnerability in the C runtime functions that the SQL Server functions call when installed on Windows NT® 4.0, Windows® 2000 or Windows XP. Although format string vulnerabilities often can be exploited to run code of the attacker's choice, that is not true in this case. Because of the specific way this vulnerability occurs, the C Runtime code would always be overrun with the same values regardless of the attacker's inputs. As a result, this vulnerability could only be used as a denial of service.

An attacker could exploit the vulnerabilities in either of two ways. The most direct way would be for the attacker to simply load and execute a database query that calls one of the affected functions. Alternatively, if a web site or other database front-end would accept and process arbitrary queries, it could be possible for the attacker to provide inputs that would cause the query to call an affected function with the appropriate parameters.

Because the two vulnerabilities have different root causes, there are separate patches for each. Microsoft recommends that the SQL Server patch be applied to all affected servers. However, we recommend that customers carefully weigh whether they need to apply the C runtime patch. We make this recommendation for two reasons:

  • The C runtime vulnerability only allows denial of service attacks, so the threat it poses is somewhat lower.
  • The C runtime plays a crucial role in the operating system itself. While we are confident that both patches are well-tested, if there were a regression error in the C runtime, the effects would likely be serious and widespread.

Mitigating factors:

  • The effect of exploiting the first vulnerability would depend on how the SQL Server service was configured. SQL Server can be configured to run in a security context of the administrator's choosing. (By default, it runs as a domain user). If best practices are followed, and the service is configured to run with the least privileges necessary, it would limit the worst-case damage an attacker could achieve.
  • The second vulnerability could only be used for denial of service attacks. It could not be used to run code on the machine.
  • The second vulnerability could only be exploited against SQL Server when running on Windows NT 4.0, Windows 2000 or Windows XP.
  • Both vectors for exploiting the vulnerabilities could be blocked by following best practices. Specifically, untrusted users should not be allowed to load and execute queries of their choice on a database server, and publicly accessible database queries should thoroughly filter all inputs prior to using them.

Severity Rating:

Internet ServersIntranet ServersClient Systems
SQL Server Vulnerability ModerateModerateModerate
C Runtime Vulnerability LowLowLow

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. The SQL Server vulnerability allows code to be run by an attacker, but only if the attacker already had the ability to submit arbitrary database queries. The C Runtime vulnerability is subject to the same mitigation, and could only be used for denial of service attacks.

Vulnerability identifier:

Tested Versions:

Microsoft tested SQL Server 7.0 and 2000, and the C runtimes in Windows NT 4.0, Windows 2000 and Windows XP, 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.

What are the vulnerabilities discussed in this bulletin?
This bulletin discusses an attack scenario against SQL Server that actually results from two completely unrelated vulnerabilities:

  • The first vulnerability results from a flaw in SQL Server itself.
  • The second vulnerability results from a flaw in the C runtime in Windows NT 4.0, Windows 2000, and Windows XP that is exposed primarily through SQL Server.

What's the scope of the first vulnerability?
The first vulnerability is a buffer overrun vulnerability. An attacker who successfully exploited the vulnerability would gain significant control over the database, and perhaps over the server itself. In the worst case, this could enable the attacker to add, delete, or change data in the database, as well as potentially allowing the attacker to reconfigure the operating system, install new software on it, or simply reformat the hard drive.
The scope of the vulnerability would be significantly reduced if best practices were followed. In particular:

  • SQL Server can be configured to run with less than total privileges on the server. If this were done, it would also have the effect of limiting what an attacker could do via this vulnerability.
  • In order to exploit the vulnerability, the attacker would need the ability to load and run a database query (which best practices recommend against), or would need to locate a query that didn't correctly check all inputs before using them.

What causes the vulnerability? 
The vulnerability results because several functions provide by SQL Server contain unchecked buffers. By calling any of these functions with specially chosen parameters, an attacker could cause a buffer overrun condition to occur.

What are the affected functions? 
The functions that contain the unchecked buffers are associated with creating, and in some cases displaying, text messages. SQL Server provides several functions that enable a database query to create formatted text. In some cases, the text is simply stored in a variable in order to be printed later; in others, the text is immediately displayed in response to an error condition.

What's wrong with the functions? 
The functions implicated in the vulnerability all have the same defect: they don't check that the text the query has requested will actually fit into the buffer that's been provided. Because of this, an attacker could provide text that overruns the buffer and overwrites memory within the SQL Server process itself.

What would this enable an attacker to do? 
Depending on the specific text the attacker chose, either of two effects could occur:

  • If the text were random data, the SQL Server process would fail.
  • If the text 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 the privileges the SQL Server service had to begin with. By default, SQL Server normally runs with unexceptional privileges (specifically, those of a domain user). An attacker who successfully exploited this vulnerability against such a server would gain control over the database, but little else.
On the other hand, if the administrator had configured SQL Server to run with higher privileges, a successful attacker could potentially gain additional privileges. This is a good example of the importance of adhering to the principal of least privilege.

How might an attacker exploit this vulnerability?
There are several ways an attacker might exploit the vulnerability. The most direct one would be for the attacker to construct a query that deliberately calls one of the affected functions and overruns its buffer. However, it would only be possible for the attacker to do this if the server had been configured to allow untrusted users to load and run queries of their choice. Best practices recommend that only trusted users be allowed to do this.

What if the attacker couldn't load and execute a query? 
It might still be possible to exploit the vulnerability. Suppose, for instance, that a web site provided a service that involved searching a database. If the database search called one of the affected functions, it might be possible for an attacker to construct a query that would cause the function to be called in such a way as to exploit the vulnerability. Clearly, this would require intimate knowledge of the internals of the database query.
On the other hand, if the database query were poorly implemented, the attacker might not need to know its internal details in order to exploit the vulnerability. One frequently exploited implementation error occurs when a database query doesn't adequately check its inputs before using them. In some cases, this would make it possible for an attacker to embed database commands - including, in this case, calls to the affected functions - within database query parameters. This underscores the need to always check input parameters before using them.

What does the patch do? 
The patch eliminates the vulnerability by implanting proper checking into the affected functions.

What's the scope of the second vulnerability?
The second vulnerability is a denial of service vulnerability. Although the attack scenario for this vulnerability is exactly the same as for the first vulnerability, it could only be used to cause the SQL Server service to fail, and only when running on Windows NT 4.0, Windows 2000, or Windows XP. The administrator could immediately restore service by restarting the SQL Server service.
As in the case of the first vulnerability, exploiting this vulnerability could be difficult. The attacker would either need the ability to load and run a database query on a SQL Server, or would need to locate an existing query - one that didn't check its inputs -- on the machine. As discussed in greater detail below, we recommend that the patch for this vulnerability only be applied to systems that the administrator judges to be at very high risk.

What causes the vulnerability? 
This vulnerability occurs because the C runtime in Windows NT 4.0, Windows 2000 and Windows XP are subject to a format string vulnerability.

How is this vulnerability related to the first vulnerability? 
In terms of the implementation error, this vulnerability is completely unrelated to the first one. That vulnerability results because of an implementation error in SQL Server; this one results because of a flaw in the C runtime. However, in terms of the attack scenario, they are identical. Both could be exploited through SQL Server, in exactly the same way. In fact, from an attacker's perspective, it would appear that there was only a single vulnerability.

What's the C runtime? 
The C runtime is the set of executables and files that provide support for programs written in the C programming language. All Windows platforms ship with a runtime for C, as well as other languages. The problem results because of a format string vulnerability affecting one of the functions in the C runtime that ships with Windows NT 4.0, Windows 2000, and Windows XP.

What's a format string vulnerability? 
A format string vulnerability occurs when a function that accepts formatted text for printing doesn't properly validate it before using it. In some cases, it's possible to either overwrite program code or take other action via the formatting codes.

If it's possible to overwrite program code via a format string vulnerabilty, why do you say this could only be used for denial of service attacks? 
It's true that format string vulnerabilities can, in many cases, be exploited to run programs of an attacker's choice. However, this isn't universally true. In the case of this vulnerability, program code can indeed be overwritten, but with the same values every time, regardless of the data that was provided to the function. The values don't lend themselves to running code, and the result is that the worst that could happen is that the SQL Server service could be made to fail.
If this vulnerability involves the C runtime, why are you discussing it solely in terms of SQL Server? Couldn't someone just write a C program and use it to exploit the vulnerability? 
Yes. However, if an attacker wrote a C program to exploit this vulnerability, the only effect would be to cause the program to fail. It couldn't be used for any broader effect. It's only when the vulnerability is exposed through SQL Server that it becomes a concern, and even then only because it provides a way to cause SQL Server to fail.

How could an attacker exploit this vulnerability? 
The exploit scenario for this vulnerability is indistinguishable from that of the first vulnerability. The attacker would need to create a SQL Server query that requested a particular text message, or locate an existing query that would let him give it arbitrary SQL commands.

Could the attacker tell which vulnerability he was exploiting? 
There are no external indications that would allow the attacker to identify beforehand whether he was exploiting this vulnerability or the one discussed above. Clearly, though, the attacker could judge which vulnerability had been exploited by observing the effect, and seeing whether it was possible to make code run.

You've advised that the patch for the first vulnerability be applied to every system running SQL Server, but only advised that administrators consider applying this patch. Why? 
First, the scope of the first vulnerability is much more serious than this one. But there's a larger answer. The C runtime is fundamental to many operating system functions, including the ability to boot the system at all. Because of this, we believe the threshold for applying the patch should be higher.

Are you saying you don't trust the patch? 
No. The fix is well understood and has been thoroughly tested. Just the same, when building a security patch, timeliness must be our first concern. As a result, we cannot perform the same level of testing as would be performed for a service pack or a new product version. We are confident in the patch, but do believe that it's prudent to only apply it to servers that are truly at risk. For all other cases, we recommend waiting until the next service pack, which will contain the fix.

What does the patch do? 
The patch eliminates the vulnerability by instituting proper validation of the formatted string printing functions in the C runtime.

Download locations for this patch

SQL Server:

C Runtime:

Additional information about this patch

Installation platforms:

SQL Server:

The SQL Server 7.0 and SQL Server 2000 patch can be installed here: http://technet.microsoft.com/en-us/sqlserver/bb331729.aspx.

C Runtime:

  • The patch for the Windows NT 4.0 C runtime can be installed on systems running Windows NT 4.0 Service Pack 6a.
  • The patch for the Windows NT 2000 C runtime can be installed on systems running Windows 2000 Service Pack 1 or Service Pack 2.
  • The patch for the Windows XP C runtime can be installed on systems running Windows XP Gold.

Inclusion in future service packs:

SQL Server:

  • The fix for this issue will be included in SQL Server 2000 Service Pack 2.

C Runtime:

  • The fix for this issue will be included in Windows 2000 Service Pack 3 and Windows XP Service Pack 1.

Reboot needed:

  • SQL Server patch: No. The SQL Server service only needs to be restarted after applying the patch.
  • C Runtime patch: Yes

Superseded patches: This patch superceeds the patch in MS01-032.

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.1020" 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 Q304851

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.0428" 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 Q304850

Windows NT 4.0 C Runtime:

  • To verify that the patch has been installed on the machine, confirm the date/time stamp of the files listed in the file manifest in Q305601

Windows 2000 C Runtime:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q305601.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q305601\Filelist

Windows XP C Runtime:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\q305601.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\q305601\Filelist

Caveats:

As discussed in the FAQ, the C runtime patch should only be applied to servers that are judged to be at high risk. In all other cases, we recommend waiting for the next service pack.

Localization:

  • SQL Server: Localized versions of this patch are available at the locations discussed in "Download Locations".
  • C Runtime: The patches can be installed on any language platform. (There are different language versions available, but the only difference between them is the language in which the EULA is written).

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:

Acknowledgments

Microsoft thanks Chris Anley of @Stake, Inc., for reporting this issue to us and working with us to protect customers.

Support:

  • Microsoft Knowledge Base article Q304850, Q304851 and Q305601 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 (December 20, 2001): Bulletin Created.
  • V1.1 (January 04, 2002): New Download Center page created for Windows XP C runtime patch; bulletin updated to link to new page. (No changes were made to the patch)
  • V1.2 (January 10, 2002): Added download link for 64-bit patch.
  • V1.3 (January 29, 2002): SQL 7.0 patch updated to address non-security regression in non-English patches.
  • V1.4 (January 7, 2003): Updated supercedence information
  • V1.5 (May 09, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.