Microsoft Security Bulletin MS02-030

Technical description:

SQLXML enables the transfer of XML data to and from SQL Server 2000. Database queries can be returned in the form of XML documents which can then be stored or transferred easily. Using SQLXML, you can access SQL Server 2000 using XML through your browser over HTTP.

Two vulnerabilities exist in SQLXML:

• An unchecked buffer vulnerability in an ISAPI extension that could, in the worst case, allow an attacker to run code of their choice on the Microsoft Internet Information Services (IIS) Server.
• A vulnerability in a function specifying an XML tag that could allow an attacker to run script on the user's computer with higher privilege. For example, a script might be able to be run in the Intranet Zone instead of the Internet Zone.

Mitigating factors:

Unchecked buffer in SQLXML ISAPI extension:

• The administrator must have set up a virtual directory structure and naming used by the SQLXML HTTP components on an IIS Server. The vulnerability gives no means for an attacker to obtain the directory structure.
• The attacker must know the location of the virtual directory on the IIS Server that has been specifically set up for SQLXML.

Script injection via XML tag:

• For an attack to succeed, the user must have privileges on the SQL Server.
• The attacker must know the address of the SQL Server on which the user has privileges.
• The attacker must lure the user to a website under their control.
• Queries submitted via HTTP are not enabled by default.
• Microsoft best practices recommends against allowing ad hoc URL queries against the database through a virtual root.
• The script will run in the user's browser according to the IE security zone used to connect with the IIS Server hosting the SQLXML components. In most cases, this will be the Intranet Zone.

Severity Rating:

Unchecked buffer in SQLXML ISAPI extension:

Script injection via XML tag:

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 criticality is reckoned due to the possibility of remotely running code in the security context of the operating system and the possibility of running script on a user's system with elevated privileges.

Vulnerability identifiers:

• Unchecked buffer in SQLXML ISAPI extension - CAN-2002-0186
• Script injection via XML tag - CAN-2002-0187

Tested Versions:

Microsoft tested the original SQLXML version shipping with SQL Server 2000 Gold as well as SQLXML versions 1, 2 and 3 to assess whether they are affected by this vulnerability. SQLXML version 1 is no longer supported, and should be upgraded to a later version as discussed in the FAQ below.

What vulnerabilities are eliminated by this patch?
This patch eliminates two vulnerabilities affecting SQLXML, a component that enables SQL Server 2000 servers to accept database queries via XML and send the results via XML. The vulnerabilities are found in the SQLXML HTTP components.

What is XML?
XML (Extensible Markup Language) can be thought of as a universal data format for transmitting information on the Internet. Using XML, web applications that run on different vendors' hardware and software platforms, and which were written in different programming languages, can exchange data with each other.
XML is an important tool in allowing web services to work seamlessly with each other. For instance, a company might want to offer its employees the ability to manage their payroll information and track their vacation time through a single web portal, even though the two types of data might reside on servers that were implemented on completely different hardware and software platforms. As long as the developers of the respective systems standardized on XML as the data format, they could do this easily.

What is SQLXML?
Among the many types of data that can be transmitted via XML are database queries and database replies. SQLXML enables SQL Server 2000 to process XML database queries and create XML database replies and, if configured to do so, operate over HTTP. SQLXML bridges the gap between XML and relational data.
An initial version of SQLXML was delivered as part of SQL Server 2000 Gold, and subsequent versions have been made available for download from the Microsoft Developers Network.

What are the SQLXML HTTP components?
SQLXML can be used to exchange XML data with a SQL server by using any of several different communications methods. One of the communications methods that can be used by SQLXML is the Hyper-text Transmission Protocol (HTTP), which uses Internet protocols to transmit information
The SQLXML HTTP components are set up in a virtual directory on an IIS server, which can be on the same machine as the SQL Server or on a separate computer.

What's a virtual directory?
Before you can access SQL Server 2000 database using HTTP, the administrator must set up a virtual directory. The administrator uses the IIS Virtual Directory Management for SQL Server utility to define and register a new virtual directory, also known as the virtual root, on the computer running IIS. This utility instructs IIS to create an association between the new virtual directory and an instance of Microsoft SQL Server. For information about the user interface for this utility, see IIS Virtual Directory Management Utility.
When using SQLXML HTTP functions, the name of the IIS server and the virtual directory must be specified as part of the URL. The information in the virtual directory (including login, password, and access permissions) is used to establish a connection to a specific database and execute the query.

Are the SQLXML HTTP components enabled by default?
No. Before you can access SQL Server using a URL via the browser or any HTTP client, the administrator must first set up a virtual directory for SQL Server on the IIS Server. The administrator uses the SQLXML Microsoft Management Console (MMC) snap-in that has been provided with any of the SQLXML releases. The SQLXML HTTP components can not be set up using IIS tools.

Is SQLXML available for SQL Server 7.0?
No. It's only available for SQL Server 2000.

What are the vulnerabilities affecting SQLXML?
There are two vulnerabilities:

