Security Bulletin

Microsoft Security Bulletin MS02-038 - Moderate

Unchecked Buffer in SQL Server 2000 Utilities Could Allow Code Execution (Q316333)

Published: July 24, 2002 | Updated: July 29, 2002

Version: 1.1

Originally posted: July 24, 2002

Summary

Who should read this bulletin: System administrators using Microsoft® SQL Server™ 2000 and Microsoft Desktop Engine 2000.

Impact of vulnerability: Two vulnerabilities, both of which could enable an attacker to run code on the server.

Maximum Severity Rating: Moderate

Recommendation: System administrators should consider installing the patch.

Affected Software:

• Microsoft SQL Server 2000.
• Microsoft Desktop Engine (MSDE) 2000

General Information

Technical details

Technical description:

This patch eliminates two newly discovered vulnerabilities affecting SQL Server 2000 and MSDE 2000:

• A buffer overrun vulnerability that occurs in several Database Consistency Checkers (DBCCs) that ship as part of SQL Server 2000. DBCCs are command console utilities that allow maintenance and other operations to be performed on a SQL Server. While many of these are executable only by sysadmin, some are executable by members of the db_owner and db_ddladmin roles as well. In the most serious case, exploiting this vulnerability would enable an attacker to run code in the context of the SQL Server service, thereby giving the attacker complete control over all databases on the server.
• A SQL injection vulnerability that occurs in two stored procedures used in database replication. One of these can only be run by users who have been assigned the db_owner role; the other, due to a permissions error, could be run by any user who could log onto the server interactively. Exploiting the vulnerability could enable an attacker to run operating system commands on the server, but is subject to significant mitigating factors as discussed below.

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.
• Exploiting the vulnerability successfully would enable the attacker to gain the privileges of the SQL Server account. However, by default this account has only domain user privileges on the server.

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.

Severity Rating:

Buffer Overrun Vulnerability in Database Consistency Checkers:

SQL Injection Vulnerability in Replication Stored Procedures:

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. The Buffer Overrun vulnerability in Database Consistency Checkers has been rated as a moderate-risk vulnerability because it could only be exploited by a user who already had significant privileges on the system. The SQL Injection vulnerability in replication stored procedures has been rated as a low-risk vulnerability because it could not be exploited under default conditions.

Vulnerability identifiers:

• Buffer overrun vulnerability in Database Consistency Checkers: CAN-2002-0644
• SQL injection vulnerability in replication stored procedures: CAN-2002-0645

Tested Versions:

Microsoft tested SQL 7.0 and 2000 (and their associated versions of MSDE) to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

Frequently asked questions

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's 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 (CVE-2002-0644):

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 on the basis of 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 doesn't 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 don't 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 don't properly check input parameters before using them. If a user executed one of the affected DBCCs using a specially 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 wouldn't 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 wouldn't 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 are 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 (CVE-2002-0645):

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 the purpose of 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 a SQL Injection vulnerability. SQL Injection vulnerabilities typically occur when a program doesn't properly validate its inputs before using them. That's exactly the case for the two stored procedures at issue here - they don't 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 can be executed by any user who can log onto the server interactively. However, there's an important additional factor to keep in mind. It's 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 could enable an attacker who could 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 didn't 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.

Patch availability

Download locations for this patch

• SQL Server 2000:

  https:

Additional information about this patch

Installation platforms:

This patch can only be installed on systems running SQL Server 2000 Service Pack 2.

Inclusion in future service packs:

The fix for this issue will be included in SQL Server 2000 Service Pack 3.

Reboot needed: No. The SQL Server and SQL Agent services only needs to be restarted after applying the patch

Patch can be uninstalled: Yes. The readme.txt describing the installation instructions also contains instructions on removing the patch.

Superseded patches: This patch supersedes the one provided in Microsoft Security Bulletin MS02-034, which was itself a cumulative patch.

Verifying patch installation:

• 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 </https:>https:

Caveats:

• This patch does not include the functionality of the Killpwd tool provided in Microsoft Security Bulletin MS02-035.
• The patch does not supersede any previously released patches for MDAC or OLAP under SQL Server 2000. At this writing, these patches include the ones discussed in:
  • Microsoft Security Bulletin MS00-092
  • Microsoft Security Bulletin MS01-041
  • Microsoft Security Bulletin MS02-030
• The process for installing the patch varies somewhat depending on the specific configuration of the server. System administrators should ensure that they read the Readme.txt file in the patch package to ensure the patch is installed correctly.

Localization:

Localized versions of this patch are available at the locations discussed in "Patch Availability".

Obtaining other security patches:

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

Other information:

Acknowledgments

Microsoft thanks Cesar Cerrudo for reporting this issue 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 24, 2002): Bulletin Created.
• V1.1 (July 29, 2002): Caveats section updated to remove erroneous statement that MS02-020 was not superseded.

Built at 2014-04-18T13:49:36Z-07:00 </https:>