[NT] Cumulative Patch for SQL Server

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


From: support@securiteam.com
To: list@securiteam.com
Date: Thu, 11 Jul 2002 11:38:12 +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.
- - - - - - - - -

  Cumulative Patch for SQL Server
------------------------------------------------------------------------

SUMMARY

This cumulative patch includes the functionality of all previously
released patches for SQL Server 2000. In addition, it eliminates three
newly discovered vulnerabilities affecting SQL Server 2000 and MSDE 2000
(but not any previous versions of SQL Server or MSDE):
 * A buffer overrun vulnerability in a procedure used to encrypt SQL
Server credential information. An attacker who was able to successfully
exploit this vulnerability could gain significant control over the
database and possibly the server itself depending on the account SQL
Server runs as.
 * A buffer overrun vulnerability in a procedure that relates to the bulk
inserting of data in SQL Server tables. An attacker who was able to
successfully exploit this vulnerability could gain significant control
over the database and possibly the server itself.
 * A privilege elevation vulnerability that results because of incorrect
permissions on the Registry key that stores the SQL Server service account
information. An attacker who was able to successfully exploit this
vulnerability could gain greater privileges on the system than had been
granted by the system administrator -- potentially even the same rights as
the operating system.

DETAILS

Vulnerable systems:
 * Microsoft SQL Server 2000 all editions.
 * Microsoft SQL Server Desktop Engine (MSDE) 2000.

Mitigating factors:
Unchecked Buffer in Password Encryption Procedure:
 * 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 default were chosen, it would minimize
the amount of damage an attacker could achieve.
 * 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.

Unchecked Buffer in Bulk Insert Procedure:
 * An attacker would need to already possess significant rights on the
server in order to exploit the vulnerability, as only Bulk Admins and full
administrators have the ability to load and run queries that invoke the
vulnerable procedure.
 * 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, it runs
in the context of a domain user; if chosen, this would minimize the amount
of damage an attacker could achieve.
 * Best practices could help minimize the vulnerability. 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.

Incorrect Permission on SQL Server Service Account Registry Key:
 * Successfully exploiting this vulnerability would require the ability to
load and run queries on the system. By following best practices and
limiting this ability to administrators, users can mitigate the threat
posed by this vulnerability.
 * Successfully exploiting this vulnerability would also require a
sysadmin or someone that has been granted xp_regwrite execute permissions.

Patch availability:
Download locations for this patch
 * Microsoft 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 is a cumulative patch that, when applied, address all previously
addressed vulnerabilities. In addition, it eliminates three new
vulnerability:
 * A buffer overrun vulnerability in a procedure that handles password
encryption for SQL Server authentication that could enable code of an
attacker's choice to be run in the same context as the SQL Server.
 * A buffer overrun vulnerability in a procedure that handles bulk
inserting of database tables that could enable an attacker's code to run
in the SQL Server Service Account's security context.
 * A privilege elevation vulnerability that could enable an attacker to
gain the ability to execute SQL Server commands in the security context of
the operating system.

What is MSDE, and how is it related to SQL Server?
Microsoft Data Engine (MSDE) is a database engine that has built and based
on SQL Server 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 1.0 is based on SQL Server 7.0 technology;
MSDE 2000 is based on SQL Server 2000.

The vulnerabilities described here involves MSDE 2000 based on SQL Server
2000.

Unchecked Buffer in Password Encryption Procedure:
What is the scope of the first vulnerability?
This is a buffer-overrun vulnerability. An attacker who was able to
successfully exploit this vulnerability could gain significant control
over the database and possibly the server itself depending on the account
SQL Server runs as. In a worst case, the attacker could add, change, or
delete data or configuration information on the database or operating
system.

In order to exploit this vulnerability, an attacker would need to be a
valid login within SQL Server and be able to load and run a query on the
server, or be able to pass uncontrolled information into an existing query
on the system. Best practices strongly recommends against both of these
practices.

What causes the vulnerability?
The vulnerability results because of an unchecked buffer in a SQL Server
function that handles the encryption of passwords for accounts that use
SQL Server Authentication. By calling this function with specially chosen
parameters, an attacker could cause a buffer-overrun condition to occur.

