MSHTML, a.k.a. Trident, is the Internet Explorer browser rendering engine. MSHTML is a great solution for rendering HTML content, either in the context of a web browser, or simply to display rich UI in an application. You are likely not even aware of some of the many ways MSHTML is hosted within Windows and third party applications. For example, the Windows XP Add/Remove Programs control panel is implemented using MSHTML. Care must be taken in order to host MSHTML with appropriate security. This FAQ will help you avoid making some common MSHTML hosting mistakes.
MSHTML may be hosted directly or via SHDOCVW. The information in this FAQ applies to either hosting scenario unless otherwise specified.
The MSHTML Host Security FAQ – Part I
How do I evaluate the level of risk posed by my MSHTML hosting scenario?
Here’s how to quickly evaluate the risk of any MSHTML hosting scenario:
_Risk level 3: No arbitrary content
_There is low risk when MSHTML is simply displaying static content loaded from a local source (Ex: A resource file, HTML on the local drive, etc.). That is not to say there is zero risk. For example, think about any possibility that an attacker may force navigation of the host somehow, perhaps using a command line parameter passed via a registered protocol handler.
Risk level 2: Controlled content
It is possible to lock a MSHTML instance to a single site. However, when this is implemented without SSL, MitM (Man-in-the-middle) or DNS poisoning attacks can enable execution of script within the hosted MSHTML instance.
Even when SSL is used (and the certificate is validated), it can still be problematic to ensure that content rendered only comes from an “unhackable” / bulletproof site. Even if the source were secure, content coming from the source still should not have authorization to automatically execute arbitrary code on the user’s machine. This is in line with the general security principal of least privilege.
Really, all content should execute securely within the hosted MSHTML instance, no matter where the content appears to have originated. That being said, if the content source is locked down sufficiently, this does at least serve as a mitigating factor for potential vulnerabilities.
_Risk level 1: Fully arbitrary content
_In this case, the MSHTML host should not take any shortcuts in enforcing the same security as is applied within the Internet Explorer web browser. Otherwise, attacks may be possible within the MSHTML host that wouldn’t otherwise be possible within Internet Explorer.
One mitigating factor may be that the navigation would have to occur within the MSHTML host. For example, using Visual Studio to navigate to web sites is not a very common usage scenario. If the Visual Studio MSHTML host has a vulnerability, it may not be very practical to exploit. Still, clearly it must not be possible for web content within Visual Studio’s MSHTML instance to run arbitrary code, read local files, etc.
_Risk level 0: Fully arbitrary content available “zero-click” from e-mail or the web
_As an example, imagine a media player were to host MSHTML and allow arbitrary navigation. If certain security restrictions were in place in the browser but not in the media player hosting scenario, these restrictions could be immediately circumvented. (A media file presumably could cause the media player’s MSHTML instance to navigate to an arbitrary web site.) Web browsers serve as the vector for many real-world attacks so this is a compelling attack scenario that must be avoided.
How do I offer advanced functionality to HTML within my hosting environment, safely?
It is often desirable to expose some special functionality to content running within the hosted MSHTML instance. Heed the guidance in the “Elevated Sandbox” section in Part II of the FAQ and resist the temptation to enable unsafe behavior (execution of arbitrary system commands, etc.) within your MSHTML instance.
Some of the common MSHTML extensibility mechanisms include:
-
Window.external
It is possible to extend the DOM via window.external. An example of this would be a CD burning application that presents its user interface using MSHTML. This application could enable the user interface to trigger the CD burning functionality by exposing a method BurnToCD() off of window.external. For more information on the window.external extensibility mechanism, see: http://support.microsoft.com/kb/188015. The general security guidance above applies to this extensibility mechanism. -
_ActiveX
_It is possible for an ActiveX control to only operate, or to provide extra functionality, when hosted within a specific MSHTML environment. As an example, HTML Help provides an ActiveX control that enables some functionality only when hosted within HH.EXE. If you implement a similar solution, make sure that the special functionality is exposed only within your MSHTML host. One way to do this would be to validate the hosting process’s name. In this way you can avoid having your functionality unintentionally abused within the context of another application.There are ways to host an ActiveX control such that it is impossible for it to identify the URL of its hosting page (Ex: Exploits for the vulnerability fixed in MS06-04 used this kind of technique). So when developing your control, make sure it is capable of falling back to a secure state if it cannot positively identify its hosting environment. The SiteLock Template for ActiveX controls is secure against this threat.
-
_Templates
_It is common for applications to load HTML template files and fill in information from other sources before passing the resulting HTML on to MSHTML to render. For example, imagine a media previewer that extracts metadata from an MP3 file and plugs that metadata into a template that will then be displayed to the user via MSHTML. If your host implements a similar strategy, be aware of potential injection issues. Do not allow Script / HTML / ActiveX controls to be injected into your MSHTML host. Inspect your Gadget includes tips on how to mitigate this class of issue in your HTML templates. (Much of the guidance around Vista Sidebar Gadgets applies equally to templates.)
How can my MSHTML host regulate the security policy applied by IE Security zones?
By default, MSHTML regulates security policy based on the calculated zone of the page it is rendering. This is often an issue for MSHTML hosts because while the model may make sense for the Internet Explorer browser, it doesn’t necessarily map to the MSHTML host’s security model unless care is taken.
Imagine a news reader application that downloads HTML to the local hard drive and then navigates a MSHTML instance to this downloaded content. Data from the Internet is now likely to render within the Local Machine Zone. Within the Local Machine Zone, the content has access to unsafe functionality enabling the execution of arbitrary code. In the browser, this may have been mitigated by Local Machine Zone Lockdown, however this would not apply to the news reader by default unless it were to opt-in to the appropriate Feature Control Key (FCK). To ensure application compatibility, Local Machine Zone Lockdown is not enabled for all MSHTML hosts by default.
The example above demonstrates why it is very important to understand the security policy applied by Internet Explorer Zones when a page is rendered within your MSHTML hosting environment.
_Implementing a Security Manager
_The default Internet Explorer security policy very well may make sense for your MSHTML host. However, if it does not, be sure to implement a security manager. The browser policy that may be enforced using a security manager is a superset of what is available in the advanced zone options in Internet Explorer:
For example, a security manager can allow your host to disable all script yet only allow one specific ActiveX control to run. The policy flags that can be controlled from a security manager are called URL Actions and are defined in urlmon.h. Be aware that even if your security manager blocks script and ActiveX by default, there are likely other URL Actions to consider disabling. For example, your host may disable frames and active content, but without also disabling URLACTION_HTML_META_REFRESH it will still be possible for HTML to trigger automatic navigation.
Regardless of whether or not you implement a security manager, you may want to implement an Asynchronous Pluggable Protocol Handler (APP). It is possible for an APP to implement IInternetProtocolInfo and provide support for PARSE_SECURITY_URL and PARSE_SECURITY_DOMAIN in order to control the zone into which URLs are placed.
When implementing an APP for your Trident host, avoid registering it globally on the system if at all possible. Instead, load it dynamically at runtime only for your process. Registering it globally adds unnecessary attack surface to Internet Explorer. See “About Pluggable Protocols” here.
- David Ross, MSRC Engineering
*Postings are provided “AS IS” with no warranties, and confers no rights.*