A flaw in several of the extended stored procedures shipped with SQL Server may allow a memory buffer allocated on the stack to be overwritten with arbitrary data, potentially allowing an attacker to run arbitrary code in the SQL Server process space. This arbitrary code might be used for purposes as simple as shutting down the server to spawning a different process that might be used to take control of the server.

Back to the top

The srv_paraminfo function is used to copy data passed by the caller into a memory buffer allocated by the extended stored procedure (callee). If the callee allocated this buffer on the stack, and if the data passed to the extended stored procedure is larger than this allocated space, the remaining data may be copied onto the stack, potentially overwriting the return address which executes when the function returns. By carefully constructing a buffer with the right information, arbitrary instructions can be placed into the server's memory and allowed to run.

Back to the top

SQL Server 2000

To resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: NOTE: The following hotfix was created prior to Microsoft SQL Server 2000 Service Pack 1.

For SQL Server 2000, the English version of this fix should have the following file attributes or later:

   Version      File name
   -------------------------

   8.00.0223    Xprepl.dll
   8.00.0223    Xpstar.dll
   8.00.0223    Xpqueue.dll
   8.00.0223    Odsole70.dll
				

Back to the top

SQL Server 7.0

To resolve this problem, obtain the latest service pack for Microsoft SQL Server 7.0. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: NOTE: The following hotfix was created prior to Microsoft SQL Server 7.0 Service Pack 4.

The English version of this fix should have the following file attributes or later:

   Version      File name
   ------------------------

   7.00.0918    Xprepl.dll
   7.00.0918    Xpstar.dll
   7.00.0918    Replres.dll
				

NOTE: Because of file dependencies, the most recent hotfix or feature that contains the preceding files may also contain additional files. To install the fix, perform the following steps:

1.	Read Microsoft Security Bulletin MS00-092, located at the following Web site: http://www.microsoft.com/technet/security/bulletin/ms00-092.mspx (http://www.microsoft.com/technet/security/bulletin/ms00-092.mspx)
2.	Download the patch from the following location by selecting the appropriate file for your SQL Server version, processor architecture and language: XP Security Downloads (http://www.microsoft.com/technet/security/bulletin/ms02-043.mspx)
3.	To extract the files, run the self-extracting executable you downloaded. During the extraction process, you are prompted for a destination directory for the files. Choose an empty temporary directory into which to extract the files.NOTE: Both the Alpha and x86 versions of the patch must be extracted by running on an x86-based system.
4.	Included with the patch is a Readme.txt file that has detailed installation instructions for that particular package. Follow those instructions to update your system with these files.

Back to the top

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

SQL Server 2000
This problem was first corrected in SQL Server 2000 Service Pack 1.

SQL Server 7.0
This problem was first corrected in SQL Server 7.0 Service Pack 4.

Back to the top

The list of affected extended stored procedures include:

•	On SQL Server 7.0: xp_sqlinventory
•	On SQL Server 7.0 and SQL Server 2000: xp_sqlagent_monitor
•	On SQL Server 2000 only: sp_OACreate sp_OAMethod sp_OAGetProperty sp_OASetProperty sp_OADestroy

This fix corrects the vulnerability in all of the Microsoft-shipped extended stored procedures. If other third party extended stored procedures are also installed on a system, it may be possible to exploit this attack by using one of those procedures if it uses the Open Data Services API srv_paraminfo. If you have extended stored procedures installed by a third party, contact that vendor to find out if their procedures are vulnerable to this attack.

The exploit takes advantage of using a buffer that is too small for the data being passed. To correctly ascertain the length of data being passed, you must first call srv_paraminfo with its sixth parameter, pbData, as NULL. The function then returns the actual length of the parameter data. An appropriately sized buffer can then be allocated, and a second call can be made to retrieve the data. The srv_paraminfo function does not allow you to specify a maximum length of data to copy into your buffer. For more information, refer to the srv_paraminfo topic in SQL Server Books Online.

Back to the top