• A vulnerability that could allow an attacker to run code of their choice on the IIS server.
• A vulnerability that could allow an attacker to execute script on the system of a user who had access to an affected SQL server.

Unchecked buffer in SQLXML ISAPI extension (CVE-CAN-2002-0186)

What's the scope of the first vulnerability?
This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could gain complete control over an affected database server. This would give the attacker to add, delete or change any data on the server, reformat the hard drive, or take other actions.
The vulnerability could only be exploited if the administrator had set up and enabled the SQLXML HTTP components on an IIS Server.

What causes the vulnerability?
The vulnerability results because the SQLXML ISAPI extension contains an unchecked buffer in a section that handles data queries over HTTP.

What's ISAPI?
ISAPI (Internet Services Application Programming Interface) is a technology that enables web developers to write custom code that provides new services for a web server. Such code can be implemented in either of two forms:

• As an ISAPI filter, -- a dynamic link library (.dll) that uses ISAPI to respond to events that occur on the server.
• As an ISAPI extension -- a dynamic link library that uses ISAPI to provide a set of web functions above and beyond those natively provided by IIS.

In the case of this vulnerability, the affected code is an ISAPI extension that allows SQLXML to communicate with users via HTTP.

What's wrong with the SQLXML ISAPI extension?
The extension contains an unchecked buffer. If a database request levied over HTTP were malformed in a particular way, it would have the effect of overrunning the buffer.

How could an attacker seek to exploit this vulnerability?
The vulnerability could be exploited by anyone who could establish an HTTP session with an affected IIS server hosting the SQLXML components.

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

• If the data were randomly selected, the IIS process would fail.
• If the data were carefully selected, it could be possible for the attacker to alter the ISAPI extension while it was running.

If the attacker provided random data, what would be required in order to restore normal operation?
The IIS server hosting the SQLXML HTTP services would need to be restarted.

If the attacker provided carefully selected data and altered the ISAPI extension, what could the modified process do?
The modified process would be able to take any action the attacker directed it to. The SQLXML ISAPI extension runs with LocalSystem privileges, so the attacker could gain complete control over the server and taken any desired action on it.

You said above that the vulnerability could only be exploited if the attacker could establish an HTTP session with the server. What would need to happen in order for this to be possible?
First, the administrator would need to enable SQLXML. By default, it's disabled. Second, SQLXML would need to be configured to allow communications via HTTP; the SQLXML ISAPI extension is only present if this has been done. Even when SQLXML is enabled, enabling HTTP communications is a separate configuration step. Finally, the attacker would need direct connectivity to the server.
It's likely that the latter step would, in most cases, only be possible in an intranet scenario. Database servers, even ones that are web-enabled, typically are not connected directly to the Internet. Generally, a front-end web server would intermediate between Internet users and the database server, thereby preventing the attacker from establishing a web session and exploiting the vulnerability. In most cases, the only scenario in which a user would be able to establish a session with such a server would be in an intranet scenario.

How do the patches eliminate this vulnerability?
The patches eliminates the vulnerability by instituting proper buffer handling within the ISAPI extension.

How can I tell if I'm running SQLXML?
If you are running SQL Server 2000 and have enabled the SQLXML HTTP components on an IIS server, you should install the patch.

There are three different patches. Which do I need to install?
It depends on which version of SQLXML you're using. SQL Server 2000 shipped with an initial version of SQLXML, so at a minimum you should install the patch for SQL Server 2000 Gold. But there have been three subsequent versions available for download.

I don't know which versions of SQLXML I've installed. How can I tell?
The following lists how to determine the versions of SQLXML installed and what actions you should take:

• In the start menu on the IIS server, check to see if you have a program group for "Microsoft SQL Server" which contains the program "Enterprise Manager". If you have the program then you have the version of SQLXML that shipped with SQL Server Gold installed and should install the patch for that version.

  There are two packages for the SQLXML version that shipped with SQL Server Gold, you should choose the version that corresponds to the version of MDAC you are using. Check the HKEY_LOCAL_MACHINE/Software/Microsoft/DataAccess/FullInstallVer/ registry key and look for a number starting with 2.6 (for MDAC version 2.6) or 2.7 (for MDAC version 2.7).

  If you get a message during the installation of the patch saying you have SQLXML version 1, then you should upgrade to a later version of SQLXML using the instructions below, as SQLXML version 1 is no longer supported.

• Search for the Sqlvdr2.dll on the IIS server. If found, then install the patch for SQLXML 2.0.
• Search for the Sqlvdr3.dll on the IIS server. If found, then install the patch for SQLXML 3.0

I've got more than one of the these versions installed. Which patch do I need to apply?
You'll need to apply the patch for each of the versions you've installed.

How do I upgrade from SQLXML version 1?
The latest version of SQLXML can be downloaded from http://msdn2.microsoft.com/en-us/library/Aa286527.aspx, and can also be found by searching at http://www.microsoft.com/downloads.
After you have installed the new SQLXML, there will be an IIS configuration tool which allows you to set properties of a virtual directory. There is a button provided for upgrading to the new version of SQLXML, click this button to complete the upgrade from SQLXML version 1.

