Original release date: June 19, 2000<BR>
Last revised: July 03, 2003<BR>
Source: CERT/CC<BR>

<P>A complete revision history is at the end of this file.

<A NAME="affected">
<H3>Systems Affected</H3>

<UL>
<LI>Systems running Microsoft Internet Explorer</LI>
</UL>

<A NAME="overview">
<H2>Overview</H2>

<P>The HHCtrl ActiveX control has a serious vulnerability that allows
remote intruders to execute arbitrary code, if the intruder can cause
a compiled help file (CHM) to be stored "locally."  Microsoft has
released a security bulletin and a patch for this vulnerability, but
the patch does not address all circumstances under which the
vulnerability can be exploited. This document discusses some of the
additional ways in which this vulnerability can be exploited. Some
common circumstances under which this vulnerability can be exploited
are addressed by the Microsoft patch; others are not. Read this
document carefully with your network configuration in mind to
determine if you need to take any action. In recent discussions with
the CERT/CC, Microsoft has indicated they do not plan to alter the
patch.
<p>
More recent information is available in Vulnerability Note <a
href="http://www.kb.cert.org/vuls/id/25249">VU#25249</a>, including an updated
<a href="http://www.kb.cert.org/vuls/id/25249#solution">solution</a>.
<p>

<A NAME="description">
<H2>I. Description</H2>

<P>The Microsoft Windows HTML help facility (part of Internet
Explorer) is able to execute arbitrary programs through an embedded
"shortcut" in a compiled HTML file.  This allows the help system to
start wizards and other programs as part of the help facility.
Unfortunately, it also makes it unsafe for users to open help files
obtained from untrusted sources.

<P>An attacker who can construct a malicious help file and place it in
a location accessible by the victim may be able to cause this help
file to be loaded and the embedded shortcuts executed without
interaction from the victim.  A malicious web site author may cause a
compiled HTML help file to be opened through the Active Scripting
<I>showHelp</I> call in Internet Explorer.  Help files may also be
opened in other environments that support Active Scripting, such as
email messages in Outlook.

<P>The specific exploit described (and corrected) by Microsoft
involves an attacker who makes the malicious help files available via
a UNC share.  The patch corrects this aspect of the problem by
allowing help files to execute shortcuts only when "located on the
user's local machine."  More information about Microsoft's security
bulletin and their patch is available from

<DL>
<DD>
<A HREF="http://microsoft.com/technet/security/bulletin/ms00-037.asp">
http://microsoft.com/technet/security/bulletin/ms00-037.asp</A>
<DD>
<A HREF="http://microsoft.com/technet/security/bulletin/fq00-037.asp">
http://microsoft.com/technet/security/bulletin/fq00-037.asp</A>
</DL>

<H4>Preconditions Required for Exploitation</H4>

<P>Unfortunately, the Microsoft patch does not address several
significant ways in which the vulnerability can be exploited.  The
vulnerability can be exploited in any situation where all of the
following conditions are met:

<OL>

<P><LI>The attacker must entice or compel a victim who has Active
Scripting enabled to open an email message or visit a web page.
Alternatively, the attacker could attempt to trick the victim into
opening the compiled help file, such as by sending it as an attachment
in an email message.  Since it is not yet widely recognized that help
files have the potential to be just as dangerous as an untrusted
executable, this may not be difficult.

<P><LI>The attacker must be able to place a malicious help file in a
location accessible to the user when the Active Script is executed.
The attacker must also be able to predict or guess the path to this file.
If the patch described in <A
href="http://microsoft.com/technet/security/bulletin/ms00-037.asp">Microsoft
Security Bulletin MS00-037</a> has been applied, this file may not
reside on a UNC share (\\hostname\path\file). That is, if the patch
has not been installed, an intruder must be able to place a file
anywhere that the victim can access it. If the patch has been
installed, the intruder must be able to place a file anywhere that the
victim can access it except on UNC shares.

<P><LI>The Active Script mentioned above must run in a security zone
that allows ActiveX controls to run and allows the scripting of
controls that are marked "safe for scripting."  The default security
settings for the Internet Zone and the My Computer zone allow these
actions to occur without warning prompts.

<P><LI>The HHCtrl ActiveX control must be installed and be marked
"safe for scripting" and "safe for initialization."  This is the
default configuration when Internet Explorer is installed.

