TechNet Home > Security > Bulletins

Microsoft Security Bulletin MS02-030
[Print] Print

Unchecked Buffer in SQLXML Could Lead to Code Execution (Q321911)

Originally posted: June 12, 2002

Summary

Who should read this bulletin: System administrators using Microsoft® SQL
Server™ 2000.

Impact of vulnerability: Two vulnerabilities, the most serious of which could
run code of attacker’s choice.

Maximum Severity Rating: Moderate

Recommendation: System administrators who have enabled SQLXML and enabled data
queries over HTTP should install the patch immediately.

Affected Software:

* Microsoft SQLXML, which ships as part of SQL Server 2000 and can be
downloaded separately.

Technical details

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:
Internet Intranet
Servers Servers Client Systems

Microsoft SQLXML version shipped
with SQL Server 2000 Gold Moderate Moderate None

Microsoft SQLXML version 2 Moderate Moderate None

Microsoft SQLXML versions 3 Moderate Moderate None

Script injection via XML tag:
Internet Intranet
Servers Servers Client Systems

Microsoft SQLXML version shipped
with SQL Server 2000 Gold Moderate Moderate None

Microsoft SQLXML version 2 Moderate Moderate None

Microsoft SQLXML versions 3 Moderate Moderate None
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.

Frequently asked questions

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://msdn.microsoft.com/sqlxml, 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:

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:

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.

Patch availability

Download locations for this patch

* Microsoft SQLXML version shipping with SQL 2000 Gold:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=39547
* Microsoft SQLXML version 2:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=38480
* Microsoft SQLXML version 3:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=38481

Additional information about this patch

Installation platforms:
This patch can be installed on systems running SQL Server 2000 SP2

Inclusion in future service packs:
The fix for this issue will be included in SQL Server 2000 SP3.

Reboot needed: Yes

Superseded patches: None.

Verifying patch installation:

SQLXML shipping with SQL Server 2000 Gold:

* 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\DataAccess\Q321858

SQLXML Version 2.0:

* 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\SQLXML 2.0\Q321460

SQLXML Version 3.0:

* 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\SQLXML 3.0\Q320833

Caveats:
None

Localization:
This patch can be applied on all language versions.

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
* All patches available via WindowsUpdate also are available in a
redistributable form from the WindowsUpdate Corporate site.

Other information:

Acknowledgments

Microsoft thanks Matt Moore of Westpoint Ltd. for reporting this issue to us
and working with us to protect customers.

Support:

* Microsoft Knowledge Base article Q321911 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 (June 12, 2002): Bulletin Created.