Microsoft Security Bulletin MS02-014

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:

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.

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:

• Outlook 98 or 2000, if the Outlook Email Security Update has been installed.
• Outlook 2002
• Outlook Express 6

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.

Download locations for this patch

• Windows 98 http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4C6FD7E5-A66E-4A08-B782-2A64C77B95B6
• Windows NT 4.0 http://www.microsoft.com/downloads/details.aspx?FamilyId=71B6135C-F957-4702-B376-2DACCE773DC0&displaylang=en
• Windows NT 4.0 with Active Desktop http://www.microsoft.com/downloads/details.aspx?FamilyID=72918a2a-dc2c-444c-a20e-f347e13f5b02&DisplayLang=en
• Windows NT 4.0 Terminal Server Edition http://www.microsoft.com/downloads/details.aspx?FamilyId=677229F8-FBBF-4FF4-A2E9-506D17BB883F&displaylang=en
• Windows 2000 http://www.microsoft.com/downloads/details.aspx?FamilyId=666D3B38-25B6-4E71-BD42-8D35F216A8A5&displaylang=en