Condividi tramite


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.

-Eric

Comments

  • Anonymous
    November 30, 2009
    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.

  • Anonymous
    November 30, 2009
    @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".

  • Anonymous
    December 01, 2009
    In that case, surely the dialog should have three buttons and no checkbox: "Allow this time", "Allow always" and "Don't allow this time".

  • Anonymous
    December 01, 2009
    Yes, that would certainly be more clear.

  • Anonymous
    December 02, 2009
    The comment has been removed

  • Anonymous
    December 02, 2009
    The comment has been removed

  • Anonymous
    December 05, 2009
    The comment has been removed

  • Anonymous
    December 05, 2009
    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.

  • Anonymous
    May 12, 2010
    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. http://welcome-re.ru/

  • Anonymous
    February 24, 2011
    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.