Security Bulletin

Microsoft Security Bulletin MS02-035 - Moderate

SQL Server Installation Process May Leave Passwords on System (Q263968)

Published: July 10, 2002 | Updated: June 14, 2005

Version: 2.0

Originally posted: July 10, 2002

Updated: June 14, 2005 Version: 2.0

Summary

Who should read this bulletin:  Administrators using Microsoft® SQL Server 7.0, Microsoft Data Engine 1.0 (MSDE 1.0), or SQL Server 2000

Impact of vulnerability:  Elevation of privilege

Maximum Severity Rating:  Moderate

Recommendation:  SQL Server administrators should delete or move the installation files, or run the KillPwd utility on affected systems immediately.

Affected Software:

• Microsoft SQL Server 7, including Microsoft Data Engine 1.0 (MSDE 1.0)
• Microsoft SQL Server 2000

General Information

Technical details

Why have you issued a version 2 of this bulletin?
After the release of this bulletin, it was determined that the tool did not include the flexibility to scan an entire drive for additional files. The updated tool addresses this. In addition, we included additional information regarding scanning cluster files**.**

Technical description:

When installing SQL Server 7.0 (including MSDE 1.0), SQL Server 2000, or a service pack for SQL Server 7.0 or SQL Server 2000, the information provided for the install process is collected and stored in a setup file called setup.iss. The setup.iss file can then be used to automate the installation of additional SQL Server systems. SQL Server 2000 also includes the ability to record an unattended install to the setup.iss file without having to actually perform an installation. The administrator setting up the SQL Server can supply a password to the installation routine under the following circumstances:

• If the SQL Server is being set up in "Mixed Mode", a password for the SQL Server administrator (the "sa" account) must be supplied.
• Whether in Mixed Mode or Windows Authentication Mode, a User ID and password can optionally be supplied for the purpose of starting up SQL Server service accounts.

In either case, the password would be stored in the setup.iss file. Prior to SQL Server 7.0 Service Pack 4, the passwords were stored in clear text. For SQL Server 7.0 Service Pack 4 and all SQL Server 2000 installation and Service Packs, the passwords are encrypted and then stored. Additionally, a log file is created during the installation process that shows the results of the installation. The log file would also include any passwords that had been stored in the setup.iss file. Lastly, in the case of a Clustered SQL Server 2000 installation, the remsetup.ini file may contain the same password information

A security vulnerability results because of two factors:

• The files remain on the server after the installation is complete. Except for the setup.iss file created by SQL Server 2000, the files are in directories that can be accessed by anyone who can interactively log on to the system.
• The password information stored in the files is either in clear text (for SQL Server 7.0 prior to Service Pack 4) or encrypted using fairly weak protection. An attacker who recovered the files could subject them to a password cracking attack to learn the passwords, potentially compromising the sa password and/or a domain account password

Mitigating factors:

• The vulnerability could only be exploited by an attacker who had the ability to interactively log onto an affected system. However, best practices suggest that unprivileged users not be allowed to interactively log onto business-critical servers, including database servers.
• The vulnerability with regard to the sa password only affects servers configured to use Mixed Mode. Customers using Windows Authentication Mode (which is the recommended mode) would only have credentials at risk if they had chosen to provide a domain credential to be used in starting the SQL Server services.
• The passwords stored in the setup.iss and log files are those provided at installation time and are not kept up-to-date when password changes are made. As a result, if the administrator changed a password, the information in the setup.iss and log files would not allow any access.
• In the case of SQL 2000, setup.iss is stored in a directory that only allows access by administrators and the user installing SQL Server.
• If the setup.iss, ini and log files containing domain user and/or sa passwords are deleted, the passwords could not be retrieved.

Severity Rating:

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. For an attack to succeed, the attacker would need to be able to log on to the SQL Server, access the setup.iss or log files, and carry out the work needed to decrypt the password. The password would have to have remained unchanged since the installation of SQL Server.

Vulnerability identifier: CVE-CAN-2002-0643

Tested Versions:

Microsoft tested SQL Server 7.0, MSDE 1.0, and SQL Server 2000 to assess whether they are affected by this vulnerability. MSDE 2000 does not create the affected setup.iss and log files, and so is not affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

Frequently asked questions

Why have you issued a version 2 of this bulletin?
After the release of this bulletin, it was determined that the tool did not include the flexibility to scan an entire drive for additional files. The updated tool addresses this. In addition, we included additional information regarding scanning cluster files**.**

What's the scope of the vulnerability?
This is a privilege elevation vulnerability. The SQL Server installation routines can, under certain conditions, store passwords that were provided by the administrator doing the setup. However, they are not stored securely, with the result that it could be possible for an attacker to access and compromise the passwords. The passwords are only stored under two conditions: if SQL Server was configured in a mode that Microsoft recommends against using, or if the administrator chose a particular install-time option discussed below. Even in cases where one or more passwords were stored, the vulnerability could only be exploited by an attacker who could log onto an affected SQL Server interactively -- that is, at the system keyboard. If an administrator had changed a password after installation, the stored password would no longer allow any access.

