Understanding the Protected Mode Elevation Dialog

Internet Explorer 7 introduced Protected Mode, a feature which helps ensure that the browser and its add-ons run with a minimal set of permissions. Code running inside the “Low Rights” process doesn’t have permission to write to your user-profile’s folders or registry keys, which helps to constrain the damage if a bad guy manages to find a vulnerability within the browser or its add-ons.

To help ensure compatibility, Protected Mode employs a system of virtualization to help ensure that code that runs within Protected Mode will continue to work even when its permissions are restricted.

In some cases, virtualization can lead to surprising outcomes, some of which Mark Russinovich describes in his blog post The Case of the Phantom Desktop Files. Beyond such surprises, some functions just cannot be virtualized effectively—for instance, if you want to offer a feature that sets the current user’s Desktop wallpaper, your code simply must write to their user-profile.

How does IE resolve the tradeoff between security and functionality? The answer is “by using brokers.” The idea is that Internet Explorer (and some add-ons like Flash and Java) will run a broker process with “Medium Rights” that can use the current user’s permissions to take actions that would otherwise be prohibited when rendering content inside the Protected Mode sandbox. A broker process must be carefully designed to accept untrusted input (since its caller could be malicious code trying to escape the sandbox), sanitizing data and confirming any security-sensitive actions with the user directly before making changes.

When an add-on running inside Protected Mode attempts to launch a broker process (or any other program), the ElevationPolicy registry key ({HKLM/HKCU}\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy) is checked to determine how the process should be launched. One of four policy values may be specified:

Policy Result
0 Protected mode prevents the process from launching.
1 Protected mode silently launches the broker as a low integrity process.
2 Protected Mode prompts the user for permission to launch the process. If permission is granted, the process is launched as a medium integrity process.
3 Protected Mode silently launches the broker as a medium integrity process.

The problem arises when a broker process fails to properly register an elevation policy. If no ElevationPolicy is specified, then the default policy is #2, and the user sees a prompt for permission to launch the process. In the case of a broker process, this can lead to a very confusing user-experience. For instance, if Flash’s Broker’s elevation policy is missing from the registry, any page that uses Flash will trigger the following prompt:

Protected Mode Elevation Prompt

Now, keeping in mind that average users (and most super users) don’t have any idea what a broker is or why they’re seeing this dialog, it’s understandable that they might click either “Allow” or “Don’t allow” just to get rid of it. However, the next time the add-on attempts to launch the broker process, the user will be presented with the same prompt.  As you might imagine, they will quickly get tired of this!

Users tired of banging the “Don’t allow” button (not really understanding what the broker is and why it exists) are likely to try checking the “Do not show me the warning for this program again” box before clicking the “Don’t allow” button.

Protected Mode Elevation Prompt with Don't Ask, Deny Always

Unfortunately, this exercise is doomed—the “Do not show” checkbox only takes effect when you push the “Allow” button—you cannot automatically deny access for a given process.

Why not? Because it would break things unexpectedly, and there would be no way for a normal person to figure out what went wrong and subsequently fix it. An add-on that tried to launch its broker would always fail, and might try repeatedly (hanging the browser). Worse still, there’s no way for the user to go back and change their mind—there was no reasonably affordable way to build a UI that would allow for such reversals after the HKCU ElevationPolicy registry key is updated.

Add-on developers should take care to ensure that the ElevationPolicy for their broker process is properly set at install time (and may wish to confirm that it’s set properly if the broker ever fails to launch due to an Access Denied error, and notify the user accordingly).

End-users encountering unexpected Protected Mode Elevation prompts should consider either reinstalling whatever add-on is triggering the prompt (it’s often obvious) or disabling any unrecognized or unwanted add-ons. Beyond reducing attack surface and prompts, disabling unwanted add-ons will often improve browser performance.


