‘Cumulative Patch for SQL Server’
‘This is a cumulative patch that includes the functionality of all previously released patches for SQL Server 7.0 and SQL Server 2000. In addition, it eliminates a newly discovered vulnerability.
SQL Server 7.0 and SQL Server 2000 provide for extended stored procedures, which are external routines written in programming languages such as C or C#. These procedures appear as normal stored procedures to users and can be invoked and executed just like normal stored procedures. By default, SQL Server 7.0 and SQL Server 2000 ship with a number of extended stored procedures that are used for various helper functions.
Some of the Microsoft-provided extended stored procedures that have the ability to reconnect to the database as the SQL Server service account have a flaw in common – namely, they have weak permissions that can allow non-privileged users to execute them. Because these extended stored procedures can be made to run with administrator privileges on the database, it is thus possible for a non-privileged user to run stored procedures on the database with administrator privileges.
An attacker could exploit this vulnerability in one of two ways. The attacker could attempt to load and execute a database query that calls one of the affected extended store procedures. Alternately, if a web site or other database front-end were configured to access and process arbitrary queries, it could be possible for the attacker to provide inputs that would cause the query to call one of the functions in question with the appropriate malformed parameters.’
‘The information has been provided by Microsoft Product Security.’
* Microsoft SQL Server 7.0
* Microsoft Desktop Engine (MSDE) 1.0
* Microsoft SQL Server 2000
* Microsoft Desktop Engine (MSDE) 2000
* 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 rule of least privilege has been followed, it would minimize the amount of damage an attacker could achieve.
* The vector for exploiting this 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.
Download locations for this patch
* Microsoft SQL Server 7.0
* Microsoft SQL Server 2000
What is the scope of the vulnerability?
This is a privilege elevation vulnerability. It occurs in some of the Microsoft-provided extended stored procedures. An attacker who successfully exploited this vulnerability in one of the affected extended stored procedures would gain significant control over the database and possibly the server itself. In a worst case, the attacker could add, change, or delete data in the database, as well as potentially being able to reconfigure the operating system, install new software, or reformat the hard drive. The scope of this vulnerability, however, would be significantly reduced if best practices were followed. Specifically:
SQL Server can be configured to run in a security context in accordance with the rule of least privilege. By default, SQL Server runs in the security context of a domain user, a context with very limited privileges on the server. If this were done, it would have the effect of limiting the potential actions an attacker could take against the operating system in the event of a successful attack.
In addition to successfully exploit this vulnerability, the attacker would need to be able to load and run a query of his construction on the server, or be able to pass information of their choosing into an existing query on the system. Best practices recommends against both of these practices.
What causes the vulnerability?
The vulnerability results because of weak permissions on some extended stored procedures that have the ability to reconnect to the database using the SQL Server.
What are SQL Server extended stored procedures?
Extended stored procedures provide the ability for database designers and administrators to create your their own customized external routines in a programming language such as C or C#. Essentially, extended stored procedures appear to users as normal stored procedures and are executed in the same way. Database queries can pass data to extended stored procedures that can return results and return status.
For instance, among the standard extended stored procedures included with SQL Server are ones that provide e-mail functions. For example:
* xp_startmail, which starts a SQL Mail client session, and
* xp_sendmail, which sends an e-mail or page.
What do you mean when you say that these extended stored procedures can reconnect to the SQL Server as the Service Account?
Typically (with a few exceptions), extended stored procedures run in the security context of the service account SQL server runs as. For example, if a user with limited privileges were to run an extended stored procedure, it would run with the same permissions as the service account.
Some of these extended stored procedures can be made to connect back to SQL server by passing in a carefully crafted input as a parameter to the stored procedures.
At that point, any actions that the extended stored procedure take against the database is in the context of the SQL Server Service Account, which might have high privileges on the database.
What is wrong with the extended stored procedures?
Some of the extended stored procedures provided by Microsoft have inappropriately weak permissions on them. As a result, it is possible for a non-privileged user to load and execute these extended stored procedures.
What could this vulnerability enable an attacker to do?
This vulnerability could enable an attacker to gain administrative control over SQL Server. Because of this, the attacker could take any action on the database that an administrator could take. In addition, depending on the configuration of the database server it could be possible for the attacker to take actions on the operating system that the SQL Server was capable of taking.
How could an attacker exploit this vulnerability?
There are several ways an attacker would try to exploit this vulnerability. The most direct attack vector would be for the attacker to construct a query that calls the affected extended stored procedures. However, to succeed at this, the server would have to be configured to allow an untrusted user to load and execute queries of their choice. Best practices strongly recommends against allowing untrusted users to load and run queries of their construction.
Is there any other way an attacker would try to exploit this vulnerability?
An attacker who could not directly load and execute a query might still be able to exploit the vulnerability if he could use a query that was already present on the system.
For example, if the database were part of a web-based search tool and one of the procedures in question were called by the web site, an attacker could attempt to construct a query that would exploit this vulnerability. However, constructing a query like this would require the attacker to possess intimate knowledge about the internals of a web site’s search function.
If a site had implemented web-based queries without proper checking of inputs, however, it could be possible for an attacker to embed database commands – including a call to the affected function – within the database query parameters. This shows the importance of validating input parameters before passing them to the database server for processing.
What does the patch do?
The patch addresses the vulnerability by setting permissions on the extended stored procedures in questions such that only administrators can invoke them.’