What causes the vulnerability?
The installation routines for SQL Server 7.0, SQL Server 2000 and MSDE 1.0 create several files as part of their operation. These files contain information recorded during the installation process, potentially including the SQL Server administrator password (if the Server is configured to use Mixed Mode) and/or a domain userid and password (if the administrator chooses to provide this information in order to allow SQL Server services to automatically start). A security vulnerability results because of two factors: the files can be accessed by interactively logged-on users, and the information in them is insufficiently well protected. In some cases the data is in plaintext; in others, it's encrypted, but only weakly. A user who accessed one or more of the files could potentially recover the passwords within them, thereby compromising the accounts.

What is MSDE, and how is it related to SQL Server?
Microsoft Data Engine (MSDE) is a database engine that's built and based on SQL Server technology, and which ships as part of several Microsoft products, including Microsoft Visual Studio and Microsoft Office Developer Edition. There is a direct connection between versions of MSDE and versions of SQL Server. MSDE 1.0 is based on SQL Server 7.0 technology; MSDE 2000 is based on SQL Server 2000. The vulnerability here involves files that are created by the installation routines for various versions of SQL Server and MSDE- specifically, it involves SQL Server 7.0 and MSDE 1.0, and SQL Server 2000 (but, in a noteworthy exception, not MSDE 2000).

What are the installation files, and why are they created?
There are three types of files involved in this vulnerability, both of which are created when installing SQL Server 7.0, SQL Server 2000, or MSDE 1.0. (Both fresh installations and service pack installations create the files). The files are:

• An unattended installation file. This file, setup.iss, is created as part of the installation process for SQL Server 7.0, MSDE 1.0 or SQL Server 2000, and contains all of the information entered by the administrator during the installation process. Setup.iss is created in order to allow unattended installs; having created setup.iss once, an administrator can use it to automate additional identical installations on other servers.
• Log files. These files, named sqlstp.log when SQL Server 7.0, MSDE 1.0 or SQL Server 2000 is initially installed, and sqlspX.log when a service pack is installed (where X is the service pack number), contain data logged by the installation process as it progresses. The purpose of the log files is to allow administrators to confirm successful installations and troubleshoot unsuccessful ones.
• Cluster installation ini file. This file, remsetup.ini, is a configuration file used by SQL Server 2000 setup only when installing on a cluster. The purpose of the file is to automate identical installations of SQL Server across multiple nodes of a cluster. It contains all the information necessary to setup SQL Server on the remote nodes of the cluster which can include the same password information above*.*

What's wrong with these files?
The files have two problems. First, they are created with inappropriate permissions that would allow anyone who could log onto the server interactively to read them. (The sole exception is the SQL 2000 setup.iss file, which is created with the correct permissions). Second, the information within them isn't adequately protected. In some cases, the information in them is unencrypted; in others, it's encrypted, but the encryption used offers only weak protection.

Under what conditions is the password data in the files encrypted, and when is it left in clear text?
The passwords in the unattended installation file are created in clear text by versions of SQL Server 7.0 prior to Service Pack 4. All versions of SQL Server 2000 and all versions of SQL Server 7.0 beginning with Service Pack 4 encrypt the passwords before storing them. The log file for an installation will have the same clear text or encrypted passwords as are found in the unattended installation file.

Why does it matter whether someone could read the files? What data is in them?
In general, the data in these files is not sensitive. However, there are two noteworthy exceptions:

• SQL Server administrator password. During installation, the administrator must choose between two operating modes, known as Mixed Mode and Windows Authentication Mode. If Mixed Mode is selected, the password for the administrator account (the so-called "sa" account) is recorded in the unattended installation file.
• Domain user credentials. Another install-time option enables the administrator to configure various SQL-related services to run automatically in the security context of a domain user account, by providing the account's userid and password. If this option has been selected, the userid and password are recorded in both the unattended installation file and the log file.

What could an attacker do via the vulnerability?
The risk posed by this scenario is fairly straightforward. An attacker who gained access to the files could compromise any passwords stored within them, and potentially use them to gain control of either the SQL Server or the domain account.

Who could exploit the vulnerability?
The vulnerability could only be exploited by an attacker who had the ability to log onto an affected server interactively - that is, at the system keyboard. (As discussed above, the SQL 2000 unattended installation file is stored in a folder that can be accessed only by administrators, so in this case exploiting the vulnerability would require the attacker to already have administrative privileges).

How can I tell if my server is at risk?
A server would only be at risk if it was configured to operate in Mixed Mode or if the administrator had chosen the installation-time option to automatically start SQL services using a domain account. If the server was configured to operate in Windows Authentication Mode (which is the recommended mode) and the administrator had not chosen to automatically start the services, the server would not be at risk.

Suppose the passwords had been changed after installation. Would the server be at risk?
The files contain snapshots of the passwords at installation time, and are never updated. If the passwords were changed after installation, it wouldn't benefit the attacker to compromise the data in the files.