What is SQL Server Authentication?
SQL Server can be configured to authenticate users in either of two ways:
via Windows Authentication, which relies on Windows to store and
authenticate user credentials, or SQL Server Authentication, in which SQL
Server performs the authentication by comparing the username and password
against information that is stored locally within tables in SQL Server
itself. The vulnerability involves a SQL Server function that is involved
in the latter type of authentication, and which provides support for the
storage of SQL Server Authentication credentials.

What is wrong with the SQL Server password encryption function?
The function in question suffers from an unchecked buffer in a section of
code that handles input. Because of this, it is possible for an attacker
to call the function and provide it with input so that the buffer is
overrun and the memory within the SQL Server process is overwritten.

What could this vulnerability enable an attacker to do?
An attacker who was able to successfully exploit this vulnerability could
seek to execute code in the context of SQL Server service account on the
SQL Server. The specific actions that the attacker's code could take would
depend on the security context that SQL Server was running in at the time
of the attempt to exploit the vulnerability. (It is worth noting, that the
third vulnerability discussed below could potentially provide a way to
change the security context of the SQL Server service).

By default, SQL Server runs in a non-privileged security context as a
domain-user. An attempt to exploit this vulnerability against a system
running in this manner would gain control over the database, but little,
if any control, over the system itself. If, however, the SQL Server had
been configured to run in a security context with higher privileges, a
successful attempt to exploit this vulnerability would yield a higher
degree of control over the system. For example, if the server were running
in the context of LocalSystem, then the attacker's program would have the
same rights as the operating system itself, and could take any action on
the system including, but not limited to, adding, changing or deleting
data, altering the security settings, or adding privileged accounts.

How could an attacker exploit this vulnerability?
The most likely way an attacker could attempt to exploit this
vulnerability would be to pass a query to the database server that called
the function in question with specially formed parameters. The attacker
would either have to be able to fully build and run queries on the system,
or find a means to input this as part of an existing query on the system.
In either circumstance, once the query is processed and the buffer
overrun, the attack would be carried out.

Is there anything that I can do that would mitigate against attempts to
exploit this vulnerability?
Yes. An attempt to exploit this vulnerability would require that the
attacker have the means to pass uncontrolled data to the database server.
If best practices limiting this ability have been followed, attempts to
exploit this vulnerability could be mitigated or completely thwarted.
Specifically, if database administrators ensure that only authorized
administrators and dba's can load and run queries, and that existing
queries strictly enforce checking and verification of data accepted as
inputs to queries, an attacker's ability to exploit this vulnerability
would be significantly if not completely impaired.

In addition, following these best practices helps limit exposure to other
issues that might arise due to mis-configuration such as SQL injection
attacks for web-exposed data sources.

How does the patch eliminate the vulnerability?
The patch eliminates the vulnerability by ensuring that the input buffer
in the password encryption function is properly validated.

Unchecked Buffer in Bulk Insert Procedure:
What is the scope of the second vulnerability?
This is a buffer-overrun vulnerability. An attacker who was able to
successfully exploit this vulnerability could gain significant control
over the database and possibly the server itself. In a worst case, the
attacker could add, change, or delete data or configuration information on
the database or operating system.

In the case of this particular vulnerability, an attacker would need to
have an account with at least Bulk Administrator privileges and be able to
load and run a query on the server. This significantly limits the exposure
of the vulnerability.

What causes the vulnerability?
The vulnerability results because of an unchecked buffer in a SQL Server
procedure that is used for the inserting of bulk data. As a result, it is
possible for an attacker who can invoke this procedure to seek to levy a
buffer-overrun attack.

What do you mean by "inserting of bulk data"?
There is a command in SQL that allows bulk copying of data from data files
into a database table or view in a user specified format. Only members of
the sysadmin and bulkadmin fixed server roles can execute this command.

What is wrong with the Bulk Insert function?
The function in questions suffers from an unchecked buffer in a section of
code that handles input. Because of this, it is possible for an attacker
to call the function and provide it with input so that the buffer is
overrun and the memory within the SQL Server process is overwritten.

What could this vulnerability enable an attacker to do?
This vulnerability could enable an attacker who was able to invoke this
procedure to run code on the system in the context of the SQL Server
service account. As discussed above, the SQL Server account by default has
only Domain User privileges, but can be configured to run with higher
privileges.

