Understanding Enhanced Protected Mode

Last week, Andy Zeigler announced the introduction of Enhanced Protected Mode (EPM) over on the IEBlog. In today’s post, I’d like to provide further technical details about EPM to help security researchers, IT professionals, enthusiasts, and developers better understand how this feature works and what impact it may have on scenarios they care about.

Internet Explorer’s Process Model and Bitness

For the past several releases, Internet Explorer has sported a multi-process architecture, where the “Frame” or “Manager” process runs at Medium Integrity and the “Tab” or “Content” processes run at either Low Integrity (Protected Mode) or Medium Integrity (for Zones where Protected Mode is disabled, like Intranet sites). All HTML content and ActiveX controls run in the Content Process. Even toolbars, which visually appear as if they’re in the Manager Process, really run down in a Content Process.

For IE10, we’ve changed IE such that Manager Processes always run as 64bit processes when running on a 64bit processor running a 64bit version of Windows. This improves security among other things. We do not expect that this change will meaningfully impact compatibility, because the Manager Process is designed not to run 3rd party content, and thus there’s little opportunity for anyone to take a dependency upon the Frame Process’ bitness. In support of this change, the various registry points that point to Internet Explorer have been updated to point to C:\Program Files\Internet Explorer\iexplore.exe. If you manually invoke C:\Program Files (x86) \Internet Explorer\iexplore.exe, that 32bit process will simply launch the 64bit version of iexplore.exe (with the appropriate command line parameters) before exiting.

For the Content Processes, the story is a little more complicated. In the Metro-style experience of Internet Explorer, all Content Processes will run at 64bit (on Win64), which means that they benefit from the improved security provided in 64bit. The compatibility impact is minimal because Metro-style IE does not load any browser add-ons (Toolbars, BHOs, and non-browser-platform COM objects like MIME Handlers, URLMon Protocol Handlers, MIME Filters, ActiveX controls, etc). Back in IE9, running in 64bit mode meant that JavaScript was not JIT-compiled, but for IE10, the JIT compiler was enhanced to work for both 32bit and 64bit tabs, providing great performance in both. Additionally, many major browser add-ons like Flash, Silverlight, and Java are now available in 64bit versions.

In Internet Explorer on the Desktop, by default, Content Processes remain at 32bit by default for compatibility with 32bit ActiveX controls, Toolbars, BHOs, etc. Even when you directly launch the 64bit iexplore.exe executable, you will still have a 64bit Manager Process that hosts only 32bit Content Processes. If you want to enable 64bit Content Processes for the Desktop, you must tick the Enable Enhanced Protected Mode option in the Security section of Internet Explorer’s Tools > Internet Options > Advanced tab. When this option is enabled, all Content Processes that are running in Protected Mode (e.g. Internet Zone and Restricted Zone, by default) will begin to use 64bit Content Processes.

Note: In the Windows 8 Release Preview, if you enable Protected Mode for the Local Intranet and Trusted Zones, even if you enable EPM, the Intranet and Trusted Zones will run in 32bit LowIL rather than a 64bit AppContainer.


In the upcoming Internet Explorer 10 on Windows 7 and Windows Server 2008R2, the only thing that enabling Enhanced Protected Mode does is turn on 64bit Content Processes. But, when running on Windows 8, the EPM option provides even more security by also causing the sandboxed Content Process to run in a new process isolation feature called “AppContainer.”

Intro to AppContainer

Windows Vista introduced the concept of Integrity Levels. The default integrity levels used by applications (Low / Medium / High) constrained what parts of the system could be written (e.g. registry keys, files, etc) and how applications could communicate or share data. Notably, in most circumstances, Integrity Levels were “Allow Read-Up; Block Write-Up” meaning that even a Low Integrity process like an IE tab would have full read-access to the rest of the disk and registry even those locations which were marked as Medium or High integrity.

