Microsoft Security Bulletin MS02-055

Technical description:

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.

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

Severity Rating:

Buffer Overrun in HTML Help ActiveX Control:  

Code Execution via Compiled HTML Help File:

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.

Vulnerability identifier:

• Buffer Overrun in HTML Help ActiveX Control: CAN-2002-0693
• Code Execution via Compiled HTML Help File: CAN-2002-0694

Tested Versions:

Microsoft tested the HTML Help facilities in Windows 98, Windows 98 SE, 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 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:

1. In Internet Explorer, select Tools, then Internet Options. Select the Security tab.
2. 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.
3. 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).
4. 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 (CAN-2002-0693):

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 a specially 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 a specially 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 (CAN-2002-0694):

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, an 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.

Download locations for this patch

The patches for all Windows systems are available via Windows Update or can be manually applied via the following patches:

• Windows 98 and Windows 98 SE:

  http://support.microsoft.com/ph/1139

• Windows Me:

  Only available via Windows Update.

• Windows NT 4.0:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=2CC66F4E-217E-4FA7-BDBF-DF77A0B9303F&displaylang=en

• Windows NT 4.0, Terminal Server Edition:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=6C0F0160-64FA-424C-A3C1-C9FAD2DC65CA&displaylang=en

• Windows 2000:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=C8B8A846-F541-4C15-8C9F-220354449117&displaylang=en

• Windows XP:
  • 32-bit Edition
  • 64-bit Edition