Microsoft Security Bulletin MS00-035 - Critical
Patch Available for 'SQL Server 7.0 Service Pack Password' Vulnerability
Published: May 30, 2000 | Updated: May 10, 2001
Originally posted: May 30, 2000
Updated: June 15, 2000
Updated: May 10, 2001
On May 30, 2000, Microsoft released the original version of this bulletin, to announce the availability of a patch that eliminates a security vulnerability in Microsoft® SQL Server® 7.0 Service Packs 1 and 2 installation routine. When run on a machine that is configured in a non-recommended mode, the routines record the administrator password in a log file, where it could be read by any user who could log onto the server at the keyboard.
On June 15, 2000, the bulletin was updated to note that, under the same conditions as originally reported, the password also is recorded in a second file. A new version of the patch is available that prevents the password from being recorded in either file.
On May 10, 2001, the bulletin was updated to note that Service Pack 3 is also affected by this vulnerability. A new patch is available for SP3 and we are also providing a command line utility (post Service Pack deployment) to remove all instances of the SA password written in either file via Q263968.
- Microsoft SQL Server 7.0 Service Packs 1, 2, and 3
Vulnerability Identifier: CVE-2000-0402
When SQL Server 7.0 Service Packs 1, 2, or 3 are installed on a machine that is configured to perform authentication using Mixed Mode, the password for the SQL Server standard security System Administrator (sa) account is recorded in plaintext in the files %TEMP%\sqlsp.log and %WINNT%\setup.iss. The default permissions on the files would allow any user to read them who could log onto the server interactively.
The password is only recorded if Mixed Mode is used, and even then, only if the adminstrator chose to use SQL Server Authentication when installing the service pack. Microsoft has long recommended that SQL servers be configured to use the more secure Windows NT Authentication Mode, and customers who have followed this recommendation would not be affected. Even on affected machines, the password could not be compromised if, per normal security recommendations, normal users are prevented from logging onto the machine interactively.
Frequently asked questions
What's this bulletin about?
Microsoft Security Bulletin MS00-035 announces the availability of a patch that eliminates a vulnerability in the installation routines for Microsoft® SQL Server 7.0 Service Packs 1, 2, and 3. The vulnerability could allow the administrator's password to be compromised under certain conditions. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.
What's the scope of the vulnerability?
When SQL Server 7.0 Service Packs 1, 2, or 3 are installed on a system that performs user authentication using Mixed Mode, the installation process can, under certain conditions, leave a copy of the database administrator's password in two files on the server. If recovered by a malicious user, the password could be used to exercise administrative control over the database. There are some significant restrictions to this vulnerability:
- It does not occur when the recommended authentication method, Windows NT® Authentication, is used.
- Even when Mixed Mode is used, it only occurs if a particular type of authentication, SQL Server Authentication, is used.
- By default, the files containing the password could only be read by a user who could interactively log onto the server. Standard security recommendations strongly militate against allowing normal users to interactively log onto security-critical servers such as database servers.
What causes the vulnerability?
If the SQL Server is configured to perform authentication in Mixed Mode, and the administrator chooses to use SQL Server Authentication during setup instead of Windows NT Authentication, the installation software for Service Packs 1, 2, and 3 will prompt the user for an administrative password. The vulnerability results because, if the above conditions are true, the installation software writes the password to two files that remain on the server.
What are the two files into which the password is written?
Sqlsp.log and setup.iss
What is Mixed Mode?
SQL Server supports two modes for authenticating users, Mixed Mode and Windows NT Authentication Mode. In Mixed Mode, clients are authenticated using Windows NT credentials if possible; otherwise, the client authenticates via SQL Server Authentication, using username and password information that is stored locally in the SQL Server database. The most common use of Mixed Mode is when SQL Server is hosted on a Windows® 95 or 98 machine. In contrast, Windows NT Authentication mode requires authentication to be performed using Windows NT (or Windows 2000) credentials. This is far more secure, and Microsoft strongly recommends that Windows NT Authentication Mode be used whenever possible. Customers who use Windows NT Authentication Mode would not be affected by this vulnerability.
Why is Mixed Mode less secure than Windows NT Authentication Mode?
In Mixed Mode, username and password information is stored within SQL Server itself. Mixed Mode is only intended for use in networks in which the servers, clients and network infrastructure are physically protected, and all users are trusted. It's included in SQL Server 7.0 only to provide for backward compatibility with previous releases, and to allow interoperability with products that don't support Windows NT Authentication. In contrast, Windows NT Authentication Mode uses the normal Windows NT authentication mechanism, which was built for use in environments where security is important. All authentication information is housed on the domain controller rather than the SQL Server, and it's protected - both on the wire and on the domain controller - by strong cryptographic hashes. More information on SQL Server 7.0 security in general, including authentication modes, is available at https:. In particular, the section titled "Setting Up a Secure SQL Server 7.0 Installation" provides instructions for changing the authentication mode.
Does this vulnerability affect all customers who use Mixed Mode?
No. To be affected by the vulnerability, all three of the following conditions must be true:
- The customer must have applied SQL Server 7.0 Service Packs 1, 2, or 3
- The SQL Server must be configured in Mixed Mode
- The administrator must have used SQL Authentication when he installed any of the service packs.
The latter point is especially important. In Mixed Mode, a user can authenticate using either Windows NT or SQL Server Authentication. If the administrator chose to use Windows NT authentication when he installed the service packs, the password would not be written to the log file.
What password is involved in this vulnerability?
The password at issue is the one associated with the SQL Server standard security System Administrator account -- the "sa" account. When Mixed Mode is used, a userid with the name "sa" is created in the SQL Server tables for the administrator. It's important to note that the sa account is not the same thing as the Windows NT Administrator account. The sa account provides administrative privileges to the SQL database, but none on the machine itself. The importance of this fact is that this vulnerability could only allow the malicious user to usurp control of the SQL database, not the machine or the network.
Who could read the files containing the password?
By default, the files could be read by anyone who could interactively log onto the server. The files are not shared by default, so remote users could not read them.
Who should be able to log onto the server interactively?
As a general rule, only administrators should be allowed to log onto security-sensitive machines like database servers. If this recommendation has been followed, only an administrator could read the file (and, of course, the administrator would already know the password). On Windows 95 and 98, there is no means of restricting who can log onto the machine - all a user needs is physical access to the machine. This is one more reason why such machines should only be used in an environment that provides physical security for all hardware, and in which all users are trusted.
What machines are most likely to be affected by the vulnerability?
The only machines affected would be those running SQL Server 7.0 Service Packs 1, 2, or 3 -- and even then, only if the service packs were applied using SQL Server authentication during the service pack setup.
I've already installed one of the affected service packs, and I did use SQL Server Authentication when I installed it. What should I do?
You can do ONE of the following:
- Please run the password utility tool provided in the Workaround section in Knowledge Base article Q263968
- Change the 'sa' account password by using the sp_password stored procedure
- Change the server configuration to validate users through Windows NT Integrated Authentication ONLY.
- Search for and delete all copies of these files:
To ensure that the files cannot be recovered, you may wish to delete them permanently by holding down the Shift key and dragging the file to the Recycle Bin.
I'm preparing to deploy SQL Server 7.0 Service Pack 2 or 3, and I'm running in Mixed Mode. What should I do?
The easiest course of action is to use Windows NT Authentication when installing the service pack. If you do this, the password won't be recorded -- and you'll have better overall security as well, as discussed above. If you must use SQL Server Authentication, there are two courses of action, depending on how many machines you'll be installing the service pack on:
- If you'll be installing the service pack on a small number of machines, you may want to consider installing the service pack normally and then deleting sqlsp.log and setup.iss.
- If you'll be installing it onto many machines, you may wish to use the patch discussed in the security bulletin. Just expand the service pack into a folder and install the patch. It will overwrite the affected files with new ones that do not create the log file. You can then install the service pack from the folder. (Please note: the original version of the patch only prevented the password from being recorded in sqlsp.log; a new version is being developed that will prevent it from being recorded in setup.iss. The original version of the patch has been removed; when the new version is available, the bulletin will be updated).
How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.
How can I tell if I installed the patch correctly?
Knowledge Base article Q263968 provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article
What is Microsoft doing about this issue?
- Microsoft has developed a procedure that eliminates the vulnerability.
- Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
- Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
- Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.
Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.
How do I get technical support on this issue?
Microsoft Technical Support can provide assistance with this or any other product support issue.
Download locations for this patch
Microsoft SQL Server 7.0 Service Pack 2:
Contact Microsoft Product Support
Note: A password removal tool is also available in the Workaround section of Knowledge Base article Q263968 which will remove all SA passwords from the affected files once the Service Pack has been deployed.
Additional information about this patch
Installation platforms: Please see the following references for more information related to this issue.
- Microsoft Knowledge Base (KB) article Q263968, </https:>https:
- Microsoft SQL Server 7.0 Security, </https:>https:.
Microsoft thanks the following customers for working with us to protect customers:
- Gordon Newman of PeopleSoft for reporting the presence of the password in sqlsp.log
- Akintunde Oluwaleimu for reporting the presence of the password in setup.iss
Support: This is a fully supported patch. Information on contacting Microsoft Technical Support is available at </https:>https:.
Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
- May 30, 2000: Bulletin Created.
- June 15, 2000: Bulletin updated to discuss password presence in setup.iss.
- May 10, 2001: Bulletin updated to provide a patch for SP3 and tool for SA password removal.
Built at 2014-04-18T13:49:36Z-07:00 </https:>