• Article

Security Bulletin

Microsoft Security Bulletin MS02-014 - Moderate

Unchecked Buffer in Windows Shell Could Lead to Code Execution

Published: March 07, 2002 | Updated: October 13, 2003

Version: 1.2

Originally posted: March 07, 2002
Updated: February 28, 2003

Summary

Who should read this bulletin: Users of Microsoft® Windows® 98, 98SE, Windows NT® 4.0, Windows 2000

Impact of vulnerability: Run code of an attacker's choice

Maximum Severity Rating: Moderate

Recommendation: Customers should apply the patch

Affected Software:

  • Microsoft Windows 98
  • Microsoft Windows 98 Second Edition
  • Microsoft Windows NT 4.0
  • Microsoft Windows NT 4.0 Terminal Server Edition
  • Microsoft Windows 2000

General Information

Technical details

Technical description:

The Windows Shell is responsible for providing the basic framework of the Windows user interface experience. It is most familiar to users as the Windows Desktop, but also provides a variety of other functions to help define the user's computing session, including organizing files and folders, and providing the means to start applications.

An unchecked buffer exists in one of the functions that helps to locate incompletely removed applications on the system. A security vulnerability results because it is possible for a malicious user to mount a buffer overrun attack and attempt to exploit this flaw. A successful attack would have the effect of either causing the Windows Shell to crash, or causing code to run in the user's context.

By default, this is not remotely exploitable. However, under very unusual conditions, it could be exploited via a web page. Specifically, if the user has installed, then uninstalled an application with custom URL handlers, and the application's uninstall routine failed to correctly remove the application completely, an attacker could attempt to mount an attack by constructing an HTML web page that seeks to overrun the buffer. Such a web page could be delivered either by posting it on a web site or sending it by email.

Mitigating factors:

  • In a default installation, this vulnerability is not remotely exploitable and could only be exploited by introducing hostile code to the system.
  • The vulnerability could be remotely exploited only if the user has installed and uninstalled software which implements customer URL handlers and the software's uninstall routine failed to completely remove the application from the system.
  • Outlook 98 and 2000 (after installing the Outlook Email Security Update), Outlook 2002, and Outlook Express 6 all open HTML mail in the Restricted Sites Zone. As a result, customers using these products would not be at risk from email-borne attacks.
  • The buffer overrun would allow code to run in the security context of the user rather than the system. The specific privileges the attacker could gain through this vulnerability would therefore depend on the privileges accorded to the user.

Severity Rating:

Internet Servers Intranet Servers Client Systems
Windows 98 None None Moderate
Windows 98SE None None Moderate
Windows NT 4.0 Low Low Moderate
Windows NT 4.0 Terminal Server Edition Low Moderate None
Windows 2000 Low Low Moderate

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. In a default installation, the vulnerability is not remotely exploitable. To be remotely exploitable, certain third-party software with customer URL handlers must be installed and uninstalled. Outlook 2000 with the OESU, Outlook 2002, and Outlook Express 6 all protect against HTML email attempts to exploit this vulnerability.

Vulnerability identifier: CAN-2002-0070

Tested Versions:

Microsoft tested Windows 98, Windows 98SE, Windows ME, Windows NT 4.0, Windows 2000, and Windows XP to assess whether they are affected by these vulnerabilities. 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 buffer overrun vulnerability. An attacker who was able to successfully exploit this vulnerability would be able to take any action on the system that the user himself was capable of. This includes adding or deleting files, communicating with web sites, or even reformatting the hard drive. The vulnerability could only be exploited if the user had taken specific actions, namely, installing and then uninstalling third-party software that happens to have a particular error in the uninstallation routine. Even if the vulnerability were successfully exploited, the attacker would gain the privileges of the user, not the operating system itself.

What causes the vulnerability?
The vulnerability results because of an unchecked buffer in a part of the Windows Shell that helps to locate missing programs. By invoking this function in a particular manner, an attacker could overrun the buffer and cause code of their choice to execute. If an uninstalled program failed to correctly uninstall itself completely and left behind a custom URL handler, it would then be possible to invoke this function from a web page by using that "orphaned" URL handler.