How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by loading and
running a query that calls the affected function. It is worth reiterating
that the attacker would need to be a member of the Bulk Administrators
group to do this. By default, this group has no members.

The Severity Rating Table says this vulnerability poses no risk on SQL
7.0. Why is this?
Although SQL 7.0 does contain the Bulk Insert procedure, and it does
contain the buffer overrun, the vulnerability cannot be used to attack a
system. In SQL 7.0, only members of the Administrators group can call the
Bulk Insert procedure - but administrators already have full control over
the server, so there would be no gain in doing this.

How does the patch eliminate the vulnerability?
The patch eliminates the vulnerability by implementing proper checking of
the input buffer in the bulk inserting procedure.

Incorrect Permission on SQL Server Service Account Registry Key:
What is the scope of the third vulnerability?
This is a privilege elevation vulnerability. An attacker who was able to
successfully exploit this vulnerability could gain greater privileges on
the system than had been granted by the system administrator --
potentially even the same rights as the operating system.

A successful attack would require that the attacker be able to load and
run queries on the database server. In addition, the service would have to
be stopped and restarted before the attacker would have the elevated
privileges.

What causes the vulnerability?
The vulnerability results because incorrect permissions are assigned to a
part of the registry that contains information regarding the service
account which SQL Server runs under. It is possible for the SQL Server
service to write to the registry and specify a different service account,
including LocalSystem. Because of this, it is possible for the SQL Server
service to run in a different, more privileged account than that granted
by the system administrator.

What is the SQL Server Service Account?
In the Windows security model, all activity on a system occurs with the
context of a security account. This ensures that every action on a system
can be checked to ensure that it is authorized and audited. For example,
all actions taken by the operating system itself occur in the context of
the LocalSystem account.

When SQL Server is installed, the security account within which it will
take all of its actions must be specified by the administrator. After the
administrator has specified what account SQL Server will use, this
information is stored in the Registry, where it is used when the service
starts.

SQL Server by default will run in the context of a non-privileged user on
the operating system. This means that the SQL Server service itself can
take very few actions on the system by default.

What is the Registry?
The Registry is the central repository where Windows stores configuration
information for both the operating system and applications.

The Registry provides a single location where operating system settings
(devices information, boot sequence, network configuration) application
settings (tuning information, configuration parameters), and user settings
(user preferences, recently used short cuts) can all be stored.

What is wrong with how the SQL Server Service Account Information is
stored?
The part of the Registry where the SQL Server Service Account information
is stored has an inappropriate permission. Specifically, the SQL Server
Service account has the right to change this information. Therefore, it is
possible for the SQL Server process to specify a different service
account, including LocalSystem, which is an account with the full
privileges of the operating system itself. The next time the SQL Server
Service starts after this change is made, it would then run in the context
of that account. The net effect of this is that it is possible for the SQL
Server service to run with greater privileges on the system than the
system administrator granted .

What could this vulnerability enable an attacker to do?
This vulnerability could enable an attacker to raise the privileges of the
SQL Server Service to equal those of the operating system itself. Since
SQL Server provides the means to execute operating system commands in its
own security context on behalf of operators, the net effect of this
vulnerability is that an attacker who was able to load and run queries
could ultimately execute any command on the system with the same rights as
the operating system itself. Thus, an attacker could change the
configuration of the operating system, add administrative accounts, or
change the security settings of the system.

How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by loading and
running a query on the SQL Server that would tell the server to change the
service account information in the Registry.

The effects of this attack, however, would not be seen until the next time
the service started after the attack. Until the server was restarted, it
would continue to run in its original security context. Once the server
restarted, it would be running in the context of the newly specified
service account. At that point, any operating system commands that the SQL
Server executed would be carried out with the rights and permissions of
the new service account.

How does the patch eliminate the vulnerability?
The patch eliminates the vulnerability by changing the permissions on the
Registry key to ensure that the SQL Server cannot change this setting.

ADDITIONAL INFORMATION

The information has been provided by
<mailto:0_33448_E51E4D7D-DECD-43AE-9A29-36080E8D4C3C_US@Newsletters.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.