</OL>

<p>Note that all of these conditions, some of which are default
conditions, must be met in order for an attacker to exploit this
vulnerability. Changing some of these conditions may involve
trade-offs between functionality and security. 

<P>In recent discussions with the CERT/CC, Microsoft has not indicated
any intention of changing the help system's behavior.  Therefore, to
be completely protected from exploitation of this vulnerability, users
must eliminate one or more of the preconditions listed above.

<P>It is reasonable for a user to expect that simply visiting a web
page is a safe activity, so eliminating the first precondition is
difficult.  Disabling Active Scripting or the execution of ActiveX
controls prevents the vulnerability from being exploited, but it also
prevents the normal operation of these features and is likely to
affect the appearance and functionality of web pages.  Removing the
"safe for initialization" or "safe for scripting" attributes of the
HHCtrl causes warning dialogs to be generated in a number of
circumstances where they may not be expected.

<H4>How an Attacker May Create "Local" Files</H4>

<P>Although you may believe it is difficult or impossible for an
intruder to place a file in a predictable location that is accessible
to you, in fact, several common practices allow intruders to do just
this.

<P>While preventing an attacker from downloading files on the local
system without warning is a valuable security practice, it is not
sufficient as the single line of defense against the <B>execution</B>
of malicious code.  The CERT/CC recommends adopting one of several
more conservative solutions, including disabling ActiveX controls or
Active Scripting.  More information on these solutions are included in
the <A HREF="#solution">Solution</A> section of this document.

<P>If a site relies solely on limiting the attacker's ability to make
malicious code accessible to the victim, the following activities are
not safe:

<UL>

<P><LI>Sharing files via a network filesystem such as AFS, DFS, NFS,
Novell Netware, or Windows shares when users map these drives to local
drive letters.  When the drive letter is not predictable but the path
to the file is, the attacker may be able to make multiple exploit
attempts because failed calls to <I>showHelp</I> generate no error
messages.  Access control lists cannot be used to defend yourself
against this problem because the ACL facility allows the intruder to
give you access to malicious files they control without your consent.

<P><LI>Sharing physical disk drives in environments such as academic
labs, Internet cafes, or libraries, where an attacker may be able to
store malicious files in a writable local directory.

<P><LI>Using any of several products that automatically extract
attachments from email messages and place them in predictable
locations.  A notable example of this is Eudora.

<P><LI>Using chat clients such as IRC-II, ICQ, or AOL Instant
Messenger in modes that allow unsolicited file transfers to be placed
in a local directory.

<P><LI>Hosting an anonymous FTP site, if the upload directory is
accessible by local users.

</UL>

<P>Without other solutions, engaging in any of these activities
renders a site vulnerable to the problem described in this advisory.
Additionally, several other vulnerabilities have been discovered
recently whose impact was limited to the ability to download arbitrary
files to the victim's system.  If they are exploited in conjunction
with this vulnerability, the impact is more significant, as discussed
in the next section.

<A NAME="impact">
<H2>II. Impact</H2>

<P>By using the <I>showHelp</I> Active Scripting call in conjunction
with shortcuts embedded in a malicious help file, attackers are able
to execute programs and ActiveX controls of their choice.  Since
exploitation of the vulnerability requires an attacker to place a
compiled help file (CHM) in a location accessible to the victim, it is
usually trivial to include a malicious executable as well.  In this
situation, the attacker can take any action that the victim can.

<P>The essence of the problem is this:

<DL><DD> 

<B>The ability for an intruder to make a file accessible to a victim
running Internet Explorer is equivalent to the ability to execute
arbitrary code on the victim's system if several common preconditions
are met.</B>

</DL>

<A NAME="solution">
<H2>III. Solution</H2>

<P>The CERT/CC developed the information in the solution section based
on our independent tests using primarily Internet Explorer 5 on
Microsoft Windows NT 4.0 and Windows 2000. Your results will vary
based on your particular configuration.

<p>For some sites, the patch provided by Microsoft is adequate. For
others, particularly those sites using non-Microsoft networking
products, the patch does not provide complete protection. You will
need to understand your network's configuration prior to deciding
which, if any, changes are appropriate. 