If an attacker did compromise the passwords, would he gain complete control over the server?
Compromising the password for the "sa" account would give the attacker complete control over SQL Server, but wouldn't convey administrative privileges on the system itself. Nor would it provide access to any other servers in the domain. Compromising the domain account would grant the attacker all the privileges that the account possessed; the specific ones would depend on how the account had been configured. Best practices always recommend that users be provided the fewest privileges necessary.

Why isn't MSDE 2000 affected by the vulnerabilities?
SQL Server 7.0, MSDE 1.0, and SQL Server 2000 all use the same installer technology while MSDE 2000 uses a different installer technology. MSDE 2000 does not create the setup.iss and log files during installation and so is not affected by this vulnerability.

Could this vulnerability be exploited remotely?
No. An attacker would need to log on to the SQL Server machine and be able to access the directories where the setup and log files are kept.

What can I do to eliminate this vulnerability?
Microsoft recommends that customers running affected systems take either of the three following steps:

• If the unattended installation file and log files are not needed, delete them.
• If the files must be retained, move them to a folder that is only accessible by administrators or, better yet, save them to well-protected offline storage.
• Use the KillPwd utility provided below to remove passwords from the setup.iss,ini and log files.

If I want to delete or move the files, where can I find them?
The unattended installation file is named setup.iss, and is stored in the following locations by default:

• SQL Server 7.0 and MSDE 1.0: The file is stored in the %windir% directory (e.g. "C:\Winnt" by default on Windows 2000). In addition, on SQL Server 7.0 a copy of the file is also made in the %SystemDrive%\MSSQL7\Install\ directory
• SQL Server 2000: The file is stored in the "install" subdirectory associated with the SQL Server installation (e.g. "C:\Program Files\Microsoft SQL Server\mssql\install" by default).

The log file created by Gold installations is named sqlstp.log, and the one created by service packs is named sqlspX.log (where X is the service pack number). The files are stored in the following locations by default:

• SQL Server 7.0 and MSDE 1.0: The files are stored in the %windir%\temp directory (e.g. "C:\Winnt\temp" by default on Windows 2000).
• SQL Server 2000: The files are stored in the %windir% directory (e.g. "C:\Winnt" by default on Windows 2000).

The remote Cluster setup log files are remsetup.ini and a remote install script file (similar to the setup.iss files above) for each remote node which are named <remote_machine_name>_<instance_name>.iss respectively. These are normally deleted when setup completes, but could potentially be left behind if the clustered setup experienced a failure. The files exist in the following locations by default:

• SQL Server 7: Not applicable.
• SQL Server 2000: The files are stored in the %windir% directory (e.g. "C:\Winnt" by default on Windows 2000).

NOTE: If the original installation was completed through a terminal server connection, then the file will be in the terminal server session %windir% directory which is normally a different path

What is the KillPwd utility?
The KillPwd utility provided below is an updated version of the tool first described in Microsoft Security Bulletin MS00-035. This utility searches the Microsoft SQL Server log and setup files for passwords and deletes any passwords that are found, whether encrypted or not. It does not, by default, delete passwords in the setup.iss file created by SQL Server 2000 installations. This is because the setup.iss file created by SQL 2000 installations is saved in a directory that only allows access by administrators and the user setting up SQL Server 2000.

If I'm not sure if a system is affected, can I run the KillPwd utility anyway?
Yes, the KillPwd utility, run by default, removes any passwords in user accessible directories that may remain in the setup.iss and log files after a SQL Server installation. There is no problem in running the utility even if no passwords exist. Additionally, a new command line argument (/N) allows you to run the utility to see what changes it would make without actually making any changes to these files. You can re-run the utility without this command line argument to make those changes.

Patch availability

Download locations for this patch

The KillPwd utility can be obtained at the following location.

• Microsoft SQL 7, MSDE 1.0, and Microsoft SQL Server 2000 - Download the utility

Additional information about this patch

Installation platforms:

This utility can be run on systems running SQL Server 7.0 Gold, MSDE 1.0, and SQL Server 2000 Gold.

You may download the latest and most comprehensive update here: https:.

Reboot needed: No.

Superseded patches: The KillPwd tool provided in this bulletin supersedes the one previously provided as part of Microsoft Security Bulletin MS00-035.

Caveats:

None

Localization:

The KillPwd utility can be run on all supported SQL Server languages.

Obtaining other security patches:

Patches for other security issues are available from the following locations:

• Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
• Patches for consumer platforms are available from the WindowsUpdate web site

Other information:

Acknowledgments

Microsoft thanks the following for working with us to help protect customers.

Cesar Cerrudo for reporting this issue to us and working with us responsibly.

Chris Coffin of BindView for reporting additional information on this issue.

Support:

• Microsoft Knowledge Base article Q263968 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
• Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

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.

Revisions:

• V1.0 (July 10, 2002): Bulletin Created.
• V1.1 (July 11, 2002): Updated information in future service packs section.
• V1.2 (February 28, 2003): Updated download links to Windows Update.
• V2.0 (June 14, 2005): Updated technical information in the FAQ with additional details around cluster installation and to advise of an updated KillPwd utility.

Built at 2014-04-18T13:49:36Z-07:00 </https:>