[NT] Unchecked Buffer in SQLXML Could Lead to Code Execution

From: support@securiteam.com
Date: 06/13/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Thu, 13 Jun 2002 00:31:59 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Unchecked Buffer in SQLXML Could Lead to Code Execution
------------------------------------------------------------------------

SUMMARY

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.

DETAILS

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

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.

Patch availability:
Download locations for this patch
 * Microsoft SQLXML version shipping with SQL 2000 Gold:
     <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=39547>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=39547
 * Microsoft SQLXML version 2:
     <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=38480>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=38480
 * Microsoft SQLXML version 3:
     <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=38481>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=38481

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
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 eliminate 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 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> http://msdn.microsoft.com/sqlxml, and
can also be found by searching at <http://www.microsoft.com/downloads>
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
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
especially malformed data to the Root parameter.

How do the patches eliminate this vulnerability?
The patches eliminate 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.

ADDITIONAL INFORMATION

The information has been provided by <mailto:secnotif@MICROSOFT.COM>
Microsoft Product Security.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages