[NT] Unchecked Buffer in Windows Help Facility Could Enable Code Execution

From: support@securiteam.com
Date: 10/04/02

Previous message: support@securiteam.com: "[NT] Flaw in Services for UNIX 3.0 Interix SDK Could Allow Code Execution"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: support@securiteam.com
To: list@securiteam.com
Date: Fri,  4 Oct 2002 22:37:24 +0200 (CEST)

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 Help Facility Could Enable Code Execution
------------------------------------------------------------------------

SUMMARY

The HTML Help facility in Windows includes an ActiveX control that
provides much of its functionality. One of the functions exposed via the
control contains an unchecked buffer, which could be exploited by a web
page hosted on an attacker's site or sent to a user as an HTML mail. An
attacker who successfully exploited the vulnerability would be able to run
code in the security context of the user, thereby gaining the same
privileges as the user on the system.

A second vulnerability exists because of flaws associated with the
handling of compiled HTML Help (.chm) files that contain shortcuts.
Because shortcuts allow HTML Help files to take any desired action on the
system, only trusted HTML Help files should be allowed to use them. Two
flaws allow this restriction to be bypassed. First, the HTML Help facility
incorrectly determines the Security Zone in the case where a web page or
HTML mail delivers a .chm file to the Temporary Internet Files folder and
subsequently opens it. Instead of handling the .chm file in the correct
zone - the one associated with the web page or HTML mail that delivered it
- the HTML Help facility incorrectly handles it in the Local Computer
Zone, thereby considering it trusted and allowing it to use shortcuts.
This error is compounded by the fact that the HTML Help facility doesn't
consider what folder the content resides in. Were it to do so, it could
recover from the first flaw, as content within the Temporary Internet
Folder is clearly not trusted, regardless of the Security Zone it renders
in.

The attack scenario for this vulnerability would be complex, and involves
using an HTML mail to deliver a .chm file that contains a shortcut, then
making use of the flaws to open it and allow the shortcut to execute. The
shortcut would be able to perform any action the user had privileges to
perform on the system.

Before deploying the patch, customers should familiarize themselves with
the caveats discussed in the FAQ and in the Caveats section below.

DETAILS

Affected Software:
* Microsoft Windows 98
* Microsoft Windows 98 Second Edition
* Microsoft Windows Millennium Edition
* Microsoft Windows NT 4.0
* Microsoft Windows NT 4.0, Terminal Server Edition
* Microsoft Windows 2000
* Microsoft Windows XP

Mitigating factors:
Buffer Overrun in HTML Help ActiveX Control:
* The HTML mail-based attack vector could not be exploited on systems
where Outlook 98 or Outlook 2000 were used in conjunction with the Outlook
Email Security Update, or Outlook Express 6 or Outlook 2002 were used in
their default configurations.

* The vulnerability would convey only the user's privileges on the
system. Users whose accounts are configured to have few privileges on the
system would be at less risk than ones who operate with administrative
privileges.

Code Execution via Compiled HTML Help File:
* The vulnerability could not be exploited via a web site.

* The vulnerability could only be exploited if the attacker were able to
determine the exact location of the Temporary Internet Files folder. By
design, this should not be possible, and Microsoft is unaware of any means
for doing so which has not already been patched.

What vulnerabilities are eliminated via this patch?
This patch eliminates several issues involving the HTML Help facility:
* A security vulnerability that could enable an attacker to gain complete
control over a system and take any action that the legitimate user could
take.

* A security vulnerability with the same scope as the first
vulnerability, but which could be exploited only if the attacker had
already breached the user's security to a significant degree.

Are there any caveats associated with the patch?
Yes. Customers should be aware of two caveats associated with the patch:

* It requires that Internet Explorer 5.01, 5.5, or 6 be installed on the
system. This is needed because the patch requires functionality that
didn't exist prior to these versions of Internet Explorer.

* Although the vulnerabilities here involve an ActiveX control, the patch
does not set the "Kill Bit".

