[NT] SQL Server Remote Data Source Function Buffer Overflows

From: support@securiteam.com
Date: 02/21/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Thu, 21 Feb 2002 14:06:27 +0100 (CET)

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.
- - - - - - - - -

  SQL Server Remote Data Source Function Buffer Overflows
------------------------------------------------------------------------

SUMMARY

One of the features of Structured Query Language (SQL) in SQL Server 7.0
and 2000 is the ability to connect to remote data sources. One capability
of this feature is the ability to use "ad hoc" connections to connect to
remote data sources without setting up a linked server for less-often used
data-sources. This is made possible using OLE DB providers, which are
low-level data source providers. This capability is made possible by
invoking the OLE DB provider directly by name in a query to connect to the
remote data source.

An unchecked buffer exists in the handling of OLE DB provider names in ad
hoc connections. A buffer overrun could occur as a result and could be
used to either cause the SQL Server service to fail, or to cause code to
run in the security context of the SQL Server. SQL Server can be
configured to run in various security contexts, and by default runs as a
domain user. The precise privileges the attacker could gain would depend
on the specific security context that the service runs in.

An attacker could exploit this vulnerability in one of two ways. They
could attempt to load and execute a database query that calls one of the
affected functions. Conversely, if a web site or other database front-end
were configured to access and process arbitrary queries, it could be
possible for an attacker to provide inputs that would cause the query to
call one of the functions in question with the appropriate malformed
parameters.

DETAILS

Vulnerable systems:
 * Microsoft SQL Server 7.0
 * Microsoft SQL Server 2000

Mitigating factors:
 * The effect of exploiting the vulnerability would depend on the specific
configuration of the SQL Server service. SQL Server can be configured to
run in a security context chosen by the administrator. By default, this
context is as a domain user. If the rule of least privilege has been
followed, it would minimize the amount of damage an attacker could
achieve.
 * Both vectors for exploiting the vulnerability could be blocked by
following best practices. Specifically, untrusted users should not be able
to load and execute queries of their choice on a database server. In
addition, publicly accessible database queries should filter all inputs
prior to processing.

Patch availability:
Download locations for this patch SQL Server 7.0:
 * The patch for this issue is available in the SQL Server 7.0 Cumulative
Security patch at:
    <http://support.microsoft.com/support/misc/kblookup.asp?id=Q318268>
http://support.microsoft.com/support/misc/kblookup.asp?id=Q318268
SQL Server 2000:
 * The patch for this issue is available in the SQL Server 2000 Cumulative
Security patch at
<http://support.microsoft.com/support/misc/kblookup.asp?id=Q316333>
http://support.microsoft.com/support/misc/kblookup.asp?id=Q316333

What is the scope of the vulnerability?
This is a buffer-overrun vulnerability. An attacker who successfully
exploited this vulnerability would gain significant control over the
database and possibly the server itself. In a worst case, the attacker
could add, change, or delete data in the database, as well as potentially
being able to reconfigure the operating system, install new software, or
reformat the hard drive.

The scope of this vulnerability, however, would be significantly reduced
if best practices were followed. Specifically:
 * SQL Server can be configured to run in a security context accordance
with the rule of least privilege. By default, SQL Server runs in the
security context of a domain user, a context with very limited privileges
on the server. If this were done, it would have the effect of limiting the
potential actions an attacker could take in the event of a successful
attack.
 * In addition to successfully exploit this vulnerability, the attacker
would need to be able to load and run a query of his construction on the
server, or be able to pass information of their choosing into an existing
query on the system. Best practices recommends against both of these
practices.

What causes the vulnerability?
The vulnerability results because several functions provided by SQL Server
contain unchecked buffers. Specifically in functions that are associated
with connecting to remote data sources through "ad hoc names". By calling
any of these functions with specially chosen parameters, an attacker could
cause a buffer-overrun condition to occur.

What are "ad hoc names"?
SQL Server provides the ability to connect to pull information from remote
data sources on a variety of platforms to allow for data warehousing,
analysis, and aggregation. Connections to remote data sources can be
accomplished in one of two ways. By establishing a "linked server"
connection for regular, ongoing connections, or using "ad hoc names" for
connections that may be established less often.

What is wrong with the functions?
The functions impacted by this vulnerability have the same defect: they
fail to properly validate that information which is passed will fit into
the buffer that has been provided. Because of this, an attacker could
provide text that overruns the buffer and overwrites the memory within the
SQL Server process itself.

What would this enable an attacker to do?
Depending on the specific data that the attacker chose, one of two effects
could result:
 * If the data were random data, the SQL Server process would fail.
 * If the were carefully selected, it could be possible for the attacker
to alter the SQL Server software while it was running.

If the attacker provided random data as the text, what would be required
in order to restore normal operation?
The administrator would need to restart the SQL Server service.

If the attacker provided carefully selected data and altered the SQL
Server software, what could the new software do?
It would depend on how SQL Server had been configured. By default, SQL
Server runs in a non-privileged security context (specifically, as a
domain user). An attacker who successfully exploited this vulnerability
against a server configured in this manner would gain control over the
database, but little else. If, however, the administrator had configured
SQL Server to run with higher privileges, a successful attack could
possibly gain those additional privileges. Thus, the potential damage of a
successful attack is proportionate to the degree to which the principle of
least privilege has been followed in the configuration of SQL Server.

How might an attacker exploit this vulnerability?
There are several ways an attacker would try to exploit this
vulnerability. The most direct attack vector would be for the attacker to
construct a query that calls one of the affected functions and performs a
buffer-overrun attack. However, to succeed at this, the server would have
to be configured to allow an untrusted user to load and execute queries of
their choice. Best practices strongly recommends against allowing
untrusted users to load and run queries of their construction.

Is there any other way an attacker would try to exploit this
vulnerability?
If an attacker were unable to load and run a query of their choosing, they
could attempt to exploit this vulnerability by using a query that was
already present on the system.

For example, if the database were part of a web-based search tool and one
of the functions in question were called by the web site, an attacker
could attempt to construct a query that would exploit this vulnerability.
However, constructing a query like this would require intimate knowledge
about the internals of a web site's search function.

If a site had implemented web-based queries without proper checking of
inputs, however, it could be possible for an attacker to embed database
commands, including calls to the affected functions - within the database
query parameters. This shows the importance of validating input parameters
before passing them to the database server for processing.

What does the patch do?
The patch eliminates the vulnerability by implanting proper checking into
the affected functions.

ADDITIONAL INFORMATION

The information has been provided by <mailto:secure@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