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:
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.*