Thursday, 17 April 2014
Silent bug is silent. PDF Print
Written by Rubén   
Wednesday, 10 August 2011

Hi there,
During the last months, completed in this Patch Tuesday, Microsoft has 'abruptly' changed a policy that was working for years:

I guess that XBAP apps were posing a risk level too high to get accepted. At the same price, they have silently fixed a blatant method to bypass IE protected mode I discovered long time ago...let me explain it briefly.

There are 3 main integrity levels: low, medium, high. IE8/9 launches two differente process.

-> Broker/Monitor (medium integrity) (parent)
-> Browser (low integrity) (child)

The low integrity instance is where those funny shellcodes are executed, so we should understand this flaw as the second stage within a client-side exploitation scenario. Therefore, a remote code execution is mandatory before taking advantage of this flaw.

A common scenario would be the following:

1. Ban Ki-Moon visits a malicious U.N website where a RCE vulnerability is triggered within the context of the low integrity IE
2. Local exploit is executed to bypass IE Protected mode.
3. VLC playing Nyan Cat video is launched as a medium integrity process.

But...How !?

Microsoft introduced the concept of "broker processes" to let extensions, running inside the IE low integrity instance, perform operations that need higher privileges. These processes are registered through the following key:

\HKEY_LOCAL_MACHINE SOFTWARE\Microsoft Internet Explorer\Low Rights\ElevationPolicy

Thus, if a low integrity instance invokes one of these registered broker processes, the medium integrity instance will handle this request. Sometimes even without prompting the user. It depends on this policy:

0x3 = Protected Mode silently launches the broker as a medium integrity process

PresentationHost.exe is registered as a broker process of type 3. Basically, this process takes care of WPF applications. Ok, so we can silently launch this process as a medium integrity process so far. However we still need another step, we should be able to take advantage of this feature to launch an arbitrary executable as a medium integrity process.

Now comes the interesting part. There was (or even *is*) a design flaw on Windows Vista and 7, by reading the specs I noted an interesting behavior: WPF applications run inside the presentationhost's SandBox and its graphical output is rendered inside Internet Explorer. Cool. Game over.I love this flaw because reverse engineering is not involved as usual, all you need to do is reading documentation. I wonder how many people also discovered this flaw, sure I was not the only one.

So taking into account XBAP applications loaded from the local file system ( even from LocalLow ;) ) were considered as a full-trust application (with no restrictions in terms of CAS), we could abuse this design flaw to execute an arbitrary .NET application as a medium integrity process, from our IE low integrity instance.

Unfortunately the trick is no longer working since urlmon!CSecurityManager::MapToUrlZone, no matter the location of your XBAP app, will map it to the Internet Zone. This prevents XBAP apps from being loaded due to the new policy of URLACTION_WINDOWS_BROWSER_APPLICATIONS is 'Disabled' by default.

References I used to discover this bug

Understanding and Working in Protected Mode Internet Explorer

Windows Presentation Foundation Security Sandbox

Last Updated ( Monday, 15 August 2011 )
< Prev   Next >