Skip to main content
MSRC

The MSHTML Host Security FAQ: Part II of II

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.

How do I make my MSHTML host opt-in to advanced IE security mitigations?

Internet Explorer 6 SP2 introduced the Feature Control Key (FCK) mechanism enabling advanced browser features to be enabled or disabled on a per-process basis. Some of the features regulated by FCKs are security related, directly or indirectly. Features may be opt-in or opt-out, so your MSHTML hosting process may or may not get them “for free” depending on the settings for individual features. Most FCKs automatically apply to IEXPLORE.EXE and EXPLORER.EXE even if the FCK is not present in the registry.

Here are opt-in FCKs that you should consider based on their documented functionality:

Similarly, consider implementing this opt-out FCK:

Opt-in to FEATURE_PROTOCOL_LOCKDOWN (Network Protocol Lockdown) only if your host has a special need for this feature. Network Protocol Lockdown enables hosts to support per-protocol zone policy. It is not enabled in Internet Explorer by default.

While it is possible to set FCKs programmatically via CoInternetSetFeatureEnabled, this is not currently supported on some FCKs such as FEATURE_LOCALMACHINE_LOCKDOWN. The registry mechanism for setting FCKs on a per-process basis is preferred.

What else to I need to worry about in order to securely host MSHTML?

Trust decisions / spoofing
If your host displays arbitrary content from the Internet then it is important to allow the user to make valid trust decisions about that content. In Internet Explorer, this is accomplished by enforcing the display of address bar and lock icon UI (aka IE7 Address Bar Protection).

New windows
Content running within your MSHTML host can enable new browser windows to be opened. This may be facilitated via links, META REFRESH operations, script, etc. Usually it is not possible to use named window navigation to target a frame within a given MSHTML host, however if your MSHTML enables new browser windows to open, another browser process on the desktop can navigate those windows elsewhere. (Named window navigation can be achieved using the second parameter of window.open, the TARGET attribute on an anchor, etc.) Additionally, if malicious script is running in a window, that script may be able to reach back through window.opener and navigate or inject script into your hosting environment. If you are hosting MSHTML via SHDOCVW you can handle WebBrowser control events to regulate the creation of new windows.

Protected Mode IE
Protected Mode IE was made available on Windows Vista and enables the Internet Explorer process to run with restricted privileges. Independent hosting of MSHTML in Protected Mode is not currently supported. By default, your MSHTML instance will be running at the same integrity level as the hosting application (typically Medium integrity). It is important to avoid enabling scenarios where your MSHTML instance would effectively provide a path to elevate out of Protected Mode IE. Read Understanding and Working in Protected Mode Internet Explorer for more guidance in this area.

General Hosting Considerations
Consult Reusing MSHTML, Reusing the WebBrowser Control, WebBrowser Customization (Part 1), and WebBrowser Customization (Part 2).

In your implementation of IDocHostUIHandler::GetHostInfo, be aware of specific DOCHOSTUIFLAG values you should consider opting-in to for security:

  • DOCHOSTUIFLAG_DISABLE_SCRIPT_INACTIVE
  • DOCHOSTUIFLAG_OVERRIDEBEHAVIORFACTORY
  • DOCHOSTUIFLAG_LOCAL_MACHINE_ACCESS_CHECK
  • DOCHOSTUIFLAG_DISABLE_UNTRUSTEDPROTOCOL

Also be aware that opting-in to some DOCHOSTUIFLAG values such as DOCHOSTUIFLAG_OPENNEWWIN or DOCHOSTUIFLAG_ENABLE_INPLACE_NAVIGATION could potentially enable interesting attack scenarios depending on the overall functionality of the host.

Avoid situations where your WebBrowser Control host does something explicitly unsafe given the untrusted nature of the web content it is operating on. For example, imagine a DWebBrowserEvents2::BeforeNavigate2 event handler that in some situations calls ShellExecute on the navigation target URL. Since the web content in the host may not be trusted, this essentially would allow malicious HTML to execute code.

Reference the “Controlling Download and Execution” section of WebBrowser Customization (Part 1) . Specifically, consider opting-in to these flags for security:

  • DLCTL_NO_SCRIPTS
  • DLCTL_NO_JAVA
  • DLCTL_NO_FRAMEDOWNLOAD
  • DLCTL_NOFRAMES
  • DLCTL_NO_DLACTIVEXCTLS
  • DLCTL_NO_RUNACTIVEXCTLS
  • DLCTL_NO_BEHAVIORS

The following flags may be useful if you are attempting to block external content references (for example, in an e-mail client):

  • DLCTL_PRAGMA_NO_CACHE
  • DLCTL_FORCEOFFLINE
  • DLCTL_NO_CLIENTPULL

If you are using MSHTML as an HTML previewer, you may want to set DLCTL_SILENT to block dialog boxes.

A special note on “Elevated Sandbox” hosting scenarios

The term “elevated” here does not refer to its specific technical meaning in the context of UAC / Protected Mode IE.

Often we see scenarios where script running within MSHTML is empowered with special abilities. In the case of HTML Help content, it was useful for the HTML Help environment to be able to run system commands, open control panel applets, etc. In cases such as these, barriers are constructed to prevent invasion by arbitrary HTML / script.

This situation creates an incentive for attackers to “break in” to the MSHTML hosting environment in order to execute arbitrary code or otherwise abuse the special permissions granted to MSHTML. Attacks may attempt to use obscure techniques to navigate the MSHTML host, or inject script via other means.

This same problem has manifested many times, often resulting in Critical severity patch class vulnerabilities.

The situation can be especially problematic when the MSHTML host ends up as a development platform in and of itself. Developers may follow the “normal” paradigms for building web sites, and in doing so end up stepping on a variety of landmines:

  • Use of innerHTML to write untrusted input to the DOM
  • Use of document.write to write untrusted input to the DOM
  • Use of Javascript eval on untrusted input
  • Referencing URLs provided as input without validating their protocol scheme
  • Referencing external resources in SCRIPT elements
  • Referencing remote CSS stylesheets
  • …and more. See Inspect your Gadget.

All of the practices listed above can result in injection issues that would compromise the security of the MSHTML host.

The HTML development model has evolved in such a way so as to make securing these types of scenarios difficult. As an alternative to hosting MSHTML, consider using a presentation system such as Silverlight or Windows Presentation Foundation (WPF) that provides better separation between markup and code. Otherwise, developers must exercise a greater level of caution when building content for your platform.

- David Ross, MSRC Engineering

*Postings are provided “AS IS” with no warranties, and confers no rights.*


Related Posts

How satisfied are you with the MSRC Blog?

Rating

Feedback * (required)

Your detailed feedback helps us improve your experience. Please enter between 10 and 2,000 characters.

Thank you for your feedback!

We'll review your input and work on improving the site.