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 http://www.microsoft.com/technet/prodtechnol/sql/70/maintain/secure.mspx. 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.
