Bolstering Protected Mode

  • Article

Internet Explorer 7 introduced Protected Mode, a defense-in-depth security feature which relied upon the Windows Vista Integrity Levels (IL) system to mitigate drive-by attacks against the browser. Internet Explorer 10 introduced a stronger version of that feature, called Enhanced Protected Mode (EPM), which goes beyond the legacy IL system and provides isolation using the Windows 8+ AppContainers feature.

Both of these features are useful in mitigating a class of exploits, but due to compatibility concerns, neither is configured as securely as possible.

Recently, there’s been some excitement over the rediscovery of a simple escape of Protected Mode, first documented back in 2010. This escape is beautiful in its simplicity-- the attacker merely:

  1. Leverages some vulnerability to get remote code execution (RCE) within the LowIL process
  2. Uses the RCE to run a simple webserver inside IE
  3. Navigates a new IE tab to the URL of that simple server at https://localhost/
  4. Serves a web page that exploits that vulnerability again

Because the exploit code is re-served from https://localhost/, it may run with Intranet Zone permissions outside of Protected Mode, since “localhost” is a dotless hostname that is typically mapped to the Intranet zone.

Now, there are some caveats that limit the availability of this escape.

IE7 and later disable the Intranet Zone by default for users who are not domain-joined or on “managed” networks. If the Intranet Zone is disabled, https://localhost/ will load in the Internet Zone, in Protected Mode, and the escape attempt is foiled:

If IE10+’s Enhanced Protected Mode feature is enabled, the escape is blocked because EPM processes are unable to listen or connect to loopback addresses, lacking the internetClientServer and privateNetworkClientServer permissions. EPM is enabled in the Windows 8+ “Metro” / “Immersive Browser” by default, and can be manually enabled for Desktop IE.

To help ensure that you are not vulnerable to escapes of Protected Mode, you can undertake one or more of the following:

  1. Enable Protected Mode for the Intranet Zone -- Click Tools > Internet Options > Security > Local Intranet. Tick the “Enable Protected Mode” box.
  2. Explicitly disable the Intranet Zone – Click Tools > Internet Options > Security > Local Intranet > Sites. Untick all of the boxes.
  3. Enable Enhanced Protected Mode – Click Tools > Internet Options > Advanced > Enable Enhanced Protected Mode.

* As another defense-in-depth, you might consider enabling the Zone Elevation warning, such that most attempts to navigate from the Internet Zone to the more-trusted Intranet Zone show a warning. Click Tools > Internet Options > Security > Local Intranet > Custom Level. Set “Websites in less privileged web content zone can navigate into this Zone” to Prompt. This will result in the following prompt when such a navigation occurs via typical means:

Elevate

Unfortunately, this mitigation isn’t useful against the sandbox escape because an attacker who has achieved full RCE inside the Protected Mode process can simply call the IELaunchURL API; that API is not protected with this prompt.

While bolstering EPM/PM is great for defense-in-depth, the best way to remain secure is to ensure that the bad guys cannot exploit a vulnerability that allows remote code execution to start with. To that end, you should:

  1. Upgrade to the latest Internet Explorer version
  2. Ensure that it’s kept up-to-date via WindowsUpdate
  3. Consider installing Enhanced Mitigation Experience Toolkit (EMET)

EMET includes cutting-edge defenses against 0-day attacks; once proven in the prototyping stage, these defenses are often then built-in to the next versions of Internet Explorer and Windows.

-Eric Lawrence