Comments (10)
  1. Piskvor says:

    Sorry, but I still don’t understand the rationale for "don’t show again only with allow". You wrote "Worse still, there’s no way for the user to go back and change their mind" – how is this situation different for "allow and don’t show again"? As you say, there’s no UI fo either case.

  2. @Piskvor: If you choose "Allow and don’t show again", then, in theory, the addon/broker will work properly, as if the installer had properly registered the ElevationPolicy.

    In contrast, if you choose "Don’t allow" and "Don’t show again", the installation is essentially corrupted, with no obvious means of repair.

    Hence, reversibility of the "Don’t allow" decision is more critical than reversibility of "Allow".

  3. Richard says:

    In that case, surely the dialog should have three buttons and no checkbox: "Allow this time", "Allow always" and "Don’t allow this time".

  4. EricLaw [MSFT] says:

    Yes, that would certainly be more clear.

  5. anon says:

    This dialog unfortunately is only presented if we click "Open" in the file download box instead of Save. It seems to have replaced the dialog for the "Confirm open after download" (BrowserFlags) setting in File Type options (pre-Vista). IE7 and above do not allow users to always save or always open like IE6/pre-Vista where we had access to this setting "Confirm open after download" in File Types (XP). IE users also can no longer configure "Browse in same window" for PDFs, DOCs.

    IE should have a way (configuration dialog) for users to set what file types should be opened by the browser or browser plugins that handle MIME types. File types is not the same as MIME types. MIME types is how (IE or IE plugin) users want to handle when open certain types directly from the browser and file types is when opening documents by double clicking from Windows Exlporer. A Firefox plugin for MIME types called MIMEEdit does this perfectly. Because of introduction of Protected Mode probably, these settings were taken away and "Protected Mode (Protected View)" now extended to Office 2010. We want to be able to:

    1.  Always save to the set download location (don’t ask for confirming save)

    2.  Always open inside the browser (with ActiveX plugin or natively)

    3.  Always open outside the browser (Show this above dialog)

    4.  Deny downloading/opening.

  6. @Anon: I’m not really sure what you’re getting at, but your response contains a number of inaccuracies.

    <<This dialog unfortunately is only presented if we click "Open" in the file download box>>

    That’s untrue. The dialog is presented any time the Protected Mode process needs to run an unelevated process for which an elevation policy isn’t registered. I hope the post was pretty clear on that.

    <<It seems to have replaced the dialog for the "Confirm open after download">>

    No. This dialog comes up *after* the [Open/Run]/Save/Cancel dialog.

    <<IE7 and above do not allow users to always save or always open>>

    There was never an "Always Save" option. Perhaps you’re confused and the server was using the META DownloadOptions to hide the Open/Run button? IE8 supports that and allows you to send DownloadOptions: NoOpen as a HTTP header as well.

    <<IE users also can no longer configure "Browse in same window">>

    Nothing really changed here. The Office team decided quite a while ago that they didn’t want their client (2003+, IIRC) opening inside IE as a DocHost.

    <<Because of introduction of Protected Mode probably, these settings were taken away >>


    <<"Protected Mode (Protected View)" now extended to Office 2010. >>

    Office 2010 introduced Protected View, yes, but that has very little to do with Protected Mode except that it is also built on a Low Integrity process.

    <<1.  Always save to the set download location (don’t ask for confirming save)>>

    That’s a security risk.

    <<4.  Deny downloading/opening.>>

    In what cases do you think that would be useful?

  7. anon says:

    What I meant was Vista/Windows 7 do not have the UI to configure "Confirm open after download (Reg EditFlags value) (Hex: 00 00 01 00)", "Always show/hide extension" (NeverShowExt) and "Browse in same window" (BrowserFlags value) options and I miss them. Since "Confirm open after download" and "Browse in same window" are IE-related, they should be reinstated in IE advanced options (They were user configurable in XP but users now need to tinker with the registry to set them for any file types they want). That would mean also putting a file types list for these options. Since the whole file types tab that contained these options was yanked and replaced with a dumbed down "Default Programs" that eliminated most of the functionality, these options are gone. The IE-related 2 above should be put into IE options.

    The dialog discussed in this post as I meant and you stated is presented when a Protected Mode process needs to run an unelevated process one of such scenarious is when we click "Open" in the file download box after download. By "replaced the dialog", I wondered if this elevation dialog had replaced the "Confirm open after download" dialog since the latter disappeared but the former appeared in Vista but now that’s clear to me.

    I hate losing features going forward. Please reinstate "Confirm open after download" and "Always open in same window" in IE9.

  8. anon says:

    Btw you see this is one of the reasons why users stick with IE6+XP if they are IE loyalists or Firefox on Vista/Windows 7. *They* want to choose whether to "Confirm open after download" or "Always open in same window". The registry is not an option.

  9. JerryMirro says:

    I have long argued for freedom

    of information in the Internet…

    but the copyright thing is complicated.

    I wish that it were designed a clever

    system of interaction holders and torrents.


  10. Philip Su says:

    Eric — thanks for this great post!  Helped me solve a problem with a feature I'm working on, where Deny'ing the Protected Mode dialog led to a hang in IE9 RC.  This article gets rid of that possibility altogether.  Very cool.

Comments are closed.

Skip to main content