The Web Browser is the most security-critical application on most users’ systems– it accepts untrusted input from servers anywhere in the world, parses that input using dozens to hundreds of parsers, and renders the result locally as fast as it can. For performance reasons, almost all code in almost all browsers is written in memory-unsafe languages.

To mitigate this insanity, web browsers perform this chainsaw juggling act inside nested layers of sandboxing. When an attacker inevitably manages to find an exploit, the resulting damage might be contained by the sandbox. Chromium calls this “The Rule of 2”:

As a consequence, most real-world browser attacks now must include exploits for two vulnerabilities: the original RCE, and a Sandbox Escape.

A web browser uses multiple mechanisms for sandboxing, from “Design sandboxing” (Same-Origin-Policy, limited JavaScript capabilities) to Process Sandboxing (AppContainers, UAC Integrity Levels, Restricted Tokens, etc).

Process sandboxing arose in the mid-200Xs as a defense-in-depth against Design Sandboxing mistakes – any error in implementation meant that an attacker could achieve arbitrary code execution (RCE) and take over the victim user’s computer.

Windows Vista introduced the notion of UAC Integrity Levels, whereby each system object (including processes) had an integrity level that limited the other objects it could read and write. Internet Explorer 7 built atop the UAC Integrity Levels system and introduced the notion of “Protected Mode” whereby Internet Zone content ran inside a tighter sandbox with decreased write-access to the system. Google Chrome and later versions of IE went much further, with AppContainers and broader process restrictions to make exploitation more challenging and reduce its impact.

Tools like SysInternals’ Process Explorer allow inspecting some of the sandboxing limitations applied to browsers’ processes. For instance, you can see the Windows Job restrictions applied to this Edge Renderer Process:

You’ll note that browsers typically use multiple processes with different sandboxing restrictions attached to each. For instance, in a default launch of Chrome, you’ll see that the main browser process launches at the default (“Medium”) Integrity Level, while the GPU process runs at Low Integrity, and the Renderer processes run at Untrusted Integrity (the lowest):

Looking at Internet Explorer, you can see that its main process runs at Medium, an Intranet Zone tab process runs at Medium, and an Internet Zone tab process runs at Low:

If you enable Enhanced Protected Mode, that Internet Zone tab process is further restricted to run in an AppContainer:

Run As Administrator

One interesting difference between Legacy IE and Microsoft Edge/Chrome is the behavior when you “Run As Administrator”: In the old IE, this resulted in the tab processes running unsandboxed at High IL:

For reasons that are hopefully obvious, running web content outside of a sandbox at High IL is an extremely dangerous configuration.

In contrast to IE behavior, in Edge/Chrome, the browser process, crash handler, and some utility processes run at High IL, but the sandboxed Renderers stay in Untrusted IL processes.

While this is clearly a safer configuration that what Internet Explorer had, the transitive nature of UAC Elevation means that many executables launched by this browser are launched at High Integrity, including Native Messaging Hosts, AppProtocol Handlers, downloaded executables, etc.

Functional Bugs

Beyond the increased security attack surface, there are some functional problems with running a Chromium-based browser at High IL. For instance, if you have AppLocker enabled, you may find that all of your sandboxed renderer processes crash (crbug.com/740132), or that link launches from non-admin processes are ignored (crbug.com/801539#c9). 

As a result of problems like these, Microsoft Edge will attempt to silently deelevate and relaunch itself when launched as an Administrator, running at Medium IL instead of High. If this feature is disabled (--do-not-de-elevate), Edge will show a warning to help users recognize the unexpected situation:

Generally speaking, there’s no legitimate reason to run your browser at High IL, and you shouldn’t ever do it.

But…

Impact on Windows Integrated Authentication

Recently, I was disappointed to learn that there are some scenarios where running at HighIL is still necessary. These scenarios are based on Windows Integrated Authentication, whereby the web server uses passthrough authentication to pass the user’s Elevated Authentication Token through to some backend service that requires membership in the Administrators group. If the web server receives and passes along the admin user’s non-elevated token (because the browser was run at Medium), the backend services will refuse to undertake the privileged operation.

The fact that such an application architecture ever worked is interesting but a bit bananas.

I’d be much happier with a design whereby this Elevated token passing scenario didn’t have to happen in the browser— either configuration should happen in some non-browser application, or the Service Account could invoke some native UI to collect the admin’s elevated credentials during the specific configuration operation where such credentials are needed. From a layering POV, I’m sure this would be complicated, because the ability of a background service to pop stuff on the admin user’s desktop is intentionally limited.

If you’re depending upon an architecture like this, please stop. Pretty please! It’s fragile: it behaves differently based on the user’s default browser, behaves differently depending on what browser windows the user already has open (launch msedge.exe as Admin doesn’t result in an Elevated browser if Edge was already open), and exposes the user to a greater attack surface if they use the Elevated browser for anything else after finishing with your scenario.

Stay safe (and de-elevated) out there!

-Eric