What is the Windows Shell?
The Windows Shell provides the basic framework for the Windows user interface. For most users, the Windows Shell is most commonly experienced as the Windows Desktop. The shell comprises many functions beyond just the desktop and works to present a consistent look and feel throughout the computing experience. The shell can be used to locate files and folders through the Windows Explorer, to provide a consistent way to start applications, through short-cuts on the "Start" menu, and to provide a consistent interface through desktop themes and colors.

What is a custom URL handler?
One of the basic functions of the shell is to provide ways to start applications. The Windows Shell provides two primary means to start applications: through the use of short-cuts on the start menu; and through the use of custom URL handlers. A custom URL handler lets an application register a new URL type that, when invoked by a web page, starts the application automatically. For example, when Outlook 2002 is installed on a system, it registers "outlook://" as a custom URL handler. Outlook can then be invoked by typing this URL in IE, in the "Run" box, or by clicking on a hyperlink. Custom URL handlers are an extensible feature of the Windows Shell. This means that any application can choose to take advantage of this functionality and register its own custom URL handler. The application would register this URL handler during installation by making entries in the Windows Registry to associate a new URL type with the new application.

What's wrong with the Windows Shell?
There is an unchecked buffer in a part of the Windows Shell that helps to locate programs when they have been incompletely removed. The specific function that contains the unchecked buffer is invoked only when the Shell can locate a custom URL handler but not its associated application. If this function were invoked in a particular way, the effect would be to overrun the buffer, thereby potentially allowing code to execute within the Windows Shell process space.

What would this enable an attacker to do?
If an attacker were able to exploit this vulnerability successfully, she might be able to run code of her choice on the user's system. Since the Windows Shell runs in the context of the user, this would have the effect of running the attacker's code as the user. Any limitations on the user's ability to add, change or delete data or configuration information would limit the attacker as well.

How might an attacker exploit the vulnerability?
An attacker could seek to exploit this opportunity by creating a web page that, when opened, calls a custom URL handler using a particular type of malformed argument. If the user had installed an application that created the URL handler, and had subsequently uninstalled the application, and the application's uninstallation routine hadn't correctly removed the URL handler, the web page could overrun the buffer. The web page could either be hosted on the attacker's web site, or sent to the user in the form of an HTML mail. In the former case, the attack would occur if the user browsed to the page. In the latter case, it would occur if the user opened the HTML mail.

The list of prerequisites for exploiting this vulnerability seem fairly steep. Is there any way to exploit the vulnerability in cases where a custom URL handler has not been installed?
It is possible to call the function even in cases where a custom URL handler hasn't been installed. However, this could only be done by a program running on the local system. As the Ten Immutable Laws of Security suggest, the vulnerability doesn't actually represent any increased risk to the user in this scenario - because if the attacker could convince a user to run a program of her choice, she would already have control over the machine and wouldn't need the buffer overrun at all.

Does the problem here lie in the Windows Shell, or in the application that installed the URL handler?
Although the vulnerability only manifests itself in cases where an unrelated application has an error - specifically, when an application's uninstall routine removes the application itself but not the custom URL handler that it created - the vulnerability lies in the Windows Shell.

I've never installed any software with custom URL handlers. Could I be affected by the vulnerability?
No. If the URL handler requested by a web page doesn't exist on the system, the request would fail and the vulnerability couldn't be exploited.

I've installed software with custom URL handlers, but I've never uninstalled it. Could I be affected by the vulnerability?
No. Simply having a custom URL handler on the system doesn't allow the vulnerability to be exploited. The URL handler must also have been uninstalled, and uninstalled incorrectly.

I've installed, and then uninstalled software with custom URL handlers. Does this mean I'm vulnerable?
Not necessarily. Most applications that install custom URL handlers correctly remove them as part of their uninstallation process. It's only when an application's uninstallation process removes the application itself, but leaves the custom URL handler in place, that the system is vulnerable.

