Microsoft Security Bulletin MS02-034 - Cumulative Patch for SQL Server available. This patch eliminates three newly found vulnerabilities affecting SQL Server 2000 and MSDE 2000: 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.
6f6531c6b91284feb309e4db2c188f2ca99bcdad24d52e72a0bcc22cc91660e6 TechNet Home > Security > Bulletins
Microsoft Security Bulletin MS02-034
[Print] Print
Cumulative Patch for SQL Server (Q316333)
Originally posted: July 10, 2002
Summary
Who should read this bulletin: Database administrators using
Microsoft® SQL Server™ or Microsoft SQL Server Desktop Engine
(MSDE) 2000.
Impact of vulnerability: Three new vulnerabilities, the most
serious of which could run code of attacker’s choice on server.
Maximum Severity Rating: Moderate
Recommendation: Apply the patch immediately to affected systems.
Affected Software:
* Microsoft SQL Server 2000 all editions.
* Microsoft SQL Server Desktop Engine (MSDE) 2000.
Technical details
Technical description:
This is a cumulative patch that 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.
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 was 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.
Severity Rating:
Unchecked Buffer in Password Encryption Procedure
Internet Intranet
Servers Servers Client Systems
SQL Server 2000
(Including MSDE 2000) Moderate Moderate Moderate
Unchecked Buffer in Bulk Insert Procedure
Internet Intranet
Servers Servers Client Systems
SQL Server 2000
(Including MSDE 2000) Moderate Moderate Moderate
Incorrect Permission on SQL Server Service Account Registry Key
Internet Intranet
Servers Servers Client Systems
SQL Server 2000
(Including MSDE 2000) Moderate Moderate Moderate
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. In the case of the
Unchecked Buffer in Bulk Insert Procedure, the vulnerability could only
enable members of the Bulk Admin group to run code in an elevated security
context. The incorrect permission on SQL Server Service Account Registry
Key vulnerability would require that the attacker have the ability to load
and run queries in order to exploit it.
Vulnerability identifier:
* Unchecked Buffer in Password Encryption Procedure: CVE-CAN-2002-0624
* Unchecked Buffer in Bulk Insert Procedure: CVE-CAN-2002-0641
* Incorrect Permission on SQL Server Service Account Registry Key:
CVE-CAN-2002-0642
Tested Versions:
Microsoft tested SQL Server 7.0 and SQL Server 2000 to assess whether they
are affected by this vulnerability. SQL Server 7 is not affected by any of
the vulnerabilities. Previous versions are no longer supported and may or
may not be affected by this vulnerability.
Frequently asked questions
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’s 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
(CVE-CAN-2002-0624):
What’s 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’s involved in
the latter type of authentication, and which provides support for
the storage of SQL Server Authentication credentials.
What's wrong with the SQL Server password encryption function?
The function in question suffers from an unchecked buffer in a
section of code which 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 (CVE-CAN-2002-0641):
What’s 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's wrong with the Bulk Insert function?
The function in questions suffers from an unchecked buffer in a
section of code which 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’s 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 can’t 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
(CVE-CAN-2002-0642):
What’s 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. As a
result 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's 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's 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. As a consequence, it is possible for the
SQL Server process to specify a different service account,
including LocalSystem, which is an account with the full
priviliges 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.
Patch availability
Download locations for this patch
* Microsoft SQL Server 2000:
http://support.microsoft.com/support/misc/kblookup.asp?id=Q316333
Additional information about this patch
Installation platforms:
The SQL Server 2000 patch can be installed on systems running SQL
Server 2000 Service Pack 2.
Inclusion in future service packs:
The fixes for these issues will be included in SQL Server 2000
Service Pack 3.
Reboot needed: No. The SQL Server service only needs to be
restarted after applying the patch.
Superseded patches: This pach supercedes the one provided in
Microsoft Security Bulletin MS02-020, which was itself a
cumulative patch.
Verifying patch installation:
SQL Server 2000
* To ensure you have the fix installed properly, verify the
individual files by consulting the date/time stamp of the
files listed in the file manifest in Microsoft Knowledge
Base article at
http://support.microsoft.com/support/misc/kblookup.asp?id=
Q316333
Caveats:
This package doesn’t contain the Microsoft Data Access Component
or the Analysis Services security fixes.
Localization:
Packages for each supported SQL Server language is being made
available. A localized Readme.txt file is included in each
package for installation instructions.
Obtaining other security patches:
As previously mentioned, these vulnerabilities do not exist on
SQL Server 7.0. If you are still running SQL Server, ensure you
are running SQL Server 7.0 Service Pack 4 where the other
security vulnerabilities were addressed. If you are running
Service Pack 3 for SQL Server 7.0, you should upgrade to Service
Pack 4 or apply the Service Pack 3 update at
http://support.microsoft.com/support/misc/kblookup.asp?id=Q318268
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 Cesar Cerrudo and Mark Litchfield of Next
Generation Security Software Ltd. for reporting the Unchecked
Buffer in Bulk Update Procedure to us and working with us to
protect customers.
Support:
* Microsoft Knowledge Base article Q316333 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 July 10, 2002 Bulletin Created.
Contact Us | E-mail this Page | TechNet Newsletter
© 2002 Microsoft Corporation. All rights reserved. Terms of Use Privacy Statement Accessibility
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed