Microsoft Security Bulletin MS03-031

Technical description:

This is a cumulative patch that includes the functionality of all previously released patches for SQL Server 7.0, SQL Server 2000, MSDE 1.0, and MSDE 2000. In addition, it eliminates three newly discovered vulnerabilities.

• Named Pipe Hijacking

  Upon system startup, SQL Server creates and listens on a specific named pipe for incoming connections to the server. A named pipe is a specifically named one-way or two-way channel for communication between a pipe server and one or more pipe clients. The named pipe is checked for verification of which connection attempts can log on to the system running SQL Server to execute queries against data that is stored on the server.

  A flaw exists in the checking method for the named pipe that could allow an attacker local to the system running SQL Server to hijack (gain control of) the named pipe during another client's authenticated logon password. This would allow the attacker to gain control of the named pipe at the same permission level as the user who is attempting to connect. If the user who is attempting to connect remotely has a higher level of permissions than the attacker, the attacker will assume those rights when the named pipe is compromised.

• Named Pipe Denial of Service

  In the same named pipes scenario that is mentioned in the "Named Pipe Hijacking" section of this bulletin, it is possible for an unauthenticated user who is local to the intranet to send a very large packet to a specific named pipe on which the system running SQL Server is listening and cause it to become unresponsive.

  This vulnerability would not allow an attacker to run arbitrary code or elevate their permissions, but it may still be possible for a denial of service condition to exist that would require that the server be restarted to restore functionality.

• SQL Server Buffer Overrun

  A flaw exists in a specific Windows function that may allow an authenticated user-with direct access to log on to the system running SQL Server-the ability create a specially crafted packet that, when sent to the listening local procedure call (LPC) port of the system, could cause a buffer overrun. If successfully exploited, this could allow a user with limited permissions on the system to elevate their permissions to the level of the SQL Server service account, or cause arbitrary code to run.

Mitigating factors:

Named Pipe Hijacking:

• To exploit this flaw, the attacker would need to be an authenticated user local to the system.
• This vulnerability provides no way for an attacker to remotely usurp control over the named pipe.

Named Pipe Denial of Service:

• Although it is unnecessary that the attacker be authenticated, to exploit this flaw the attacker would require access to the local intranet.
• Restarting the SQL Server will reinstate normal operations
• This flaw provides no method by which an attacker can gain access to the system or information contained in the database.

SQL Server Buffer Overrun:

• To exploit this flaw, the attacker would need to be an authenticated user local to the system.
• This vulnerability cannot be remotely exploited.

Severity Rating:

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.

Vulnerability identifier:

• Named Pipe Hijacking CAN-2003-0230
• Named Pipe Denial of Service CAN-2003-0231
• SQL Server Buffer Overrun CAN-2003-0232

  Tested Versions:

  Microsoft tested SQL Server 7.0, MSDE 1.0, SQL Server 2000 SP3, SP3a, MSDE 2000 SP3 and MSDE (Windows) to assess whether they are affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

What vulnerabilities does this patch eliminate?
This is a cumulative patch that, when applied, addresses all previously reported vulnerabilities in SQL Server. In addition, it eliminates three new vulnerabilities:

• A vulnerability through which an already authenticated user with physical access to the SQL server could gain additional permissions on the system.
• A vulnerability that could enable an attacker to cause a denial of service situation against the system.
• A vulnerability through which an authenticated user with physical access to the system could potentially cause a program to run, or elevate their permissions on the system to that of the SQL Server Service account.

Is this patch cumulative?
This patch does supersede all previously released security patches involving the SQL Server 7.0 and SQL Server 2000 database engines. However, applying this patch is not sufficient by itself to fully secure a system running SQL Server:

• One security fix for SQL Server 2000, discussed in Microsoft Security Bulletin MS02-035, requires remediation by using a tool rather than a patch. The tool only needs to be run one time, so customers who have previously run it do not need to take additional action. However, installing this patch does not cause the tool to be run.
• The patch does not include any fixes for security vulnerabilities involving the Microsoft Data Access Components (MDAC) or Online Analytic Processing (OLAP) technologies for SQL Server. The patches for these issues (listed in the Caveats section below) must be applied separately.

The "Affected Versions Software" section of this bulletin says that MSDE is also affected by these vulnerabilities. What is MSDE?
Microsoft Desktop Engine (MSDE) is a database engine that is built and based on SQL Server technology, and which ships as part of several Microsoft products, including Microsoft Visual Studio and Microsoft Office Developer Edition.
There is a direct connection between versions of MSDE and versions of SQL Server. MSDE 1.0 is based on SQL Server 7.0; MSDE 2000 is based on SQL Server 2000.