Script injection via XML tag (CVE-CAN-2002-0187)

What's the scope of the second vulnerability?
This is an elevation of privilege vulnerability. An attacker who was able to successfully exploit this vulnerability would be able to cause scripts to run on another user's system in the IE Security Zone associated with the IIS Server running SQLXML HTTP components.
The vulnerability is subject to a number of significant mitigating factors:

• It could only be exploited against a user who had permissions to query an affected SQL server.
• The attacker would need to possess significant information, including the name of the affected SQL server
• In most cases, the script would run in the Intranet Zone, which has no significant differences from the security zone that the attacker's own web site would be placed in.

What causes the vulnerability?
The vulnerability results because one of the parameters that can be included in an XML SQL query, known as Root, isn't correctly validated. If script were included in the Root parameter as part of a SQL query, that script would be included in the reply from the server. If rendered within a browser, the script would execute in the IE Security Zone associated with the IIS Server running SQLXML HTTP components.

What's the Root parameter?
Root is a parameter that can be included in an SQLXML request to ensure that the query results will comprise well-formed XML. It does this by ensuring that the query result will be a full XML document with only a single top-level XML tag in the query result.
For instance, suppose a query result would ordinarily look like this:

<Customers CustomerID="ALFKI" CompanyName="Alfreds Futterkiste" />
<Customers CustomerID="ANATR" CompanyName="Ana Trujillo Emparedados y helados" />

In some cases, the fact that there are multiple Customers tags could complicate the processing of the result. By including the Root parameter, the result of the query could look like this:

<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<Customers CustomerID="ALFKI" CompanyName="Alfreds Futterkiste" />
<Customers CustomerID="ANATR" CompanyName="Ana Trujillo Emparedados y helados" />
</ROOT>

What's wrong with how SQLXML handles the Root parameter?
SQLXML should ensure that the value of the parameter doesn't include script. However, it doesn't do so, with the result that if an XML database request included script in the Root parameter, SQLXML would include the script in the response. If the response were subsequently rendered in a browser, the script would run.

What would this enable an attacker to do?
Under a daunting scenario, the vulnerability could provide an attacker with an avenue by which to run script on another user's system.
Suppose the attacker hosted a web site and was able to lure a user into visiting it and clicking a link on it. That link could submit an XML query to a SQL server. If the query contained script in the Root parameter of the query, the script would be embedded in the resulting response from the server, and would execute in the user's browser when the response was rendered.

What would this gain the attacker? Couldn't he have just run the script directly when the user clicked on the link?
The attacker's web page could indeed have run script directly when the user clicked on the link. However, the script would run in the IE Security Zone associated with the attacker's web site (by default, the Internet Zone). By using the vulnerability, the attacker's script would run in the Security Zone associated with the IIS Server running SQLXML HTTP components.

What zone would the script run in?
It would depend on the specific scenario, but in most cases the IIS Server running the SQLXML components would be an intranet server and the script would therefore run in the Intranet Zone. This would usually gain the attacker very few additional privileges. The default settings for the Intranet Zone are exactly the same as those for the Internet Zone, with three exceptions, none of which would allow destructive action:

• Java permissions. This setting defaults to "medium" in the Intranet Zone, but "high" in the Internet Zone
• Access data sources across domains. This is set to "prompt" in the Intranet Zone, but "disable" in the Internet zone.
• Don't prompt for certificate selection when no certificate or only one certificate exists. This is set to "enable" in the Intranet Zone, but "disable" in the Internet Zone.

Could the attacker exploit this vulnerability against any user who visited his web site?
No. The attacker could only exploit the vulnerability if all of the following were true:

• The user had access to a IIS Server running SQLXML HTTP components that had not been patched.
• The user had been given permissions by the SQL administrator to levy queries on the server.
• The attacker knew the name of the virtual directory that has been set up on the IIS Server for SQLXML HTTP components. In most cases, this would require the attacker to be an insider on the user's network.

Could this vulnerability be exploited by accident?
No. The vulnerability could only be exploited by an attacker who sent specially malformed data to the Root parameter.

How do the patches eliminate this vulnerability?
The patches eliminates the vulnerability by instituting proper validity checking on the Root parameter.

How can I tell if I need to apply a patch?
See the section above.

Download locations for this patch

• Microsoft SQLXML version shipping with SQL 2000 Gold:

  http://www.microsoft.com/downloads/details.aspx?FamilyID=cf3f644b-f68f-4ec9-8808-34860f9dc31f&DisplayLang=en

• Microsoft SQLXML version 2:

  http://www.microsoft.com/downloads/details.aspx?FamilyID=b10fdc29-ba8e-4869-98e4-08464b2c8dd3&DisplayLang=en

• Microsoft SQLXML version 3:

  http://www.microsoft.com/downloads/details.aspx?FamilyID=05f1a309-be6e-49fe-968d-9833fa15cc12&DisplayLang=en