• Article

Security Bulletin

Microsoft Security Bulletin MS00-052 - Critical

Patch Available for 'Relative Shell Path' Vulnerability

Published: July 28, 2000

Version: 1.0

Originally posted: July 28, 2000

Summary

Microsoft has released a patch that eliminates a security vulnerability in Microsoft® Windows NT® 4.0 and Windows® 2000. Under certain conditions, the vulnerability could enable a malicious user to cause code of his choice to run when another user subsequently logged onto the same machine.

Affected Software:

  • Microsoft Windows NT 4.0 Workstation
  • Microsoft Windows NT 4.0 Server
  • Microsoft Windows NT 4.0 Server, Enterprise Edition
  • Microsoft Windows NT 4.0 Server, Terminal Server Edition
  • Microsoft Windows 2000 Professional
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server

Vulnerability Identifier: CVE-2000-0663

General Information

Technical details

Technical description:

The registry entry that specifies the Windows Shell executable (Explorer.exe) provides a relative, rather than absolute, path name. (As discussed in the FAQ, it does this because of legacy application compatibility concerns). Because of the circumstances in place at system startup time, the normal search order would cause any file named Explorer.exe in the %Systemdrive%\ directory to be loaded in place of the bona fide version. This could provide an opportunity for a malicious user to cause code of his choice to run when another user subsequently logged onto the same machine.

Under normal conditions, the malicious user could only exploit this vulnerability on machines that he could interactively log onto. As a result, workstations and terminal servers would be the machines primarily at risk. If standard security recommendations have been followed, normal users will not be given permission to interactively log onto security-critical machines such as domain controllers, print/file servers, ERP servers, web servers, and so forth.

Frequently asked questions

What's this bulletin about?
Microsoft Security Bulletin MS00-052 announces the availability of a patch that eliminates a vulnerability in Microsoft® Windows NT® 4.0 and Windows® 2000. 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 would enable a malicious user to substitute code of his choice for the normal Windows desktop on machines that he can interactively log onto. Such code would run automatically whenever a user subsequently logged onto the same machine, and could take any action the user had privileges to take on the machine. Workstations and terminal servers would be the machines primarily affected by this vulnerability. If normal security precautions are followed, security-critical servers such as print and file server, domain controllers, ERP servers, and others will not allow normal users to interactively log onto them.

What causes the vulnerability?
The vulnerability results because the name of the executable that provides the Windows Shell functionality is specified by a relative, rather than absolute, path in the registry key that Windows consults during startup. If a bogus version of the Windows Shell were placed in a location that is ahead of the bona fide version in the search order, the bogus version would be loaded upon system startup.

What's the Windows Shell?
The Windows Shell is the familiar desktop that's used for interacting with Windows. During system startup, Windows NT 4.0 and Windows 2000 consult the "Shell" registry entry, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell, to determine the name of the executable that should be loaded as the Shell. By default, this value specifies Explorer.exe.

Is this a problem with Explorer.exe?
No. The vulnerability has nothing to do with Explorer.exe per se. Instead, it results because the default value for the Shell registry entry specifies Explorer.exe via a relative rather than absolute path. That is, it's specified as "Explorer.exe" rather than "%systemroot%\Explorer.exe".

Why is it a problem to specify Explorer.exe via a relative path name rather than an absolute one?
The problem has to do with the search order that occurs when system startup is in process. Whenever a registry entry specifies the name of a code module, but does it using a relative path, Windows initiates a search process to find the code. The search order is as follows:

  1. Search the current directory
  2. If the code isn't found, search the directories specified in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path, in the order in which they are specified.
  3. If the code isn't found, search the directories specified in HKEY_CURRENT_USER\Environment\Path, in the order in which they are specified.

The default settings for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path and HKEY_CURRENT_USER\Environment\Path are "%SystemRoot%\System32;%SystemRoot %" and null, respectively. Because the current directory during system startup is %SystemDrive%\, the resulting search path would be:

  1. %SystemDrive%\ (e.g., C:\)
  2. %SystemRoot%\System32 (e.g., C:\WINNT\System32)
  3. %SystemRoot% (e.g., C:\WINNT)

The vulnerability results because the default permissions on %SystemDrive%\ allow all interactive users to write to it. Thus, on a machine that boots from the C: drive, if a malicious user placed a bogus Explorer.exe into C:\, the search order would cause it, rather than the bona fide Explorer.exe, to be loaded and executed each time a user on the machine logged on.

Why isn't Explorer.exe specified by an absolute path name in the Shell registry value?
Under normal conditions, it would be. Microsoft has long recommended whenever a registry entry provides the location of an executable file, it should specify the file via an absolute path. The reason this was not done in the particular case of the Shell registry value is because of compatibility concerns with legacy applications. Many applications, especially older ones, consult the Shell value during installation in order to determine the name of the shell in effect. Some of these applications are coded to handle only the case where a file name and extension are provided, and would stop working if an absolute path were included in the value. That's why, alone among Microsoft-provided registry values, the Shell value uses a relative path.

What could a bogus Explorer.exe do?
The code could do anything the user was authorized to do on the computer. If a user with few privileges logged on, the code might be able to do very little. On the other hand, if a user with significant privileges on the machine or on the domain logged onto it, the code might be able to cause significant harm. It's worth pointing out that standard security recommendations advise highly-privileged users such as domain administrators against using untrusted machines.

Could the user prevent the bogus code from running?
No. The Shell code is run as part of system startup, so the user would not have an opportunity to prevent it from running.

Could this vulnerability be exploited accidentally?
No. It would require a specific set of steps that are unlikely to be carried out by accident.

Could this vulnerability exploited remotely?
No. Under default conditions, this vulnerability could only be exploited if the malicious user had the ability to log onto the machine interactively, that is, log on at the keyboard. The only case in which this vulnerability could be remotely exploited would be one in which an administrator on the machine had shared the root directory of the machine to the malicious user, and given him write privileges to it.

What machines are at greatest risk from this vulnerability?
The most important point to keep in mind is that, as discussed above, the malicious user could only exploit this vulnerability on machines he could log onto interactively. As a result, machines that allow normal users to log on interactively, such as workstations and terminal servers, would be at greatest risk. Standard security recommendations strongly militate against ever allowing normal users to interactively log onto security-critical machines like domain controllers, print/file servers, ERP servers, database servers and the like. If this guidance has been followed, these machines would not be at risk.

Who should use the patch?
Microsoft recommends that customers consider installing the patch on any machine that allows normal users to log on interactively, and on any machine on which the root directory is globally shared.

What does the patch do?
It isn't feasible to correct the situation by using an absolute path name in the "Shell" registry entry, because of the application compatibility concerns discussed above. The patch eliminates the vulnerability by introducing a special case into the startup code, that prepends %systemroot% before the value specified in the "Shell" entry.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.

How do I use the patch?
The Knowledge Base article Q269049 contains detailed instructions for applying the patch.

How can I tell if I installed the patch correctly?
The Knowledge Base article Q269049 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 delivered a patch 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 Q269049 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 Product Support Services can provide assistance with this or any other product support issue.

Patch availability

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 Q269049, https:

Other information:

Support: This is a fully supported patch. Information on contacting Microsoft Product Support Services is available at </https:>https:.

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:

  • July 28, 2000: Bulletin Created.

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