<H4>Configure Outlook to read email in the Restricted Zone.</H4>

<P>Because an email message may start Internet Explorer automatically
if Active Scripting is enabled, the CERT/CC encourages you to
configure your Outlook email client to use the Restricted Zone, and to
disable Active Scripting in this zone.  This solution should be
implemented in addition to one of the changes mentioned earlier.

<P>The steps for configuring Outlook to use the Restricted Zone are:

<OL>
<LI>Start Outlook as you normally would.

<LI>From the <B>Tools</B> menu select <B>Options...</B>. The
Options dialog box appears.

<LI>Select the <B>Security</B> tab. The Security Options panel
appears.

<LI>In the <B>Secure content</B> section, change the pull-down menu
from <B>Internet</B> to <B>Restricted Sites</B>.

<LI>Click <B>Apply</B> to save your changes.

<LI>Click <B>OK</B> to close the Options dialog box.

</OL>

<p>We recommend similar steps for any other mail clients that support
Active Scripting and Security Zones (or similar facilities to prevent
the unwanted execution of scripts).


<H4>Disable Active Scripting and/or ActiveX controls in the Internet
Zone.</H4>

<P>One way to prevent the exploitation of this vulnerability is to
limit the functionality available to attackers through the security
zone feature of Internet Explorer.  The CERT/CC recommends this
solution as a way to protect against the vulnerability while retaining
as much functionality as possible in the help system.

<P>A security zone is a set of security settings applied to a web page
based on the site the web paged originated from.  By default, all
sites are in the Internet Zone, and disabling functionality in this
zone can protect you from attackers at all sites not associated with
another zone.

<P>You may also need to reduce the settings in the Local Intranet
Zone, if you do not trust all web sites within your DNS domain.  In
fact, the risk of exploitation by an inside attacker may be greater,
since the ability to create a file accessible by you may be easier
within a local area network.

<P>One or more of the following options must be changed in the
appropriate zones to protect against the vulnerability:

<UL>

<P><LI>The <B>Active Scripting</B> option

<P>Disabling Active Scripting is perhaps the best solution since it
prevents the vulnerability from being exploited and doesn't present
the user with warning dialogs.  Setting this option to "Prompt" is
<B>not</B> recommended, because the warning dialog will incorrectly
imply that the action is safe, when in fact it is not.

<P><LI>The <B>Run ActiveX controls and plug-ins</B> option

<P>Disabling the execution of ActiveX controls is an option that
protects against this vulnerability, but it also prevents plug-ins
from executing normally.  Since plug-ins for common applications such
as Adobe Acrobat are included in this same category, setting the
option to "Disable" results in significantly reduced functionality.
For similar reasons, setting this option to "Prompt" is not
recommended, because it is not always clear what the safe response
should be.

<P>An excellent solution (but perhaps requiring more administrative
effort) is to set this option to "Administrator approved".  In this
setting, only those ActiveX controls approved by the administrator
(using the Internet Explorer Administration Kit) will be executed.  If
the administrator includes most controls but specifically excludes the
HHCtrl control, there is an attractive balance between security and
functionality. For more information regarding this option, see

<dl>
<dd>
<a
href="http://www.microsoft.com/Windows/ieak/en/support/faq/default.asp">http://www.microsoft.com/Windows/ieak/en/support/faq/default.asp</a>
</dd>
</dl>

<P><LI>The <B>Script ActiveX controls marked safe for scripting</B> option

<P>Disabling the scripting of ActiveX controls marked "safe for
scripting" protects against this vulnerability but limits the normal
operation of many controls used over the Internet.  Setting this
option to "Prompt" generates a warning dialog that is not strongly
enough worded to reflect the danger inherent in the HHCtrl control.

</UL>

<P>If all three of these options are set to "Enable", which is the
default in the Internet Zone, this vulnerability may be exploited.
Improving the security settings of any of these three options will at
least cause a warning dialog to appear and may prevent the exploit
entirely.

<P>Steps for changing your security zone settings for Internet
Explorer 5 on Windows NT 4.0 are:

<OL>

<LI>Start Internet Explorer as you normally would.

<LI>From the <B>Tools</B> menu select <B>Internet Options...</B>. The
Internet Options dialog box appears.

<LI>Select the <B>Security</B> tab. The Security Options panel
appears.

