What is the correct order for installing this patch in conjunction with the hotfix discussed in 317748?
This security patch does not contain a patch from Knowledge Base Article 317748 that is required to ensure normal operation of SQL Server 2000 and MSDE 2000. The correct order of installation is to install the 317748 patch and then this security patch. If you have applied this security patch to a SQL Server 2000 or MSDE 2000 installation prior to applying the hotfix from Knowledge Patch article 317748, you must answer "no" if and when prompted to overwrite files to ensure that you do not overwrite files from the security patch.
How do I check I've got this security patch installed?
You should verify that the version of ssnetlib.dll in the \MSSQL\BINN folder for the instance you applied the patch for is: 2000.80.636.0
If the version of the ssnetlib.dll in the \MSSSQL\BINN folder is less than 2000.80.636.0, then you will need to re-apply the security patch. However Microsoft recommends that you apply the latest security patch as described in MS02-061 since this contains fixes for additional security vulnerabilities in these products.
What vulnerabilities does this patch eliminate?
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#. For all intents and purposes, 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 which 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 procs can be made to connect back to SQL server by passing in a carefully crafted input as a parameter to the stored procs.
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's 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's 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. As a result 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 were 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 couldn't 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.