Windows 8 introduces a new process isolation mechanism, called AppContainer, that offers more fine-grained security permissions and which blocks Write and Read Access to most of the system. There’s not a lot of documentation specifically about AppContainer because all Metro-style applications run in AppContainers, so most of the documentation is written from that point of view. For instance, here’s a page that describes the capabilities that a Metro-style application can declare that it needs: https://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx. Under the covers, it’s the AppContainer that helps ensure that an App does not have access to capabilities that it hasn’t declared and been granted by the user.

IE Tabs and AppContainer

Tabs running in Enhanced Protected Mode on Windows 8 run inside an AppContainer. On Windows 7 and Windows Server 2008 R2, AppContainer does not exist, so EPM only enables 64bit tabs on a 64bit OS. (That also means that enabling EPM on a 32bit Windows 7 system doesn’t do anything, because a 32bit Windows 7 system supports neither 64bit nor AppContainer).

On Windows 8, Metro-style IE’s tabs in the Internet and Restricted Zone run in Enhanced Protected mode, while tabs in other zones run in 64bit only. You cannot disable EPM for Metro-style IE except by turning off Protected Mode entirely.

By default, Desktop IE’s tabs run in the Low Integrity Protected Mode at 32bit. Only if you enable Enhanced Protected Mode using the Internet Options control panel will Desktop IE’s tabs run in AppContainer (and 64bit, if available).

IE’s AppContainer

Internet Explorer’s EPM-mode tabs run in an AppContainer named windows_ie_ac_001. In the Windows 8 Consumer Preview release, this container declares the capabilities internetClient, location, and sharedUserCertificates.

Notably, the container does not specify internetClientServer, privateNetworkClientServer, enterpriseAuthentication, or any of the *Library capabilities, which means that Internet content runs in a tightly-limited process.

AppContainer - Network Restrictions

AppContainer introduces three key restrictions related to Network Connectivity that impact EPM. I’ll describe each.

Acting as a Network Server is Blocked

