Microsoft KB Archive/256052

= FIX: Sqlservr.exe Non-Trusted Connection Through OPENROWSET Allows Access to Service Account =

Article ID: 256052

Article Last Modified on 3/14/2006

-

APPLIES TO


 * Microsoft SQL Server 7.0 Standard Edition

-



This article was previously published under Q256052



BUG #: 57634 (SQLBUG_70)



SYMPTOMS
If a user is able to submit a particular form of a SQL SELECT statement to SQL Server, it is possible to take actions on the SQL database. If the SQL Server is operating in an account with elevated privileges on the underlying system, it is possible to take actions on the underlying operating system.



WORKAROUND
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

To work around this issue without the fix, you can disallow ad-hoc through the OpenRowset function as discussed in the SQL Server Books Online topic Configuring OLE DB Providers for Distributed Queries.

To automate the workaround copy the following and create a .reg file, and then double-click the .reg file. This disables all ad-hoc query access through OLE DB providers from your SQL Server or Microsoft Data Engine (MSDE) installation. You may also manually add each of these registry keys. For more information about using regedit .reg files, see the Help menu of regedit for your Microsoft Windows NT or Microsoft Windows 2000 documentation.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers\Microsoft.Jet.OLEDB.4.0] "DisallowAdhocAccess"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers\MSDAORA] "DisallowAdhocAccess"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers\MSDASQL] "DisallowAdhocAccess"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers\SQLOLEDB] "DisallowAdhocAccess"=dword:00000001



STATUS
Microsoft has confirmed this to be a problem in SQL Server 7.0. This problem has been corrected in U.S. Service Pack 2 for Microsoft SQL Server 7.0. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

254561 INF: How to Obtain Service Pack 2 for Microsoft SQL Server 7.0 and Microsoft Data Engine (MSDE) 1.0

For more information, contact your primary support provider.

This bug is also fixed in the following hotfix, which is in a self-extracting zip file format.

IMPORTANT: You must unzip BOTH the x86 and the Alpha versions of the fix onto an x86 computer.

The following files are available for download from the Microsoft Download Center:

x86: Download S70780i.exe now

Alpha: Download S70780a.exe now

Release Date: MAR-08-2000

For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:

119591 How To Obtain Microsoft Support Files from Online Services

Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.

Instructions to Microsoft Customers for Applying the Sqlservr.exe Hotfix
Please read through this file thoroughly before proceeding with any steps of the hotfix installation.

Hotfixes are intended for interim use until the next service pack is available, at which point you should upgrade immediately.

While running a hotfix, if conditions arise requiring assistance from Microsoft product support, you may be asked to upgrade immediately to a newer hotfix or the next service pack. Performing this upgrade may be required in order to expedite troubleshooting and problem resolution.

IMPORTANT: This hotfix requires the installation of 7.0 Service Pack 1. You MUST install 7.0 Service Pack 1 before applying this hotfix. If you are running 7.0 Service Pack 2 or later, you do not need this hotfix.

This hotfix contains the following files:

Sqlservr.exe - Main SQL Server Executable

Sqlservr.dbg - SQL Server symbol file

Sqlservr.pdb - SQL Server symbol file

If you are installing this hotfix on a server running SQL 7.0 Enterprise Edition with clustering enabled, please use the section titled "Hotfix Installation Steps for SQL 7.0 EE with Clustering Enabled" for installation instructions. All other environments should use the section titled "Standard Hotfix Installation Steps".

Standard Hotfix Installation Steps

 * 1) Install SQL 7.0 Service Pack 1.

NOTE: Do not go to any further steps until you complete the SQL Server 7.0 Service Pack 1 installation successfully.
 * 1) Shut down the Microsoft SQL Server and SQL Server Agent services.
 * 2) Make a backup copy of the Sqlservr.exe, Sqlservr.dbg and Sqlservr.pdb files in the \Mssql7\Binn directory (or whatever directory into which you installed the SQL Server 7.0 program files).
 * 3) Copy the Sqlservr.exe, Sqlservr.dbg, and Sqlservr.pdb files into the \Mssql7\Binn directory (or into whatever directory into which you installed the SQL Server 7.0 program files).
 * 4) Start Microsoft SQL Server and the SQL Server Agent services.
 * 5) Test your system to make sure that it runs properly.
 * 6) If for any reason you encounter a problem with this hotfix build, you may go back to the previous build by restoring the files backed up in step 3.

Hotfix Installation Steps for SQL 7.0 EE with Clustering Enabled

 * 1) Make sure that the computer node on which SQL 7.0 was originally set up controls the SQL Server resources.
 * 2) On this same computer node, run the Failover Setup Wizard utility to remove that Virtual SQL Server.
 * 3) Install the SQL 7.0 Service Pack 1.

NOTE: Do not go to any further steps until you complete the SQL 7.0 Service Pack 1 installation successfully.
 * 1) Make a backup copy of the Sqlservr.exe, Sqlservr.dbg and Sqlservr.pdb files in the \Mssql7\Binn directory (or whatever directory into which you installed the SQL Server 7.0 program files).
 * 2) Copy the Sqlservr.exe, Sqlservr.dbg, and Sqlservr.pdb files into the \Mssql7\Binn directory (or into whatever directory into which you installed the SQL Server 7.0 program files).
 * 3) Run the Failover Setup Wizard utility to create the Virtual SQL Server resources.
 * 4) Using the Windows NT Cluster Manager, select the SQL Resource Group, right-click and then select Bring on-line. This brings all services on-line in their order of dependency.
 * 5) Test the scenario for the bug that is fixed in this build to verify that the problem is resolved. Notify Microsoft Product Support Services immediately if you feel for any reason that the problem is not resolved.
 * 6) If for any reason you encounter a problem with this hotfix build, you may go back to the previous version of SQL Server by copying back the files you copied in step 4 above.

Using the T-SQL OPENROWSET statement, any user who can connect to the server using DB-Library, ODBC or OLE-DB can get administrative rights on the server and execute any command (even xp_cmdshell or SHUTDOWN) on the server.

For example, to shut down the server, just use a SELECT statement like the following: SELECT result.* FROM OPENROWSET('SQLOLEDB', 'Trusted_Connection=yes;Integrated Security=SSPI;Data Source=servername;Initial Catalog=master', 'select testing shutdown with nowait') as result If the SQL Server database administrator account is also the administrator account, or a highly privileged account on the server platform, then this vulnerability may be exploited to assume control of the underlying platform. If the database administrator account is an ordinary user account, or does not have such privileges, then exploitation of the vulnerability is limited to the database itself.

Users who have SQL Server databases that are accessible through DB-Library, ODBC or OLE-DB should install the patch. Alternatively, users may install SQL Server 7.0 Service Pack 2, which also contains code that eliminates this vulnerability.

The patch eliminates the vulnerability by preventing standard security users from becoming trusted users when connecting back into SQL Server.

