Microsoft Security Bulletin MS02-034

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

Unchecked Buffer in Bulk Insert Procedure

Incorrect Permission on SQL Server Service Account Registry Key

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.

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.

Download locations for this patch

• Microsoft SQL Server 2000:

  http://support.microsoft.com/default.aspx?scid=kb;en-us;316333