<LI>Select the zone you wish to change.  For most users, this is the
<B>Internet</B> Zone, but depending on your circumstances, you may
need to repeat these steps for the <B>Local Intranet</B> Zone as well.

<LI>Click the <B>Custom Level</B> button. The Security Settings panel
appears.

<LI>Change one or more of the following settings based on the
information provided earlier and your desired level of security.

<OL TYPE="a">

<LI>Set <B>Run ActiveX controls and plug-ins</B> to administrator
approved, disable, or prompt.

<LI>Set <B>Script ActiveX controls marked safe for scripting</B> to
disable or prompt.

<LI>Set <B>Active scripting</B> to disable or prompt.


</OL>

<LI>Click <B>OK</B> to accept these changes. A dialog box appears
asking if you are sure you want to make these changes.
 
<LI>Click <B>Yes</B>.

<LI>Click <B>Apply</B> to save your changes.

<LI>Click <B>OK</B> to close the Internet Options dialog box.
</OL>

<P>Security zones can also be used to enable Active Scripting and
ActiveX controls at specific sites where you wish to retain this
functionality.  To place a site in the Trusted Sites Zone using
Internet Explorer 5.0 on Windows NT 4.0,

<OL>

<LI>Start Internet Explorer as you normally would.

<LI>From the <B>Tools</B> menu select <B>Internet Options...</B>. The
Internet Options dialog box appears.

<LI>Select the <B>Security</B> tab. The Security Options panel
appears.

<LI>Select the <B>Trusted Sites</B> Zone.

<LI>Click the <B>Sites...</B> button.

<LI>Enter the name of the trusted site in the <B>Add this Web Site to
the zone:</B> text box.

<LI>Click the <B>Add</B> button.

<LI>If a dialog box appears saying "Sites added to this zone must use
the https:// prefix.  This prefix assures a secure connection":


<OL TYPE="a">

<LI>Click <B>OK</B>.

<LI>Add https:// to the beginning of the site name, and try to add the
site again.

<LI>Or uncheck the box at the bottom of the dialog box marked
<B>Require server verification (https:) for all sites in this
zone.</B> Making this change reduces the security of your system by
not requiring certificate based authentication, relying instead on DNS
based verification which could be misleading.  The CERT/CC encourages
you not to make this change unless you fully understand the
implications.  If you choose not to require certificate based
verification, you may wish to reduce other security settings for the
Trusted Sites Zone.

</OL>

<LI>Click <B>OK</B> to save the new list of sites.

<LI>Click <B>Apply</B> to save your changes.

<LI>Click <B>OK</B> to close the Internet Options dialog box.

</OL>

<p>Steps for managing Security Zones in other versions of Windows and
Internet Explorer are similar. 

<H5>The "My Computer" Zone</H5>
<p>In addition to the four zones that are ordinarily visible, there is
a fifth zone called the "My Computer" zone which is not ordinarily
visible. Files on the local system are in the "My Computer" zone. You
can examine and modify the settings in the "My Computer" through the
registry. For more information, see

<dl>
<dd>
<A
HREF="http://support.microsoft.com/support/kb/articles/Q182/5/69.ASP">http://support.microsoft.com/support/kb/articles/Q182/5/69.ASP</a>
</dd>
</dl>

<p>The "My Computer" zone may also be managed through the Internet
Explorer Administration Kit (IEAK). 

<p>The CERT/CC does not recommend modifications to the "My Computer"
zone unless you have unusual security requirements and a thorough
understanding of the ramifications, including the potential for loss
of functionality. 

<p>Note, however, that if there is a vulnerability or condition that
allows an attacker to create a file locally (such as through Eudora,
for example) then this file will be subject to the security settings
of the "My Computer" zone. 

<p>Active Scripts on a web page or in a mail message will continue to
be subject to the security settings of the zone where the web page or
mail client resides. In this case, disabling Active Scripting in
untrusted locations, including the Internet Zone, provides the best
defense.


<H4>Change the attributes of the HHCtrl ActiveX control.</H4>

<P>Because the HHCtrl control is central to the exploitation of this
vulnerability, removing either the "safe for scripting" or the "safe
for initialization" attribute in the registry corrects the problem.
Unfortunately, removing these attributes prevents some features of the
help system from operating normally, even if the help file is opened
through some other application.

