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:
- Search the current directory
- 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.
- 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:
- %SystemDrive%\ (e.g., C:\)
- %SystemRoot%\System32 (e.g., C:\WINNT\System32)
- %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 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 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.
