Microsoft Security Bulletin MS02-035 - SQL Server Installation Process May Leave Passwords on System. 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.
9f9beb2a328bbc2c0a237bce8101c3044e0ed4db04422219c2b498b9e29b18b5 TechNet Home > Security > Bulletins
Microsoft Security Bulletin MS02-035
[Print] Print
SQL Server Installation Process May Leave Passwords on System (Q263968)
Originally posted: July 10, 2002
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
Technical details
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 SQL Server 2000 Service Packs 1 and 2, 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.
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 and log files containing domain user
and/or sa passwords are deleted, the passwords could not
be retrieved.
Severity Rating:
Internet Servers Intranet Servers Client Systems
SQL Server 7.0 Moderate Moderate None
MSDE 1.0 Moderate Moderate Moderate
SQL Server 2000 Moderate Moderate None
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
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 two 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.
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 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).
* 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).
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 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.
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:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=40205
Additional information about this patch
Installation platforms:
This utility can be run on systems running:
* SQL Server 7.0 Gold, Service Pack 1, Service Pack 2,
Service Pack 3, or Service Pack 4
* MSDE 1.0
* SQL Server 2000 Gold, Service Pack 1, or Service Pack 2
Inclusion in future service packs:
The fix for this issue will be included in:
* SQL Server 7.0 - no future Service Pack planned at
present
* SQL Server 2000 Service Pack 3
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
* All patches available via WindowsUpdate also are
available in a redistributable form from the
WindowsUpdate Corporate site.
Other information:
Acknowledgments
Microsoft thanks Cesar Cerrudo for reporting this issue to us
and working with us to protect customers.
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.
Contact Us | E-mail this Page | TechNet Newsletter
© 2002 Microsoft Corporation. All rights reserved. Terms of Use Privacy Statement Accessibility
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed