Microsoft security sandbox for IE: Still broken after all these years

Four years later, a key IE defense against drive-by attacks is still easy to bypass.

There's a trivial way for drive-by exploit developers to bypass the security sandbox in almost all versions of Internet Explorer, and Microsoft says it has no immediate plans to fix it, according to researchers from Hewlett-Packard.

The exploit technique, laid out in a blog post published Thursday, significantly lowers the bar for attacks that surreptitiously install malware on end-user computers. Sandboxes like those included in IE and Google Chrome effectively require attackers to devise two exploits, one that pierces the sandbox and the other that targets a flaw in some other part of the browser. Having a reliable way to clear the first hurdle drastically lessens the burden of developing sophisticated attacks.

The bypass technique "does give the attacker a significant advantage by giving them higher-level access than a typical exploit might in Internet Explorer, by allowing them to escape the sandbox," Robert "Rsnake" Hansen, a vice president at security firm WhiteHat Labs, wrote in an e-mail to Ars. "In practical terms this is a very important finding, because it can be tied into existing exploits that might otherwise not be able to escape the IE sandbox."

A Balkanized state for attack code

Known as Protect Mode, Microsoft's sandbox works by funneling most Web content into a "low integrity" level that has limited access to other applications or sensitive parts of the operating system. Attacks that remain confined to this Balkanized state still may be suitable for denial-of-service attacks or installing scripts that automate the sending of spam, but they generally have a much harder time surviving a reboot and gaining more access to a targeted system. The HP researchers found a trivial way to funnel attack code into "medium integrity" processes that are allocated to normal Windows users. The technique was first documented by researchers from Verizon in 2010, when IE 7 was in vogue. The HP researchers' contribution was to show that it remains viable even against most newer versions.

The technique involves setting up a fake Web server that executes a reliable working exploit against the computer's localhost address used for communicating with services on the same local system. With that, the attack code runs with medium integrity privileges with no constraint from the sandbox. The technique works by default against all versions of IE except IE 11 running on Windows 8.1. By default, that configuration implements enhanced protection mode (EPM), which is immune to the bypass. EPM is also enabled by default in IE 10 and 11 when running in metro mode. It needs to be enabled in desktop mode.

In a four-sentence statement, Microsoft officials downplayed the severity of the bypass. It said:

We do not consider this to be a security vulnerability within Protected Mode. Protected Mode is a defense-in-depth feature introduced by Internet Explorer 7 in 2006 and improved by Enhanced Protected Mode in 2012. Enhanced Protected Mode enabled in Internet Explorer 11 and running on Windows 8.1, blocks this technique. This technique cannot be used, on its own, to compromise a customer’s security.

Some outside researchers remain unconvinced.

"It is important to highlight the fact that launching medium integrity processes is a problem in four major versions of Internet Explorer since the Verizon paper," HP researcher Matt Molinyawe wrote. "You don’t need the required protected mode API or have to interface with the broker at all. Simply redirect with any means possible, whether it be with JavaScript, page reload, etc. Our identification that redirection to medium integrity can occur with what can be considered normal operation demonstrates that this can potentially be used in a covert manner without triggering anomalous behavior."

HD Moore, chief research officer at Rapid7, agreed the bypass is serious.

"In my opinion, network administrators should respond by switching users over to a more secure browser, such as Chrome, and looking into an additional layer of sandboxing for anyone who must use Internet Explorer," he said. Third-party sandboxing from Sandboxie and Invincea are good candidates, he said, as are Amazon desktop images with no content, temporary virtual machines, and Microsoft's Enhanced Mitigation Experience Toolkit.

From what I understand from the linked article, they use an exploit at the low-integrity level to set up a minor http proxy so they can redirect to localhost, which then elevates all of IE's processes to medium integrity, allowing them to do more stuff - it's probably the easiest way to elevate to medium integrity, since IE does that itself.

At that point they spawn calc processes as an example (which they couldn't do at low integrity, I assume); I guess that they can just spawn whatever processes they please?

From what I understand from the linked article, they use an exploit at the low-integrity level to set up a minor http proxy so they can redirect to localhost, which then elevates all of IE's processes to medium integrity, allowing them to do more stuff - it's probably the easiest way to elevate to medium integrity, since IE does that itself.

Yes, this appears to be the case.

What I find surprising is that apparently a low-integrity process is able to listen on a network port. This isn't something I would have thought a low-integrity process should be allowed to do. So maybe that's why they set up EPM, and are now making that the default.

The other mitigation would be to change the default zone for intranet sites to "Medium-High" (security) from "Medium-Low". In fact, I might just push that out via GPO in my office next week. All of our internal stuff is properly behaved.

To clarify how this works. Take the IE exploit of the week (whichever of the many available for the target in question). You convince your target to visit my-evil-domain.example.com, this web site triggers the exploit and forces IE to execute a payload in the "low integrity" sandbox. This payload is a web server bound to a randomly chosen port.

At the same time, the exploit page is waiting for this web server to start responding and then forces IE to browse to http://localhost:random_port/ which now runs in "medium integrity" mode because "localhost" is in the default "intranet zone" for most workstations joined to a domain. The fake web server returns the code that triggers the exploit, but instead of creating a web server, the payload is now a malicious, persistent piece of malware, that has the same rights as the user and is not in the "low integrity" sandbox.

Its a complicated process to explain because it is a complicated process. The short version is the exploit is used twice, the first time by the initial evil web site, the second time by a web server created by the first execution of the exploit, which is enough to break out of the sandbox in the default configuration of domain-joined workstations.

69 Reader Comments

This is why everyone should always use a non-privileged account on internet connected computers. Browser may get owned but the attacker won't be able to do much without using three exploits: sandbox, browser, and then escalation of privilege. Considerably lowers the chances of getting hit with system-context malware such as a rootkit. Worst outcome, usually, is having some add-on tagged to IE or a DLL or executable dropped into user profile folder and running in user context. That's obvious if you know what to look for, and easily cleaned.

Once you get into the realm of true rootkits and invisible malware, where there's nothing odd in Task Manager and no funny DLLs loaded anywhere and yet your perimeter logs are still showing network traffic to an IP address in China, that's pretty much game over.

Just to make sure I understand: this vulnerability relies on having a pre-existing malicious process running, right? A low-integrity site cannot actually launch this process? If so, it doesn't seem that shocking that a compromised machine can be compromised.

I think the article's title is alarmist. This involves setting up a webserver on the client machine. It then allows a script to connect to that webserver to run bad code which probably has about as many privileges as the webserver.The only thing confusing me is the term "fake Web server". What does "fake" mean?

In response to EPM: In a nutshell, all those things that companies still regretfully need old versions of IE for? They involve code that's badly secured and basically allows full programs to run inside the browser. EPM would likely stop those from running, basically turning IE into *gasp* a normal HTML5 web browser unpolluted by ActiveX controls from decades ago.

Given that it's Microsoft, and given that they put a great deal of effort into not breaking compatibility[1], perhaps the problem is that they can't think of a way to fix this that won't completely break something else.

If EPM can block this vector why isn't that technology enabled by default on IE 10, and earlier? Is there some downside to this?

Yup. I can't remember the details, but I disabled it the same day I turned it on. It blocks you from operations you probably consider routine - as I said, can't remember specifics, but I think it blocks things like opening a PDF from a web page.

If EPM can block this vector why isn't that technology enabled by default on IE 10, and earlier? Is there some downside to this?

Pretty sure that EPM forces IE to always run in 64-bit mode, and there are stellar masses of ActiveX controls out there that will not run in 64-bit mode. Ask me how I know!

ninja edit: Nope. Per Microsoft:

Quote:

When this feature is enabled, add-ons such as toolbars, browser helper objects (BHOs), and extensions are loaded only if they are compatible with Enhanced Protected Mode. If you have to load an incompatible add-on, you can disable Enhanced Protected Mode for the desktop browser. This action lets incompatible add-ons load, but it may increase the risk of having malware or other potentially harmful software installed on your computer.

Still, lots of ActiveX out there that won't be compatible without rewriting and testing.

This is why everyone should always use a non-privileged account on internet connected computers. Browser may get owned but the attacker won't be able to do much without using three exploits: sandbox, browser, and then escalation of privilege.

That's all well and good but Windows users REFUSE to listen and/or understand.

It will never get fixed either... because if Microsoft does that then countless consumer zombies users will be lost whenever they have to install a program and remember that there is an admin account with an admin password. The problem is further exacerbated by all the installation packages that do not automatically prompt for elevated privileges, but rather fail during installation (you must remember to launch it with admin rights).

Raymond Chen's ranted about the amount of time that is wasted by bogus exploit reports submitted by random people to MS of the form "An attacker who already has admin rights to the system can exploit component X to compromise Y, where Y is something that can be done directly with admin rights".

Unless I'm misunderstanding what HP is reporting, if you substitute "admin rights" with "normal user rights" everywhere, you've got the worst case version of HPs report (where the webserver was installed via xcopy so no elevation was required). I really thought better of HP than this.

If EPM can block this vector why isn't that technology enabled by default on IE 10, and earlier? Is there some downside to this?

Pretty sure that EPM forces IE to always run in 64-bit mode, and there are stellar masses of ActiveX controls out there that will not run in 64-bit mode. Ask me how I know!

ninja edit: Nope. Per Microsoft:

Quote:

When this feature is enabled, add-ons such as toolbars, browser helper objects (BHOs), and extensions are loaded only if they are compatible with Enhanced Protected Mode. If you have to load an incompatible add-on, you can disable Enhanced Protected Mode for the desktop browser. This action lets incompatible add-ons load, but it may increase the risk of having malware or other potentially harmful software installed on your computer.

Still, lots of ActiveX out there that won't be compatible without rewriting and testing.

Enabling or disabling EPM is a little less fun than they make it sound, since it requires a reboot. "Disable for the desktop browser" isn't something anyone will want to do every time they come up against something that doesn't work.

I usually look forward to articles from Dan Goodin, but this one is a real stinker. I mean come on, the exploit involves setting up a web server on the target. If it needs that level of access then the system is already compromised.

This is why everyone should always use a non-privileged account on internet connected computers. Browser may get owned but the attacker won't be able to do much without using three exploits: sandbox, browser, and then escalation of privilege.

So they get access to all of your data, can impersonate you to every logged in service, etc. but the good news is that they can't alter the system wallpaper files shipped under C:\Windows?

That approach has been known to be limited for decades and it provides almost no benefit at all on a single-user system. Fixing this problem really requires going further down the privilege separation path running each application inside a sandbox with a phone-style access control system to prevent every running program from being able to silently access everything under your account.

A mitigation exists (EPM). The reason this is off by default is because it breaks so many add-ons people need. The features those add-ons need inherently enable some badness. Yes, it's sad. Yes, we should have known better N years ago. We didn't

If an attacker already has the ability to run arbitrary code on your PC (aka a web server on localhost), then I think an IE exploit is the least of your worries.

Fixing this problem really requires going further down the privilege separation path running each application inside a sandbox with a phone-style access control system to prevent every running program from being able to silently access everything under your account.

If EPM can block this vector why isn't that technology enabled by default on IE 10, and earlier? Is there some downside to this?

Pretty sure that EPM forces IE to always run in 64-bit mode, and there are stellar masses of ActiveX controls out there that will not run in 64-bit mode. Ask me how I know!

ninja edit: Nope. Per Microsoft:

Quote:

When this feature is enabled, add-ons such as toolbars, browser helper objects (BHOs), and extensions are loaded only if they are compatible with Enhanced Protected Mode. If you have to load an incompatible add-on, you can disable Enhanced Protected Mode for the desktop browser. This action lets incompatible add-ons load, but it may increase the risk of having malware or other potentially harmful software installed on your computer.

Still, lots of ActiveX out there that won't be compatible without rewriting and testing.

Enabling or disabling EPM is a little less fun than they make it sound, since it requires a reboot. "Disable for the desktop browser" isn't something anyone will want to do every time they come up against something that doesn't work.

Outside of office workers with crap legacy systems, how many people actually need to ever visit a site with a legitimate activeX control anymore?

This is why everyone should always use a non-privileged account on internet connected computers. Browser may get owned but the attacker won't be able to do much without using three exploits: sandbox, browser, and then escalation of privilege.

So they get access to all of your data, can impersonate you to every logged in service, etc. but the good news is that they can't alter the system wallpaper files shipped under C:\Windows?

That approach has been known to be limited for decades and it provides almost no benefit at all on a single-user system. Fixing this problem really requires going further down the privilege separation path running each application inside a sandbox with a phone-style access control system to prevent every running program from being able to silently access everything under your account.

Aye it is a problem that Windows, by default, basically has two levels of access for every program: either full access to all the users files and settings or full access to the entire system. This is why I look forward to the rumoured windowed Metro apps in Windows 9, although if they stick with the MS account requirement it could seriously impact uptake.

Of course some programs (system tools or application managers such as Steam) will require more access than Metro can give but those should be the exception rather than the rule.

This is nothing. I've heard that if a malicious hacker has physical access and superuser priviliges they can do almost anything! Someone really needs to fix this problem. I can't believe it's been 28 years since Windows 1.0 an no one has done anything about it.

From what I understand from the linked article, they use an exploit at the low-integrity level to set up a minor http proxy so they can redirect to localhost, which then elevates all of IE's processes to medium integrity, allowing them to do more stuff - it's probably the easiest way to elevate to medium integrity, since IE does that itself.

At that point they spawn calc processes as an example (which they couldn't do at low integrity, I assume); I guess that they can just spawn whatever processes they please?

Once you get into the realm of true rootkits and invisible malware, where there's nothing odd in Task Manager and no funny DLLs loaded anywhere and yet your perimeter logs are still showing network traffic to an IP address in China, that's pretty much game over.

What tool would you recommend to visualize rogue http connections? Network Monitor and TcpView are too generic for this particular use.

As far as I know Process Explorer does not differentiate between dll's loaded at boot time and dll injections. Do you know of any tool that visualizes/alerts when injections occur?

From what I understand from the linked article, they use an exploit at the low-integrity level to set up a minor http proxy so they can redirect to localhost, which then elevates all of IE's processes to medium integrity, allowing them to do more stuff - it's probably the easiest way to elevate to medium integrity, since IE does that itself.

Yes, this appears to be the case.

What I find surprising is that apparently a low-integrity process is able to listen on a network port. This isn't something I would have thought a low-integrity process should be allowed to do. So maybe that's why they set up EPM, and are now making that the default.

The other mitigation would be to change the default zone for intranet sites to "Medium-High" (security) from "Medium-Low". In fact, I might just push that out via GPO in my office next week. All of our internal stuff is properly behaved.

This is why everyone should always use a non-privileged account on internet connected computers. Browser may get owned but the attacker won't be able to do much without using three exploits: sandbox, browser, and then escalation of privilege.

So they get access to all of your data, can impersonate you to every logged in service, etc. but the good news is that they can't alter the system wallpaper files shipped under C:\Windows?

That approach has been known to be limited for decades and it provides almost no benefit at all on a single-user system. Fixing this problem really requires going further down the privilege separation path running each application inside a sandbox with a phone-style access control system to prevent every running program from being able to silently access everything under your account.

You missed the point. Userland malware will be noticed almost immediately and removed... quite possibly before the hacker gets a chance to tell it what it wants to do with your PC. A rootkit will be undetected for months maybe even years. See the difference?

Aye it is a problem that Windows, by default, basically has two levels of access for every program: either full access to all the users files and settings or full access to the entire system.

Yeah, I take it you're not familiar with the Low Integrity Level?

Yeah and that's great for IE (assuming it doesn't have holes of course). But in the more general case Metro actually guarantees that a program will never leave the Metro sandbox (with browsers being the only exception). Even the installer doesn't get to arbitrary access to the system. The user can't make such guarantees with other programs (and besides, few third-party applications are designed to work in low integrity even if you try to force it).

"In my opinion, network administrators should respond by switching users over to a more secure browser, such as Chrome, and looking into an additional layer of sandboxing for anyone who must use Internet Explorer,"

Aye it is a problem that Windows, by default, basically has two levels of access for every program: either full access to all the users files and settings or full access to the entire system.

Yeah, I take it you're not familiar with the Low Integrity Level?

Yeah and that's great for IE (assuming it doesn't have holes of course). But in the more general case Metro actually guarantees that a program will never leave the Metro sandbox (with browsers being the only exception). Even the installer doesn't get to arbitrary access to the system. The user can't make such guarantees with other programs (and besides, few third-party applications are designed to work in low integrity even if you try to force it).

(this post might not really apply to your post, sorry if I misunderstood you.)The EPM option in IE11, is the metro sandbox (called AppContainer) for IE desktop mode. As others have said, it's just not enabled by default, because active-x controls are not widely written to it, although flash does work in it, which is probably the only plug in most IE users need. I assume any program can also do something like IE's EPM, they just don't since there is little enthusiasm for such things unfortunately.

But yea, I agree with the posters that said this is alarmist, as someone said MS has a solution (EPM), active-x control makers just need to be pushed into supporting it.

If EPM can block this vector why isn't that technology enabled by default on IE 10, and earlier? Is there some downside to this?

Pretty sure that EPM forces IE to always run in 64-bit mode, and there are stellar masses of ActiveX controls out there that will not run in 64-bit mode. Ask me how I know!

ninja edit: Nope. Per Microsoft:

Quote:

When this feature is enabled, add-ons such as toolbars, browser helper objects (BHOs), and extensions are loaded only if they are compatible with Enhanced Protected Mode. If you have to load an incompatible add-on, you can disable Enhanced Protected Mode for the desktop browser. This action lets incompatible add-ons load, but it may increase the risk of having malware or other potentially harmful software installed on your computer.

Still, lots of ActiveX out there that won't be compatible without rewriting and testing.

Enabling or disabling EPM is a little less fun than they make it sound, since it requires a reboot. "Disable for the desktop browser" isn't something anyone will want to do every time they come up against something that doesn't work.

Outside of office workers with crap legacy systems, how many people actually need to ever visit a site with a legitimate activeX control anymore?

I don't disagree, but it's a lot more than Active-X. I open PDFs from IE every day, and I'm not likely to fight with IE every time I want to do so. Other people use toolbars installed by LOB productivity apps that aren't likely to get upgraded to support EPM any time soon. Basically, the whole thing is an IT nightmare - I'm not likely to sign up for a zillion user phone calls about some stupid thing that doesn't work.

If EPM can block this vector why isn't that technology enabled by default on IE 10, and earlier? Is there some downside to this?

Pretty sure that EPM forces IE to always run in 64-bit mode, and there are stellar masses of ActiveX controls out there that will not run in 64-bit mode. Ask me how I know!

ninja edit: Nope. Per Microsoft:

Quote:

When this feature is enabled, add-ons such as toolbars, browser helper objects (BHOs), and extensions are loaded only if they are compatible with Enhanced Protected Mode. If you have to load an incompatible add-on, you can disable Enhanced Protected Mode for the desktop browser. This action lets incompatible add-ons load, but it may increase the risk of having malware or other potentially harmful software installed on your computer.

Still, lots of ActiveX out there that won't be compatible without rewriting and testing.

Enabling or disabling EPM is a little less fun than they make it sound, since it requires a reboot. "Disable for the desktop browser" isn't something anyone will want to do every time they come up against something that doesn't work.