What's an ActiveX control?
ActiveX controls are small, single-purpose programs that can be called by
programs and web pages. ActiveX allows a programmer to write a piece of
software one time, and make its functionality available to other programs
that may need it.

What's the "Kill Bit"?
The Kill Bit is a method by which an ActiveX control can be prevented from
ever being invoked via Internet Explorer, even if it's present on the
system. (More information on the Kill Bit is available in Microsoft
Knowledge Base article Q240797). Typically, when a security vulnerability
involves an ActiveX control, the patch delivers a new control and sets the
Kill Bit on the vulnerable control. However, it isn't feasible to do so in
this case.

Why isn't it feasible to set the Kill Bit in the case?
The ActiveX control involved in these vulnerabilities implements the
entire Windows Help system. Many applications, including third-party
applications, contain hard-coded references to it; if the patch set the
Kill Bit, those programs' help facilities would no longer be available. As
a result, the patch updates the control to remove the vulnerabilities, but
does not provide a brand-new control and set the Kill Bit on the old one.

What are the risks associated with taking this approach?
Because the ActiveX control at issue here has been digitally signed by
Microsoft, and the signature is still valid, it could be possible under
certain conditions for an attacker to re-introduce the old, vulnerable
version of the control onto a system that had been patched, thereby making
it vulnerable again.

To re-introduce the vulnerable version of the control, an attacker would
need to use either of two means, both of which could be mitigated. The
attacker could attempt either of the following two methods:

Lure a user to a web page that, when viewed, would download the old
control to the user's system.
Send an HTML mail to a user which, when opened, would download the old
control to the user's system.

What could users do to mitigate the risk from a web site?
Only a small number of web sites on the Internet are operated by malicious
people. The vast majority of web sites treat visitors with respect.
Customers who visit well-known web sites are at very little risk. However,
customers who wish to take precautions against a web site re-introducing
the vulnerable version of the control should disable the downloading
ActiveX controls, as follows:

* In Internet Explorer, select Tools, then Internet Options. Select the
Security tab.
* In the box labeled "Select a web content zone.." click on the Internet
zone. Next, click on the "Custom Level" button at the bottom of the dialog
box.
* In the next dialog box, locate the "ActiveX Control and Plug-ins"
section (it should be the topmost section). Then locate the option labeled
"Download Signed ActiveX controls" (it should be the topmost option within
the section).
* Select "Disable". Click OK to exit the dialog, then click OK to close
the Internet Options dialog.

What can users do to mitigate the risk from an HTML mail?
Customers who are running Outlook Express or Outlook 2002 in the default
configuration are at no risk from an email-based attack. Likewise,
customers running Outlook 98 or Outlook 2000, and who have installed the
Outlook Email Security Update are at no risk. In all of these cases,
downloading of signed ActiveX controls via email is already disabled.

Will Microsoft eventually set the Kill Bit on this control?
Yes. Microsoft is developing a new technology that will enable it to set
the Kill Bit on the vulnerable version of the control, without losing the
ability for applications to use the Help facility. When the new technology
is available, we will ensure that this fix uses it.

Buffer Overrun in HTML Help ActiveX Control:
What's the scope of this vulnerability?
This is a buffer overrun vulnerability. An attacker who was able to
exploit this vulnerability could take any action the legitimate user could
take; for instance, the attacker could add, delete or change data files,
download and run programs, communicate with web sites, reformat the hard
drive, or take other actions. The vulnerability could be exploited either
by luring a user into visiting a web site controlled by the attacker, or
by sending a specially constructed HTML mail to a user.

The vulnerability is subject to several constraints:
* The attacker would gain the same privileges as the user, but no more.
Users whose accounts are configured to have few privileges on the system
would be at less risk than ones who operate with administrative
privileges.

* Customers who use Outlook 98 or Outlook 2000 in conjunction with the
Outlook Email Security Update, or who use Outlook Express 6 or Outlook
2002, would be at no risk from the email-based attack vector.

What causes the vulnerability?
The vulnerability results because the ActiveX control that implements the
HTML Help facility contains an unchecked buffer in one of the functions it
exposes. If the function was called using an especially malformed
argument, it could have the effect of overrunning the buffer.

What's the HTML Help facility?
All recent versions of Windows include a standardized HTML-based help
facility, through which any application running on Windows can display
help information for users. This has several advantages:

* It allows all applications to provide a consistent user experience.

* It allows animation, hyperlinks, and other web-based features to be
used in order to provide more effective help information.

* It shortens development time by allowing developers to avoid
implementing their own help systems.

How is the HTML Help facility implemented?
It's implemented in part as an ActiveX control. This allows it to be
called both by GUI-based and web-based applications - potentially
including web sites.

What's wrong with the HTML Help facility?
The facility provides a number of different functions that applications
can use when displaying their help information. However, one of those
functions contains an unchecked buffer, and this flaw poses a security
vulnerability.

What could an attacker do via the vulnerability?
An attacker who invoked the HTML Help facility and called the affected
function using an especially malformed parameter could modify the
functionality of the HTML Help facility and cause it to perform actions of
the attacker's choice. This could include adding, deleting or changing
data on the system, running programs, downloading or uploading data, or
virtually any other action that the user could take. In essence, it would
let the attacker pose as the user on the system.

But couldn't an application do this already? After all, it would already
running on the user's computer.
It's true that if a program is running on a system, it can by definition
do anything the user can do. In such a case, the First Immutable Law of
Security applies ("If a bad guy can persuade you to run his program on
your computer, it's not your computer anymore"). However, recall that it's
not just applications on the user's system that can use the HTML Help
facility - it also can be invoked by a web page. That's why there's a
security vulnerability here.

An attacker who wished to exploit the vulnerability could create a web
page that, when rendered within the browser, calls the HTML Help facility
and invokes the function that contains the vulnerability. If the page were
posted on the attacker's web site, any user who visited the site could be
attached. On the other hand, if the attacker sent the page directly to the
user as an HTML mail, it would trigger the vulnerability when the user
opened it.

Is there any way to prevent an attack via a web site?
Yes. One way would be to use the Internet Explorer Security Zones
mechanism, which allows you to regulate what actions web sites can take on
your system. A site located in the Restricted Sites Zone, for instance,
could not exploit this vulnerability because of the more restrictive
security settings there. Specifically, web pages in the Restricted Sites
Zone are prevented from invoking ActiveX controls.

Is there any way to prevent an attack via an HTML mail?
Yes. Outlook and Outlook Express rely on Internet Explorer to display the
contents of HTML mails, and you can use the same Security Zones mechanism
to regulate what HTML mail can do. Customers who are using Outlook Express
6 or Outlook 2002 are at no risk from an attack via HTML mail, because
these products by default open mail in the Restricted Sites Zone.
Similarly, customers using Outlook 98 or 2000, and who have installed the
Outlook Email Security Update, are at no risk - again, because in such a
configuration, HTML mail is opened in the Restricted Sites Zone

How does the patch address the vulnerability?
The patch corrects the unchecked buffer.

Code Execution via Compiled HTML Help File:
What's the scope of this vulnerability?
This vulnerability could enable an attacker to take any action on another
user's computer that the user could take, limited only by the privileges
the user possessed on the system. As in the case above, this could enable
an attacker to take a wide array of destructive actions.

The vulnerability could only be exploited if other known security
vulnerabilities, for which patches are available, have not been applied.
The patch provided here will prevent the vulnerability from being
exploited under any conditions.

What causes the vulnerability?
The vulnerability results because of two independent flaws involving how
compiled HTML Help (.chm) files are handled:

The HTML Help Facility uses the IE Security Zones mechanism to determine
what restrictions to place upon a compiled HTML Help file, but does this
incorrectly in some cases.
There is no restriction on which compiled HTML Help files can contain
shortcuts.

What are compiled HTML Help files?
A compiled HTML (.chm) file is comprised of a web page containing help
text, along with several other files. Compiling a help file helps minimize
the space that a help file occupies on a disk.

Of particular interest in this case is the fact that .chm files can
contain shortcuts. Shortcuts allow HTML Help files to link to and execute
code. This feature allows the help topic to either demonstrate a point to
the user, or to perform a function for him. For example, if you search for
help on adding a printer in Windows 2000, there's a shortcut that will let
you go directly to the Printers folder in Control Panel and start the
wizard that adds a printer.

What's wrong with the way HTML Help handles compiled HTML Help files?
There are two problems. The first involved how the HTML Help facility
assesses the Internet Explorer Security Zone that a compiled HTML Help
file should be handled in, for the case in which the file was downloaded
as part of a web page.

Anytime a file is delivered to a user's system as part of a web page, it's
stored in the Temporary Internet Files folder (which is also known as the
Internet Explorer cache). Under most conditions, when a file located on
the user's system is opened in Internet Explorer, it's opened in the Local
Computer Zone. Files located in the Temporary Internet Files folder,
though, are a special case - they've been delivered by a web page, and
should be subject to the same restrictions as the page itself. As a
result, files in the Temporary Internet Files folder should always open in
the Security Zone associated with the web page that delivered them.

The first flaw occurs because the HTML Help facility doesn't rely on
Internet Explorer to determine the zone for compiled HTML Help files, but
instead determines the zone itself, and does so incorrectly. Specifically,
it incorrectly uses the Local Computer Zone when opening the file, which
grants the file greater latitude than it warrants, and opens the door for
the second flaw to be exploited.

What's the second flaw?
The HTML Help facility restricts when a shortcut in a compiled HTML Help
file can be executed, but it doesn't do so adequately. The Help facility
only allows an HTML Help file to use a shortcut if it's reckoned in the
Local Computer Zone. But it should also check which folder the file is in,
and bar it from using a shortcut if it's in a folder that - like the
Temporary Internet Files folder - contains untrustworthy content.

How do these flaws combine to create a security vulnerability?
Suppose an attacker were able to deliver a compiled HTML Help file
containing a shortcut into the Temporary Internet Files folder on a user's
computer. Because of the first flaw, if the attacker were able to open the
file by some means, it would do so in the Local Computer Zone. And because
of the second flaw, this would be sufficient to allow the shortcut in the
file to execute. Once that happened, the attacker's shortcut could take
any action it was programmed to take on the user's system.

But how would the attacker deliver the file to the Temporary Internet
Files folder and open it?
Delivering the file to the Temporary Internet Files folder isn't
particularly difficult - it could easily be done by sending the user a
specially constructed HTML mail. However, the second step - opening the
file - could be quite difficult. By design, web pages should not be able
to directly open files in the Temporary Internet Files folder. The ability
to do this is itself a security vulnerability, and Microsoft would
immediately develop a patch to block such a case.

How does the patch address the vulnerability?
The patch takes two steps to address the vulnerability. First, it changes
how HTML Help determines the Security Zone for HTML files. After applying
the patch, the HTML Help facility relies on Internet Explorer to identify
the zone, rather than attempting to determine the zone by itself.

Second, the patch institutes a new check that restricts where an HTML Help
file can reside if it contains a shortcut. After applying the patch, HTML
Help can only use shortcuts if it's not located in a folder that's known
to contain untrusted content. For instance, on Windows 2000 and XP
systems, shortcuts would only operate if the file were contained in one of
the following folders (or any of their subfolders):

%windir%/help
%windir%/pchealth/helpctr
%program files%

Is there any way to change the list of folders in which shortcuts are
allowed?
Yes. The patch also creates a new system policy for Windows 2000 and XP
systems, called "Restrict potentially unsafe HTML Help functions to
specified folders". System administrators can use this policy to customize
the list of folders in which HTML Help files can use shortcuts. The policy
sets the HelpQualifiedRootDir key under the System Administrative
Template.

ADDITIONAL INFORMATION

The information has been provided by
<mailto:0_37890_E51E4D7D-DECD-43AE-9A29-36080E8D4C3C_US@Newsletters.Microsoft.com> Microsoft.

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

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.

Previous message: support@securiteam.com: "[NT] Flaw in Services for UNIX 3.0 Interix SDK Could Allow Code Execution"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]