Because EPM’s AppContainer does not have the internetClientServer capability, there’s no way for an EPM process to accept inbound connection attempts from the network. Typically, such connections weren’t possible in the Web Platform anyway (e.g. there's no JavaScript method to listen() on a new TCP/IP socket), but some browser add-ons had the capability of allowing inbound connections (even though this became pretty uncommon with the broadscale deployment of firewalls). When EPM is enabled, such add-ons will not be able to accept remote connections.


Apps running in AppContainer are not allowed to make connections to locally-running processes outside of their own package. This means, for instance, if you run a local developer instance of Apache or IIS on your own computer, you will find that Metro-style applications are unable to connect to that server. This also means that by-default, you cannot use Fiddler to debug Metro-style applications, because Fiddler acts as a proxy server on your local computer. To unblock Fiddler users, I’ve published a simple utility that allows users to remove the Loopback Restriction on the AppContainers of their choice; you can also use this utility to allow your App or MetroIE to contact a locally-running web server for development purposes.


Please note that Windows Store-delivered applications will not be permitted to set a loopback exemption for themselves, so this is only useful for test/development purposes.

Now, one key thing to understand about Loopback connections in Metro-style Internet Explorer is that the Hostname you use in your URL matters a lot! If you try to navigate to, your page will be treated as an Internet Zone and thus will run in an EPM tab, and the loading of the page will be blocked by the AppContainer’s Loopback-block-- you’ll see a Page Could Not Be Displayed error page.

However, if you instead try the URL https://localhost/ (assuming your Intranet Zone is enabled), you will find that Internet Explorer considers your content to be Local Intranet Zone, and thus it is loaded in a Medium Integrity (non-Protected Mode) tab. The page will successfully load since it is not running in EPM, and thus isn't blocked by the network restrictions provided by AppContainer.

Private Network resources

Because EPM does not declare the privateNetworkClientServer capability, your Intranet resources are protected from many types of cross-zone attacks (usually called “Cross-Site-Request-Forgery (CSRF)” and “Intranet Port Scanning.”) Internet pages are not able to frame Intranet pages, load images or resources from them, send them CORS XHR requests, etc.

However, it’s important to understand how this restriction functions, because it can have some very surprising outcomes depending on how your Internet Explorer Security Zones are configured.

For instance, many of us have a home router with a configuration UI accessible at or a similar address that is not globally-routable. On one hand, it’s desirable to prevent Internet content from sending requests to such addresses to help block CSRF-attacks that might maliciously reconfigure poorly-secured routers. However, for historical and other reasons, Security Zones consider this dotted hostname to be an Internet-Zone address by default, which means that if you attempt to navigate to the Router configuration page in Metro-style IE, you may encounter a Page Cannot Be Displayed error page. If you enable EPM in the Desktop mode of the browser, you can use the F12 Developer tools to see why the request was blocked:


Note: The next update to IE10 will use a more specific error message here; this string was designed for developers of Metro-style applications, not for folks debugging in EPM in IE.

To resolve this issue, you can either use a non-dotted hostname for your router (e.g. my DNS points https://router to or you can manually add the router’s address to your Trusted Sites zone using the Tools > Internet Options > Security | Trusted | Sites... list. When navigating to Trusted Sites, the navigation occurs outside of Protected Mode, so AppContainer restrictions are not a problem.

There’s a non-obvious subtlety here which bears mentioning. When I personally tried to reproduce this restriction at home, I had no problem in navigating straight to the router’s IP Address in both Metro and Desktop IE with EPM enabled:


What’s up with that?

The explanation is that the AppContainer network restrictions are sensitive to your network configuration. When I had originally connected to my router, I had selected the following configuration:


As a result, the Windows Firewall considered my router part of a public network:


…and thus AppContainers are freely able to contact the address as I had indicated that I was on a “Public Network” and thus the privateNetworkClientServer capability is not required to contact local / non-routable addresses like

I can enable the network restriction by reconfiguring my network settings. First, I use the sidebar's context menu to tell Windows to “forget” my Linksys connection. Then, I re-established it as a “home” network:


This causes the Windows Firewall consider this a “Private network”:



...and subsequently block connections to "local" addresses from AppContainers that lack the privateNetworkClientServer capability.

AppContainer – Isolation of Cookies and Cache

AppContainers do not have read or write access to files outside of their container, which means that the cache, cookies, and other web-platform state information is not shared between different AppContainers and the rest of the system. This means, for instance, that if you have a Windows Web App (a Metro-style app written in HTML+JavaScript), that application will not share cookies or cache files with Internet Explorer. Similarly, Metro-style apps will not share cookies and cache with one another.

This “partitioning” can be great for security and privacy, because it means that your use of one application isn’t visible to another. For instance, if you log into your Banking App, the banking app’s cache, cookies, and credentials aren’t available to be stolen from pages you browse in Metro-style Internet Explorer, even if a vulnerability was discovered that allowed an attacker to run arbitrary native code in the AppContainer.

However, partitioning can lead to unexpected behaviors. I describe some of these in a previous post called Beware Cookie Sharing in Cross-Zone Scenarios. In that post, I observed that even in IE7 to IE9, there exists a partition between sites that run in Medium Integrity vs. those that run in Protected Mode, such that cookies are not shared between those modes. That can lead to problems when a site in one zone frames another, since the sandbox in which all frames in a page run is determined by the top-level page’s Zone.

In Windows 8, the existing Medium IL / Low IL partition remains, and a new EPM AppContainer partition is added as well. It’s now possible for a user to have three independent copies of a cookie for a single site in IE (not even counting other non-IE Metro Apps). For instance, if www.example.com tries to set a cookie when it’s the subframe of an Intranet top-level page, that cookie will go in the MediumIL cookie jar. If the user then visits www.example.com in Metro-style IE, the cookie will be set in the EPM’s AppContainer cookie jar. Then, if the user visits www.example.com in Desktop IE, the cookie will be set in the LowIL cookie jar. These three cookies are independent, and changes or deletions of the cookie in one partition will not be seen in the other partitions. If the user "logs out" in one mode of the browser (which deletes the cookie) the other modes of the browser will remain "logged in" (since their cookies are isolated). Sites that need to securely log a user out across all browser modes should continue to expire the session on the server, rather than only relying on the client to stop sending a given cookie.

To be explicit, the following data stores are partitioned between Internet Zone content running in Metro-style IE (in EPM) and Desktop IE (in LowIL):

In contrast, Local Intranet Zone and Trusted Zone pages run in Medium IL in both Metro-style IE and Desktop IE, and thus these Zones' data stores are shared between both browser modes.

One exception exists to the partitioning behavior described above. When you use the View on the Desktop command in Metro-style IE, it will "push" the current tab’s session cookies into the new Desktop IE instance that opens. However, this only applies to session cookies and not persistent cookies.

You can see how this works by following these steps:

  1. Clear all cookies using Delete Browser History
  2. Visit www.facebook.com in Metro-style IE
  3. Log in with the Keep me logged in box unchecked on the Facebook site
  4. Facebook will send you a session cookie containing your credentials.
  5. Invoke the View on the Desktop command

At this point, you should find that Desktop IE shows your default post-logon Facebook page (e.g. your Wall)-- you're still logged in.

Now close your browsers and repeat these steps, except at step #3, check the Keep me logged in option. At Step #4, Facebook will send you a persistent cookie with your credentials. When you switch to Desktop IE at step #5, you will find that you are not logged in to Facebook, because the persistent cookie set by Facebook isn’t pushed to Desktop IE.

You will further notice that if you enable Enhanced Protected Mode for Desktop IE, when switching from Metro IE to Desktop IE you will remain logged into Facebook in Desktop, because MetroIE in EPM shares cookies with DesktopIE in EPM since they are both running in the same AppContainer.

Add-ons in Enhanced Protected Mode

Metro-style Internet Explorer does not load add-ons, so there are no AppContainer considerations to worry about in MetroIE.

In contrast, most users expect add-ons to work in Desktop IE, but very few add-ons are AppContainer-compatible today. If you enable EPM in the desktop and have a BHO or Toolbar that isn’t EPM compatible, the add-on will be disabled:


If you visit a page that requires an ActiveX control which is not EPM-compatible, you’ll be provided the opportunity to load the page in a special “Low IL Compat” tab that runs the page at 32bits in LowIL instead of in an 64-bit AppContainer:

Notification message which reads “This webpage wants to run 'Adobe Flash Player 10.3 d162'. If you trust this site, you can disable Enhanced Protected Mode for this site to run the control.” The notication bar contains one button labeled “Disable”.

In order to be EPM-compatible, Toolbars and BHOs must be available in 32bit and 64bit flavors, to avoid toolbars or other UI appearing and disappearing as you navigate between zones that run at different bitnesses. To load in EPM on Windows 8, the add-on must also indicate that it is compatible with the AppContainer isolation feature by registering with a COM Component Category that indicates that the component was designed and tested to ensure it runs correctly in the no-read-up process.

The category is named CATID_AppContainerCompatible and its GUID is {59fb2056-d625-48d0-a944-1a85b5ab2640}. C++ programmers may use:

  DEFINE_GUID(CATID_AppContainerCompatible, 0x59fb2056,0xd625,0x48d0,0xa9,0x44,0x1a,0x85,0xb5,0xab,0x26,0x40);

Any non-trivial add-on is likely to find that it needs access to resources that are not available from within an AppContainer. The way to security provide such access is to build a broker object that runs at Medium IL. In Vista and later, brokers were needed to write protected resources, and in EPM, they are required to read protected resources.  The general pattern is:

  1. Untrusted code (the add-on running in the Protected Mode tab) calls a method in the broker, passing zero or more arguments.
  2. The broker evaluates the request's arguments and its own security policy.
  3. The broker confirms with the user that the requested operation is acceptable (e.g. by showing a Save prompt or whatever).
  4. The broker undertakes the operation if allowed, or blocks it if denied.

Writing a broker is a significant undertaking, and requires a thorough security audit to ensure that the broker doesn’t allow malicious code to escape from the tab running in Protected Mode.

12/20/2013 UPDATE: The IE team has published documentation on writing EPM-Compatible extensions on MSDN.


PS: Please see this post for discussion of the impact of EPM on loading of local files that contain a Mark-of-the-Web.