enabling/disabling EPM does not require a reboot, you only need to close and re-open IE.

"In my opinion, network administrators should respond by switching users over to a more secure browser, such as Chrome, and looking into an additional layer of sandboxing for anyone who must use Internet Explorer,"

Pretty hard to manage Chrome via AD IIRC.

Exactly right, and in a small business (at least this one), that's not going to happen. About six months ago, I visited a workstation where the user was running Firefox 3. Short of walking from one PC to another and manually verifying version and patch level, there's no free or inexpensive, simple way to manage any browser besides IE.

If EPM can block this vector why isn't that technology enabled by default on IE 10, and earlier? Is there some downside to this?

Pretty sure that EPM forces IE to always run in 64-bit mode, and there are stellar masses of ActiveX controls out there that will not run in 64-bit mode. Ask me how I know!

ninja edit: Nope. Per Microsoft:

Quote:

When this feature is enabled, add-ons such as toolbars, browser helper objects (BHOs), and extensions are loaded only if they are compatible with Enhanced Protected Mode. If you have to load an incompatible add-on, you can disable Enhanced Protected Mode for the desktop browser. This action lets incompatible add-ons load, but it may increase the risk of having malware or other potentially harmful software installed on your computer.

Still, lots of ActiveX out there that won't be compatible without rewriting and testing.

Enabling or disabling EPM is a little less fun than they make it sound, since it requires a reboot. "Disable for the desktop browser" isn't something anyone will want to do every time they come up against something that doesn't work.

enabling/disabling EPM does not require a reboot, you only need to close and re-open IE.

Then Microsoft should take out the thing that says "Takes effect after you restart your computer" on the Internet Options -> Advanced tab.