<P>Implementing this solution will allow other ActiveX controls to
function, including those referenced in Internet web pages.  If you
are unable to implement one of the solutions mentioned earlier, or you
are willing to sacrifice help system features for more complete
ActiveX functionality, then you may wish to consider this solution.
This solution will provide warning dialogs when users open help files
--  both malicious and benign help files.

<P>To mark the HHCtrl ActiveX control as <B>not</B> "safe for
scripting", remove this registry key:

<DL><DD>
HKEY_CLASSES_ROOT\CLSID\ {ADB880A6-D8FF-11CF-9377-00AA003B7A11}\
Implemented Categories\ {7DD95801-9882-11CF-9FA9-00AA006C42C4}
</DL>

<P>To mark the HHCtrl ActiveX control as <B>not</B> "safe for
initialization", remove this registry key:

<DL><DD>
HKEY_CLASSES_ROOT\CLSID\ {ADB880A6-D8FF-11CF-9377-00AA003B7A11}\
Implemented Categories\ {7DD95802-9882-11CF-9FA9-00AA006C42C4}
</DL>

<P>Spaces in the keys listed above were added to improve HTML
formatting and are not in the actual registry keys.

<P>Only one of the two changes need to be made in order to prevent the
exploitation of this vulnerability.  Either of these changes will
result in additional warning dialogs when a user opens compiled help
files with references to the HHCtrl control, even if the help file is
part of legitimate locally installed software.


<H4>Avoid accessing filesystems writable by untrusted users.</H4>

<P>Because of the difficulty in implementing this solution correctly,
the CERT/CC does not recommend relying on this solution.  You may want
to consider this solution only if you can implement it easily or if
you have no other viable choices.

<P>Care should be taken with any mechanism that might allow an
untrusted user to download or otherwise cause a file to be accessible
to the victim.  This includes, but is not limited to, network-based
file sharing mechanisms (AFS, DFS, Netware, NFS, Windows shares) and
mail delivery programs that automatically extract attachments.

<P>Also, if you choose to implement this solution, you need to be
especially vigilant in your monitoring of security resources for
information about new vulnerabilities that allow attackers to download
files to your system.  The impact of these vulnerabilities will be
greater than if you had selected one of the solutions recommended
above.

<A NAME="vendors">
<H2>Appendix A. Vendor Information</H2>

<A NAME="microsoft">
<H4>Microsoft Corporation</H4>

Microsoft recommends customers using Microsoft Internet Explorer
version 4.0, 4.01, 5.0, or 5.01 apply the patch discussed in <A
HREF="http://microsoft.com/technet/security/bulletin/ms00-037.asp">http://microsoft.com/technet/security/bulletin/ms00-037.asp</a>
and routinely use the Security Zones feature.

<p>The Security Zones feature of Internet Explorer allows you to
categorize the web sites you visit and specify what the sites in a
particular category should be allowed to do.  Since most people visit
a small number of familiar, professionally-operated web sites, and
it's unlikely that such a site would pose any risk, we recommend
putting the sites that you visit frequently and trust into the Trusted
Zone.  All sites that you haven't otherwise categorized will reside in
the Internet Zone.  You can then configure the zones to give the
appropriate privileges to the web sites in each of these zones.

<p>In addition Microsoft recommends Outlook users install the Outlook
Security Update <A
HREF="http://www.officeupdate.com/2000/downloaddetails/Out2ksec.htm">http://www.officeupdate.com/2000/downloaddetails/Out2ksec.htm</a>
to protect against mail-borne attacks.



<HR NOSHADE>

<P>Thanks to Georgi Guninski, who originally discovered this
vulnerability and who also provided input used in the development of
this advisory.

<P></P>

<HR NOSHADE>

<P><A HREF="mailto:cert@cert.org?subject=CA-2000-12%20Feedback">Cory
Cohen</A> was the primary author of this document, with some text by
Shawn Hernan. 

<P></P>

<!--#include virtual="/include/footer_nocopyright.html" -->

<P>Copyright 2000 Carnegie Mellon University.</P>

<P>Revision History
<PRE>
June 19, 2000:  Initial release
July 03, 2003:  Added reference to VU#25249
</PRE>