Does the Microsoft Desktop Engine ship with any version of Windows?
Yes. MSDE is included in Windows Server 2003 to support Universal Description, Discovery, and Integration (UDDI). It is called Microsoft SQL Server 2000 Desktop Engine (Windows), and will be listed in Control Panel as "SQL Server Desktop Engine (UDDI)." No other versions of Windows include MSDE.

Is the SQL Server 2000 Desktop Engine (Windows) installed on Windows Server 2003 by default?
No. It is currently only installed on Windows Server 2003 installations that are configured to support UDDI.

What is UDDI?
Universal Description, Discovery, and Integration(UDDI) is an XML-based registry for businesses worldwide to list themselves on the Internet. Its ultimate goal is to streamline online transactions by enabling companies to find one another on the Web and make their systems interoperable for e-commerce.

Is this patch available on Windows Update for any supported platforms other than Windows Server 2003?
No. The Microsoft SQL Server 2000 Desktop Engine (Windows) is not included with any other version of Windows. As such, this update is only available on Windows Update for Windows Server 2003 installations that are configured to support UDDI.

How do I tell if I have MSDE or SQL Server 2000 installed on my system?
Click Start, click Search, and then search the local system for the file "sqlservr.exe." If this file is present on your system, you have MSDE or SQL Server installed.

The SQL Server 2000 patch is only available to install on SP3a. What if I am using SP2 or earlier?
Because SQL Server service packs are cumulative, SP3a includes all fixes from previously released Service Pack 1 (SP1), Service Pack 2 (SP2), and Service Pack 3 (SP3). SP3a can be applied to an original installation or to one where SP1, SP2, or SP3 was previously applied. Previous service pack versions are no longer supported. Information on the support lifecycle is available at http://support.microsoft.com/common/international.aspx?rdpath=fh;en-us;lifecycle.

I already have SP3 installed on my system. Does this mean that I need to upgrade to SP3a?
If you have applied SP3, you do not need to apply SP3a. SP3a is only for SQL Server users who have not applied any versions of SP3. More information about SP3a is available at http://www.microsoft.com/downloads/details.aspx?familyid=90dcd52c-0488-4e46-afbf-acace5369fa3.

Does the patch include any other fixes?
Yes. This patch includes a behavior change to the setting of the SA Account password. After applying this patch, a user who deliberately attempts to set the SA Account password to "blank" will receive a security warning. Additionally, if the named pipes protocol has been disabled prior to applying this patch, a user will notice the following three changes:

• Console.exe will not be able to connect to the system running SQL Server.
• All SQL Server Agent jobs that require tape mounting will fail.
• Backups to pipe will fail before attempting to connect to the pipe.

Microsoft has published Knowledge Base article 818806 which contains additional details about this change.

Named Pipe Hijacking:

What's the scope of this vulnerability?
This is a privilege elevation vulnerability. This could allow an attacker to gain control of the named pipe at the same permission level as the user attempting to connect. If the user connecting remotely had higher access rights than the attacker, the attacker could assume those rights when the named pipe was compromised.
To exploit this vulnerability, an attacker would have to be logged on to the system running SQL Server locally at the time of the named pipe connection attempt.

What causes the vulnerability?
The vulnerability results because of a flaw in the checking method used by SQL Server when a client establishes an authenticated logon by using a named pipe. This flaw could allow an attacker to hijack (gain control of) the pipe and acquire the same level of access as the authenticated user.

What's a named pipe?
A pipe is an area of memory that two or more processes share, and which enables them to communicate with each other. When Process A wants to communicate with Process B, it puts data into the shared memory and sets a semaphore flag telling Process B to read it.
There are two types of pipes:

• Anonymous pipes, which allow one-way communication from a parent process to a child process. These can only exist locally.
• Named pipes, which allow bidirectional communication between multiple processes. The processes can reside on different systems.

What's wrong with the way SQL Server validates named pipes?
SQL Server creates and listens to a named pipe at startup. Any user can connect to this pipe, and the server determines which connection attempt can actually log on or not.

What could this vulnerability enable an attacker to do?
If an attacker were able to successfully exploit this vulnerability, they would be able to access information and data at the same level of permission as the authenticated user connecting over the pipe. If the user had administrative permissions the attacker would also assume administrative permissions over the database.

How could an attacker exploit this vulnerability?
An attacker (a low privileged user) who was logged on to a system running SQL Server could seek to exploit this vulnerability by creating the same named pipe that the comptuer running SQL Server uses.
When a client then connected to the system running SQL Server through the named pipe, and used Windows Authentication, the attacker could then hijack the named pipe and assume the same level of permission over the database as the user who had connected.

