Microsoft Security Bulletin MS00-092

Technical description:

Extended Stored Procedures (XPs) are DLLs that can be installed by a SQL Server administrator to provide enhanced functionality within SQL Server. An API provided by SQL Server to parse input parameters for XPs, srv_paraminfo(), has a flaw that could result in a buffer overrun condition. The API is designed to locate the nth parameter in a string, and put it into a buffer provided by the XP. By design, the API does not provide a way for the XP to indicate the length of the buffer - instead, the XP is expected to ensure that the buffer will be large enough to hold the parameter. However, not all XPs provided by default in SQL Server perform this checking. A malicious user who provided a sufficiently-long parameter to an affected XP could cause a buffer overrun within srv_paraminfo, in order to either cause the SQL Server to fail, or to cause code of her choice to execute.

There are two scenarios whereby a malicious user might seek to exploit the vulnerability:

• First, she might try to attack a SQL Server directly, by logging onto it and calling an XP. However, she could only do this if she could successfully authenticate to the SQL Server.
• Alternatively, she could try to attack a database server that served as a back-end to a web server, by providing carefully-chosen inputs to the web application. However, XPs are rarely used by web applications. Even if a web application did use an XP, she would need detailed knowledge of the design of the web application in order to feed it parameters that would pass to an XP, and thence to srv_paraminfo() in such a way as to exploit the unchecked buffer.

As a result of these restrictions, it is likely that this vulnerability would be most useful to a malicious user who had already compromised a web server and become a valid SQL Server user on the back-end server. If the malicious user did succeed in running code on the server, it would run in the security context of the SQL Server service account. If best practices have been followed, this account would have only normal user privileges on the machine. In this case, the malicious user's code could take any desired action against the database, but would not gain administrative control of the machine.

The patch works by changing all default XPs to allocate a correctly sized buffer before calling srv_paraminfo(). This approach was chosen over modifying srv_paraminfo() because the latter course of action would have introduced backward compatibility problems. Microsoft recommends that any third-party XPs that call srv_paraminfo() also be checked to ensure that they do so correctly. (The Knowledge Base article referenced below provides information on how to do this.)

What's this bulletin about?
Microsoft Security Bulletin MS00-092 announces the availability of a patch that eliminates a vulnerability in Microsoft® SQL Server products. Microsoft is committed to protecting customers' information,and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

What's the scope of the vulnerability?
This is a buffer overrun vulnerability. A malicious user could exploit this vulnerability in either of two ways. In the simplest case, she could use the vulnerability to cause the SQL Server service to fail. In the more complex case, she could potentially use the vulnerability to run code of her choice on the database server.
There are several issues that would significantly restrict the scope of the vulnerability:

• The affected function is usually not reachable via web applications and other interfaces that are exposed to normal users. As a result, it might be necessary for the malicious user to already have gained a foothold on a machine in order to exploit the vulnerability.
• Even in the case where the malicious user could exploit the vulnerability to run code of her choice, this would not give her administrative control of the server, if recommended practices have been followed.

What causes the vulnerability?
Srv_paraminfo(), an API used by extended stored procedures in SQL Server and MSDE, is subject to a buffer overrun vulnerability. If called with a particular type of malformed argument, code could be made to run on the server, or the service itself could be made to fail, via a buffer overrun vulnerability.

What is MSDE?
MSDE (Microsoft SQL Server Desktop Engine and Microsoft Data Engine) is a database engine based on SQL Server 7.0 that is included in certain versions of Microsoft Office 2000 and Microsoft Visual Studio 6.0, and which may be redistributed by third party software suppliers. MSDE 1.0 was released concurrently with SQL Server 7.0. MSDE 2000 is the successor to MSDE 1.0 and was released concurrently with SQL Server 2000.

What are extended stored procedures?
Let's start with stored procedures, and then address extended stored procedures. A stored procedure is a collection of SQL statements that can be called as though they were a single function. There's a rough corollary between a SQL stored procedure and a batch file - both are text files consisting of commands, and can be run by invoking the name of the procedure or batch file.
An extended stored procedure (XP) takes the notion of a stored procedure one step further. Where stored procedures consist of text files, XPs are written in high-languages like C and compiled into .DLLs. Where stored procedures consist primarily of SQL commands, XPs can provide entirely new functions via their code.

What is Srv_paraminfo()?
Srv_paraminfo() is a helper function that's designed to help XPs parse input parameters. Specifically, when a user calls an XP, he may provide it with some parameters. The purpose of srv_paraminfo() is to allow the XP writer a convenient way to retrieve the nth parameter.

Is the problem in srv_paraminfo() or in the XPs that call it?
There is a design flaw in srv_paraminfo(), but because of backward compatibility issues, the fix actually needs to be made in the XPs that call it. The rationale for this decision is discussed below, and in the KB article. In any event, the effect of the problem is that, if an XP that doesn't perform sufficient checking were provided with a sufficiently-long parameter, it would be possible to cause a buffer overrun to occur in srv_paraminfo().

What could this vulnerability enable a malicious user to do?
A malicious user could exploit this vulnerability in either of two ways:

• If she simply overran the buffer with random data, it would cause the SQL Server service to fail. The operator would need to restart the service in order to resume normal operation; it would not be necessary to reboot the machine.
• If she overran the buffer with carefully-crafted data, the SQL Server service could be made to run code of her choice.

If the malicious user exploited the vulnerability to run code, what could it do?
It would depend on how SQL Server has been configured. Specifically, it would depend on what account the SQL Server service has been configured to run under. When installing SQL Server, the administrator must select the account under which SQL Server will run, and provide the password for the account. If the malicious user exploited the vulnerability to run code, the code would be able to do anything this account had privileges to do.
At a minimum, this would enable the malicious user to have complete control over the database, and to add, change or delete data, and run procedures on the database. However, if best practices have been followed, this would not give her administrative control over the machine itself. Best practices recommend that the SQL Server service be configured to run as a normal user, rather than an administrator. If this was the case, the malicious user would gain only the privileges of a normal user on the machine. (The sole exception to this is when SQL runs as part of a Windows NT® 4.0 cluster -- in this case, and only in this case, the SQL Server service does need to run as local administrator).

How would a malicious user call the affected function?
Srv_paraminfo() can't be called directly by SQL Server users. Instead, a user would need to find an XP that doesn't do the proper checks before calling srv_paraminfo(), then run the XP, providing parameters that, when fed to srv_paraminfo(), would cause the buffer overflow to occur. Clearly, this would require some knowledge of the internals of the XP.

So this vulnerability doesn't affect all XPs? 
Right. Most XPs that use srv_paraminfo() do so in a way that doesn't allow the buffer overrun to occur. Only some XPs have the flaw that allows the buffer overrun to occur.

Suppose the malicious user had identified an XP that was affected by the vulnerability. Could she run it? 
It would depend on her level of access to the machine. SQL Server users can call most XPs, but not all -- so much would depend on which XP was affected, and what the malicious user's permissions on the server were.

Would this vulnerability enable the malicious user to attack web sites?
It's possible, but it would be difficult. If the malicious user visited a web site that had a SQL Server back-end, it's possible that she could provide information to the web application that would cause an XP to be executed with a parameter that would in turn cause srv_paraminfo() to overflow the buffer. However, XPs are typically not called by web applications - they usually support maintenance and operations functions such as replication. Even if a web application did call an XP, the malicious user would need an intimate knowledge of the site internals to know exactly how to cause the information she provided the web application to ripple through three layers of code in exactly the right way.
With that said, though, if the malicious user had already compromised the web server, and had gained user-level access to the SQL Server, she might be able to directly call an XP to exploit the vulnerability.

Could she add her own XP, solely for the purpose of exploiting this vulnerability?
No. Only SQL Server system administrators can install XPs.

You said above that the flaw lies in srv_paraminfo() but that the fix needs to be made in the XPs that call it. Why?
The Knowledge Base article provides a detailed technical explanation, but here's the issue in a nutshell. When calling srv_paraminfo(), the XP needs to pass the parameter string it wants srv_paraminfo() to parse, a block of memory (called a buffer) into which the selected parameter should be put, and some other ancillary information. However, there's no way for srv_paraminfo() to know what the length of the buffer is, because of the way it's passed (via a pointer) and because the calling program - not srv_paraminfo() - created it. As a result, srv_paraminfo() trusts the calling program to have allocated a large enough buffer and puts the nth parameter into it without checking, potentially overrunning it.
In a perfect world, we would have chosen to alter srv_paraminfo() in order to require the calling XP to specify how long the buffer is. Srv_paraminfo() could then ensure that it never overfills the buffer. However, changing the way the API is called would require that every XP in the world be recoded to use the new calling format. Instead, we have chosen to fix the small number of XPs that supply too-small buffers to srv_paraminfo(). Any third-party XP developers that use srv_paraminfo() should likewise check their code.

How can an XP tell whether the buffer it supplies is too small?
Srv_paraminfo() can be called in a mode that doesn't actually copy any data, but instead tells the calling XP how large the nth parameter is. XPs should always call srv_paraminfo() once in this mode, determine how long the parameter is, then allocate a buffer of at least that size and call srv_paraminfo() a second time to actually retrieve the data. The Knowledge Base article contains specific instructions on how to do this.

How can I tell whether MSDE is installed on my machine?
To verify whether MSDE is installed on your machine, go to Control Panel, then select Add/Remove Programs. If MSDE has been installed, SQL Server will be listed as an installed program.

Who should use the patch?
Microsoft recommends that all customers using affected versions of SQL Server or MSDE consider installing the patch.

What does the patch do?
The patch eliminates the vulnerability by causing all XPs that ship with SQL Server or MSDE, and which use the srv_paraminfo() API, to ensure that the affected buffer is long enough before calling srv_paraminfo().

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin .

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

How can I tell if I installed the patch correctly?
The Knowledge Base article provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?

• Microsoft has delivered a patch that eliminates the vulnerability.
• Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
• Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
• Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.

Download locations for this patch

• http://support.microsoft.com/support/sql/xp_security.asp

  Note: The SQL Server 7.0 patch can be applied atop Service Pack 2. It will be included in SQL Server 7.0 Service Pack 3.

  Note: The SQL Server 2000 patch can be applied atop SQL Server 2000. It will be included in SQL Server 2000 Service Pack 1.