IEInternals

A look at Internet Explorer from the inside out. @EricLaw left Microsoft in 2012, but was named an IE MVP in '13 & an IE userAgent (http://useragents.ie) in '14

Understanding Enhanced Protected Mode

Understanding Enhanced Protected Mode

  • Comments 52

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.

enableepm

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: http://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.

Loopback-blocked

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.

image

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 http://127.0.0.1/, 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 http://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 http://192.168.1.1 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:

EPMOnFails

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 http://router to 192.168.1.1) 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:

EPMOff

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:

MarkPublic

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

LinkSysIsPub

…and thus AppContainers are freely able to contact the 192.168.1.1 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 192.168.1.1.

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:

MarkPrivate

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

LinksysPriv

 

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

Cookie Pushing

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:

BingBar

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.

-Eric

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

  • Q: If I use the notification bar to exempt a site from Enhanced Protected Mode, how can I later clear that exemption?

    A: Use the Delete Browser History item and check the "History" checkbox.

  • I cannot upload images from my F/G/H drives of my hard disk (E being the CD ROM drive) using IE10. Ex: Facebook. I can do the same without any problem using Chrome.I am not a tech guy, but I can see that something is wrong somewhere with IE10.I have tried everything including resetting IE10 but this problem persists.

    EricLaw: Are you seeing this problem in Metro-style IE, or Desktop IE? What exactly happens? What is the simplest site this occurs on? Do you have this problem using the first upload box at http://www.debugtheweb.com/sandbox/FileForm.asp? 

  • @Eric.

    1. Simplest site: Facebook.

    2. On my own website.

    On both I am able to access all partitions and images from Google Chrome.

    On Desktop as well as Metro.

    It says "This Briefcase cannot be opened because the disk in inaccessible. Verify that the disk is accessible."

    The same briefcase from the same location works fine on Chrome.

    The same brief case when copied-pasted on to Desktop works fine on IE10.

    Yes. I have the same problem in the fileform you have given as well.

    Thanks.

  • @Eric.

    I solved it.

    For some reason, IE10 was NOT reading from files saved in 'Briefcases' (which I had moved from my previous laptop which ran on W7HP).

    I deleted all Briefcases and made them into 'normal' folders. And I can now access and upload.

    Thanks guys.

  • Hello, How to find whether the add-on is running in EPM? For an ordinary PM there is IEIsProtectedModeProcess, but I cannot find anything like that for EPM.

    EricLaw: Great question. As far as I know, there's no public API that permits detecting that you're running in EPM, although it's probably possible to use one of the AppContainer APIs or Windows Security Token APIs to detect this case.

  • Another question, see the codes below, isExited == True immediately after browserProcess.Start(), after checking process in Task Manager, the 32bit IE seems still run. I am not sure why the 32Bit IE process exited. Could you give me help on this answer ? Thank you so much. Running on OS: 64bit Win2012

    Process browserProcess = new Process();
    browserProcess.StartInfo.FileName = @"C:\Program Files (x86)\Internet Explorer\iexplore.exe";
    browserProcess.Start();
    bool isExited = browserProcess.HasExited;

    EricLaw: If you launch the 32bit IExplore.exe directly, it immediately launches a 64bit frame process and then shuts the 32bit instance of itself down. That 64bit frame process may itself then launch a 32bit content process, but that content process has no relationship to the original 32bit instance that kicked off the 64bit frame process.

  • Hi Eric,

    I am trying to get a webpage to connect to a websocket server running on the local machine (for test purposes only at this stage). The server isn't hosted by IIS, it's a dedicated .NET app listening on a non-standard (for HTTP) port. The javascript constructor for the websocket is of the form New WebSocket("ws://machinename:8090"). This works great in desktop IE10 but fails miserably when the page is loaded into IE10 Metro. I tried making the machinename a trusted site, but it didn't help. Is the problem going to be down to IE10's zoning of the URI resulting in the websocket call being firewalled?

    Thanks.

    EricLaw: Yes, that is likely it. See http://blogs.msdn.com/b/fiddler/archive/2011/12/10/fiddler-windows-8-apps-enable-loopback-network-isolation-exemption.aspx for my utility to workaround that limitation. (If you want to go the Trusted route, the key is that the Trusted site needs to be the page's host not the target websocket host.

  • Brilliant! The trusted route is all I need at this stage. As you say, the key is to trust the page host rather than the websocket host. Everything works now, so thank you very much Eric.

  • Hi can any one tell me  Switch Between 32-bit and 64-bit Internet Explorer 10 in Windows 7  is also possible like windows 8 or not ?? i.e in order to enable 64bit Content Processes for the Desktop we will enable "Enhanced Protect Mode" in IE10 windows 8. . is it the same case in Windows 7 ??

    EricLaw: In IE10 on Windows7, the "Enhanced Protect Mode" checkbox controls only whether IE runs in 64bit. In IE9, 64bit IE is a separate program in the Start Menu.

  • We blocked the x64 IE9 with AppLocker (Program Files path). Users should run only x86 version of IE. But with IE10: blocking the x64 path with prevents startup of x86 IE! How to handle this?

    EricLaw: That rule definitely shouldn't be used with IE10, as IE10 requires processes of both bitnesses for its normal function. You can use Zones to control what bitness processes are used for sites.

  • On Win7-64 with IE10 I want to enable EPM and use 64-bit browser processes for everything, EXCEPT for a few sites that require a 32-bit IE for a 32-bit-only add-on.  With IE9 I could create a shortcut to ProgFilesX86\IE\iexplore.exe with a URL to get a 32-bit browser instance.  But with IE10 and EPM, that shortcut now produces a 64-bit browser process so the 32-bit add-on fails.

    How can I leave EPM enabled by default for 99% of browsing and create a shortcut or link to launch a 32-bit browser instance or somehow tag a site to use a 32-bit browser instance?

    Thx.

  • This part seems especially important for those enterprise customers that have transparent proxy server through which outbound traffic flows:

    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.

    I'm seeing authentication requests fail when the site is running in an AppContainer tab. If I add the site to IE Trusted Sites zone, the site runs at Medium level, and the transparent authentication works.  It seems that AppContainer is preventing the passing of network credentials to the proxy server.  For corporate customers, what is the way around this?  Is it possible to enable the enterpriseAuthentication capability for IE10 when running in the AppContainer?  

  • Thilo, it looks like you will need to ensure that Enhanced Protected Mode is always OFF for the desktop version of IE10.  This will ensure that tabs run at 32-bit.  Tommcg1, if it's only a few sites, you can add them to IE Trusted Sites through Group Policy, and they will run at 32-bit, while all other sites continue to use EPM and run at 64-bit.  Adding to Trusted Sites will turn Protected Mode OFF, so be aware of that.  

  • Thilo, you can use Group Policy to disable Enhanced Protected Mode -- forgot to add that.  

  • Thanks, breca89, for the suggestion.  However, with EPM globally enabled and tagging the site "trusted" (medium security and protection disabled) still does not result in a 32-bit IE process running when navigate to that site.

    If launch IE on about:blank with EPM enabled, it is a 64-bit process. Just typing the address of the trusted site in address bar or choosing link from favorites does not result in a new 32-bit iexplore.exe process -- it just loads the site in the 64-bit content process that the browser window runs within.  

    And launching iexplore.exe from ProgFilesX86 still results in a 64-bit IE.

    With EPM enabled, a desktop URL shortcut to trusted site still results in 64-bit IE.

    Open link in new window still results in 64-bit IE.

    Even setting trusted sites to lowest security level still results in 64-bit IE.

    Still can't figure out how to get a 32-bit IE to load for only a specific site or link or shortcut while leaving EPM enabled globally.  

    This is Win7-64 IE10 with tabs disabled.

    Thx.

Page 2 of 4 (52 items) 1234
Leave a Comment
  • Please add 2 and 2 and type the answer here:
  • Post