Microsoft Security Bulletin MS00-041 - Critical
Patch Available for 'DTS Password' Vulnerability
Published: June 13, 2000 | Updated: July 11, 2000
Originally posted: June 13, 2000
Updated: July 11, 2000
On June 13, 2000, Microsoft released a patch that eliminates a security vulnerability in a component that ships with Microsoft® SQL Server 7.0. If the component is configured improperly, the vulnerability could allow passwords to be compromised.
On July 11, 2000, Microsoft is updating this bulletin to reflect a similar issue with the Enterprise Manager Server registration dialog. A new version of the patch is available to remedy all symptoms related to this vulnerability.
- Microsoft SQL Server 7.0
Data Transformation Service (DTS) packages in SQL Server 7.0 allow database administrators to create a package that will perform a particular database action at regular intervals. As part of the creation of a DTS package, the administrator provides the account name and password under which the action should be taken. However, the password can be retrieved by programmatically interrogating the package's Properties dialogue.
We have also found this vulnerability within the Registered Servers Dialog under Enterprise Manager.
The vulnerability could only occur if several best practices have not been followed:
- The creator of the DTS package chose to supply a username and password instead of using Windows Authentication.
- The DTS package was created without restricting who can edit it.
- The SQL Server administrator allowed Guest access to the SQL Server MSDB database.
- A SQL Server is registered under Enterprise Manager using a username and password instead of using Windows Authentication.
Frequently asked questions
What's this bulletin about?
Microsoft Security Bulletin MS00-041 announces the availability of a patch that eliminates a vulnerability in a component that ships with Microsoft® SQL Server 7.0. The vulnerability could allow a malicious user to obtain passwords programmatically from a DTS package task or through the Enterprise Manager Server Registration Dialog. 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?
This vulnerability could allow the password for an account to be compromised. A component of SQL Server 7.0 that allows an administrator to automate database functions provides the capability to do so in the security context of a particular account. However, the component does not adequately protect the password, and, under certain conditions, a malicious user could compromise it. There are several significant restrictions to this vulnerability. It would not occur if the recommended authentication method, Windows NT® Authentication, had been used. Similarly, if standard security practices were followed, the malicious user would not have access to either the server or the component.
What causes this vulnerability?
The account name and password associated with a SQL Server 7.0 Data Transformation Service (DTS) package or Enterprise Manager Server Registration dialog, are not adequately protected. If a malicious user were able to view the Properties page associated with a DTS package, he could programmatically interrogate the password and compromise it. The same attack could also be used against the Server Registration dialog through Enterprise Manager.
What is DTS?
Data Transformation Services is a component of Microsoft SQL Server 7.0 used to import, export, and transform data from different data sources. Administrators or users can create DTS packages, each of which defines a series of tasks to be executed in a coordinated sequence. A DTS package can be created manually by using a language that supports OLE Automation, such as Microsoft Visual Basic®, or interactively by using the Data Transformation Services wizards or DTS Designer. (Please refer to the Microsoft SQL 7.0 CD, Books Online for more information)
What's an example of how DTS could be used?
Suppose a company has a heavily-used database, and needs to send end-of-day statistics to the database administrator, summarizing the total number of changes that were made to the data during the day, the types of changes, and so forth. The administrator might create a DTS package to generate the statistics, then email them to a distribution list. The administrator could then configure the package to run automatically at a certain time daily.
What's wrong with the way passwords are stored in DTS packages and the Server Registration dialog in Enterprise Manager?
If the password is stored in a DTS package, it's masked by asterisks when shown on the Properties page. However, if a malicious user could display the Properties page, he could programmatically interrogate it to retrieve the plaintext password. In similar fashion, if a malicious user has access to the Registered Server dialog in Enterprise Manager they can also interrogate it to retrieve the plaintext password.
What's the password at issue here?
Every DTS package that contains an interactive task needs to run in the security context of a specific account. For instance, in the example above, the DTS package would need to run in the context of an account that has query access to the database, and the ability to send mail. This is the account whose password would be at risk in this vulnerability. When a SQL Server administrator registers a server using Enterprise Manager the "Registered Server Properties" dialog appears. If the administrator supplies a username and password (instead of using Windows Authentication) the password in that edit box is also at risk with this vulnerability.
Could the system administrator password be compromised via this vulnerability?
Potentially, it could - but only if the system administrator created a DTS package and chose to use their account as the one in which the package would run or when registering a server through Enterprise Manager. Clearly, this is not a recommended practice. DTS packages should always follow a "least privilege" policy, and only use an account with the bare minimum privileges needed. The same best practice holds true when registering servers and not using Windows Authentication.
Is every DTS package at risk from this vulnerability?
No. There are two ways for a DTS package to authenticate itself: by means of a stored password within the package, or via Windows NT authentication. The vulnerability only occurs if the former has been done. Microsoft always recommends that Windows NT be used for all authentication methods. Even if the password were stored within a DTS package, it wouldn't be sufficient to allow the password to be compromised. To exploit the vulnerability, the malicious user would also need to have access to the package itself, and view the Properties page.
Who could access a DTS package?
If best practices have been followed, normal users will not be able to access DTS packages, and hence would not be able to exploit the vulnerability. All DTS packages on a SQL server are stored in a construct called the MSDB (Microsoft Database). By default, normal users cannot access the MSDB, and as a result could not exploit the vulnerability. It's worth noting that even in the absence of this vulnerability, it would be contrary to best practices to allow all users to access the MSDB. As is generally the case, users should only be given permissions to access network resources that they are authorized to use.
Who could view the Properties page of a DTS package?
Even if normal users were given access to the MSDB, they would still be unable to view the Properties page of a particular DTS package by default. Access to a particular DTS package, including the Properties page, can be controlled by the person who created it. There are two levels of access, Owner access and User access. User access allows a person to run a DTS package; Owner access allows him to edit and run the DTS package. Owner access to a DTS package should always be tightly controlled, and if this has been done, a malicious user would not be able to exploit this vulnerability. It's worth pointing out that even in the absence of this vulnerability, it is a standard administrative practice to assign Owners to DTS packages, otherwise any user would be allowed to edit the package and completely change what the package does.
What is Enterprise Manager?
Microsoft Management Console (MMC) is a tool that presents a common interface for managing different server applications in a Microsoft® Windows® network. Server applications provide a component called an MMC snap-in that presents MMC users with a user interface for managing the server application. SQL Server Enterprise Manager (EM) is the Microsoft SQL Server™ MMC snap-in.
What does the patch do?
The patch eliminates the vulnerability by ensuring the password is removed behind the mask within the user properties password edit boxes and also from the Registered Servers dialog within Enterprise Manager.
How do I use the patch?
Knowledge Base article, Q264880 contains detailed instructions for applying the patch.
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?
The Knowledge Base article, Q264880 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 bulletinand 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, Q264880 explaining the vulnerability and procedures 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 Supportcan provide assistance with this or any other product support issue.
Download locations for this patch
Additional information about this patch
Installation platforms: Please see the following references for more information related to this issue.
- Microsoft Knowledge Base (KB) article, Q264880
Support: This is a fully supported patch. Information on contacting Microsoft Technical Support is available at http://support.microsoft.com/contactussupport/?ws=support.
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.
- June 13, 2000: Bulletin Created.
- July 11, 2000: Updated to discuss similar vulnerability with Enterprise Manager.
Built at 2014-04-18T13:49:36Z-07:00