Is an attacker limited in any way when attempting this sort of attack?
Yes. An attacker must be able to log on interactively to the system running SQL Server in order to exploit this flaw.

What does the patch do?
The patch addresses the vulnerability by limiting the creation of named pipes to the SQL Server process only.

Named Pipe Denial of Service:

What's the scope of this vulnerability?
This is a denial of service vulnerability that could cause SQL Server to stop responding (hang).
To successfully exploit this flaw, an attacker would require access to the local intranet, although it is not necessary for them to be authenticated on the domain.
There is no way for a attacker to use this vulnerability as a means of usurping control over the system, or gaining access to any information on the server. Restarting the SQL Server restores normal functionality.

What causes the vulnerability?
The vulnerability results because of a flaw in the way that SQL Server interprets a return code from a specific named pipes operation. When more data than expected is received, SQL misinterprets the valid return code as an error. When this occurs, the system stops responding.

What could this vulnerability enable an attacker to do?
If an attacker were able to successfully exploit this vulnerability, they could interrupt the normal operations of a system running SQL Server by causing it to stop responding.
This behavior would be temporary and would be corrected when the SQL Server was restarted.

How could an attacker exploit this vulnerability?
An attacker, with access to the local intranet, could seek to exploit this vulnerability by crafting a very large packet and sending it to the named pipe on which SQL Server is listening.
This could cause the server to stop responding. You would need to restart the SQL Server to regain functionality.

Why would an attacker need access to the local intranet to exploit this vulnerability?
An attacker would need access to a domain trusted by the domain of the system running SQL Server. They would then need to be able to open a named pipe to a particular SQL Server, thereby creating a connection and then sending the specially crafted packet over that established connection.

What does the patch do?
The patch limits the amount of data read by the system running SQL Server to the size of the established buffer.

SQL Server Buffer Overrun:

What's the scope of this vulnerability?
This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could cause the system to fail, or could cause code of the attacker's choice to be executed with the same permissions as the SQL Server Service account.
Code running with service account permissions could provide an attacker with the ability to take full control over the database and the data contained within it.
The vulnerability could only be exploited by an attacker who had valid credentials to interactively log on to the system.

What causes the vulnerability?
The vulnerability results because of a flaw in the way SQL Server validates requests to the LPC port on which it listens.
Because LPC can only be used on the local system, this vulnerability could not be exploited remotely. Instead, an attacker could only exploit this on systems that they could log on to interactively. Typically, workstations and terminal servers would be at the greatest risk, because, if ordinary security practices have been followed, ordinary users will not be allowed to log on to critical servers interactively.

What is LPC?
Local Procedure Call (LPC) is a message-passing service provided by Windows NT 4.0, Windows 2000, and Windows Server 2003 that allows threads and processes to communicate with each other. Whenever a client process needs to request services from a server process, there has to be a way for the two processes to communicate with each other - that is, there must be a way for the client process to make requests of the server, for the server to send responses to the client, and for each to determine their mutual status. When the client and server processes are located on different systems, RPC is used. When they are located on the same system, LPC can be used.
The advantage of using LPC is that it's fast. Because the processes are located on the same system, certain efficiencies can be gained to speed up the communications. For instance, it is possible under LPC for the two processes to communicate by using a shared memory segment rather than by passing messages to each other. One process puts a message in the shared segment and sends a signal to the other party, which then reads the message from the shared segment.

What are LPC Ports?
Every LPC has a collection of communications channels called LPC ports. Each port carries one type of communication-for instance, an LPC will always have a port that is used to allow one client to send messages to the server, another port that allows the server to send messages to each client, and other ports that, for instance, allow threads within a process to coordinate their requests.

What's wrong with the way SQL Server validates LPC Requests?
SQL Server does not properly validate certain types of requests made to the LPC port on which it listens. As a result, it could be possible to send a specially crafted packet to the LPC port and cause a buffer overrun to occur.

What could this vulnerability enable an attacker to do?
If an attacker were able to successfully exploit this vulnerability, they could cause code to be executed on the system with the permissions of the SQL Service account.
Code running with service account permissions could provide an attacker with the ability to take full control over the database and the data contained within it.

How could an attacker exploit this vulnerability?
An attacker, who had permissions to interactively log on to the system running SQL Server, might attempt to exploit this vulnerability by creating an especially large packet that, when sent to the listening port of the system, could cause a buffer overrun.

What does the patch do?
The patch limits the amount of data read by the SQL Server to the size of the established buffer.

Download locations for this patch

• Microsoft SQL Server 7.0
• Microsoft SQL 2000 32-bit Edition
• Microsoft SQL 2000 64-bit Edition