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

Article translations Article translations
Article ID: 256052 - View products that this article applies to.
This article was previously published under Q256052
This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 57634 (SQLBUG_70)
Expand all | Collapse all

On This Page

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.

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.
  2. Shut down the Microsoft SQL Server and SQL Server Agent services.
  3. 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).
  4. 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).
  5. Start Microsoft SQL Server and the SQL Server Agent services.
  6. Test your system to make sure that it runs properly.
  7. 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.
  4. 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).
  5. 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).
  6. Run the Failover Setup Wizard utility to create the Virtual SQL Server resources.
  7. 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.
  8. 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.
  9. 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.

References

For additional security-related information about Microsoft products, visit the following Microsoft Web site:
http://www.microsoft.com/security/

Properties

Article ID: 256052 - Last Review: October 26, 2013 - Revision: 4.0
Applies to
  • Microsoft SQL Server 7.0 Standard Edition
Keywords: 
kbnosurvey kbarchive kbbug kbfile kbfix kbgraphxlinkcritical KB256052

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com