[NT] Unchecked Buffer in Windows Shell Could Lead to Code Execution

From: support@securiteam.com
Date: 03/11/02


From: support@securiteam.com
To: list@securiteam.com
Date: Mon, 11 Mar 2002 23:16:54 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Unchecked Buffer in Windows Shell Could Lead to Code Execution
------------------------------------------------------------------------

SUMMARY

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 affect 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.

DETAILS

Vulnerable systems:
- Microsoft Windows 98
- Microsoft Windows 98 Second Edition
- Microsoft Windows NT 4.0
- Microsoft Windows NT 4.0 Terminal Server Edition
- Microsoft Windows 2000

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.

Patch availability:
Download locations for this patch
Windows 98
 <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37015>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37015
Windows NT 4.0
 <http://www.microsoft.com/downloads/release.asp?ReleaseID=36867>
http://www.microsoft.com/downloads/release.asp?ReleaseID=36867
Windows NT 4.0 with Active Desktop
 <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37015>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37015
Windows NT 4.0 Terminal Server Edition
 <http://www.microsoft.com/downloads/release.asp?ReleaseID=36869>
http://www.microsoft.com/downloads/release.asp?ReleaseID=36869
Windows NT 2000
 <http://www.microsoft.com/downloads/release.asp?ReleaseID=36880>
http://www.microsoft.com/downloads/release.asp?ReleaseID=36880

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.

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
<http://support.microsoft.com/default.aspx?scid=kb;EN-US;q216840> Q216840.

ADDITIONAL INFORMATION

This vulnerability was discovered by <http://www.eeye.com> eEye Digital
Security.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.