Would an attacker have to know the exact custom URL handler that was susceptible to mount a successful attack?
Yes. For an attack to succeed, the attacker would have to specify a URL that had been installed and uninstalled on the user's system, and also know that this URL had not be fully unregistered. However, there are many well-known custom URL handlers, and an attacker could attempt to try and exploit the more widely used URL handlers in an attack.

Do any Microsoft products install, and then incorrectly uninstall, custom URL handlers?
To the best of our knowledge, all Microsoft products that install custom URL handlers correctly uninstall them. However, several third-party products have been brought to our attention that do not correctly uninstall the custom URL handlers they create.

Why would an attacker be able to exploit this via HTML email?
HTML mails are essentially web pages that are sent by mail. By creating a web page that exploits the vulnerability, and then sending it as an HTML mail, an attacker could mount essentially the same attack as by a web site. If scripting were enabled for HTML email, when the mail was opened, either by double-clicking the message or viewing it in a preview pane, the script would execute. It's worth noting that the email-based attack scenario would be blocked in many cases. For instance, customers using any of the following email products would, by default, be protected against the email scenario:

I'm using one of the email products you listed above. Does this mean I don't need the patch?
The Outlook Email Security Update, Outlook 2002, and Outlook Express 6 will protect you against the mail-borne attack scenario. However, we still recommend that you install the patch, to ensure that you're protected against the web-based scenario.

I'm using Windows ME. Could I be affected by the vulnerability?
No. Windows ME does not contain the error.

I'm using Windows XP. Could I be affected by the vulnerability?
No. Windows XP does not contain the error.

Could this vulnerability be exploited by accident?
No. The steps it would take to exploit this vulnerability are very specific and unlikely to be the result of human error.

What does the patch do?
The patch eliminates the vulnerability by imposing proper input validation on the Windows Shell function in question.

Why are there two patches for Windows NT 4.0?
One patch is for Windows NT 4.0 without the Active Desktop feature of IE 4.0. This is a feature that was introduced with IE 4.0 and allows the desktop to display HTML content. This feature introduced a different Windows Shell, and thus requires a separate patch.

How can I tell if I'm running Active Desktop on Windows NT 4.0?
You can determine if you're running Active Desktop on Windows NT 4.0 by examining the registry as discussed in Q216840.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:

  • The Windows 98 patch can be installed on system running Windows 98 and Windows 98SE.
  • The Windows NT 4.0 patch can be installed on systems running Service Pack 6a.
  • The Windows NT 4.0 Terminal Server Edition patch can be installed on systems running Windows NT 4.0 TSE Service Pack 6.
  • The Windows 2000 patch can be installed on systems running Windows 2000 Service Pack 2.

Inclusion in future service packs:

The fix for this issue will be included in Windows 2000 Service Pack 3

Reboot needed: Yes

Superseded patches: None.

Verifying patch installation:

Windows 98 and 98 SE and Windows NT 4.0 Service Pack 6a with Active Desktop:

  • To verify that the patch has been installed on the machine, open IE, select Help, then select About Internet Explorer and confirm that Q313829 is listed in the Update Versions field.
  • To verify the individual files, use the patch manifest provided in Knowledge Base article Q313829.

Windows NT 4.0 Service Pack 6a:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q313829

  • To verify the individual files, consult the file manifest in Knowledge Base article Q313829

Windows NT 4.0 Terminal Server Edition Service Pack 6:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q313829.

  • To verify the individual files, consult the file manifest in Knowledge Base article Q313829

Windows 2000 Service Pack 2:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q313829.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q313829\Filelist

Caveats:

None

Localization:

Localized versions of this patch are currently available at the locations listed above in "Patch Availability".

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 eEye Digital Security (https://www.eeye.com) for reporting this issue to us and working with us to protect customers.

Support:

  • Microsoft Knowledge Base article Q313829 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 (March 07, 2002): Bulletin Created.
  • V1.1 (February 28, 2003): Updated links in Additional Information Section
  • V1.2 (October 13, 2003): Updated Windows 2000 download link in Patch Availability Section

Built at 2014-04-18T13:49:36Z-07:00