Corelan Cybersecurity Research

Good morning friends,

I’d like to welcome you back on this second day of BlackHat Europe 2013.  Day 1 has been pretty interesting, so let’s see how day 2 goes (especially after Rapid7 and IOActive parties last night).  I think there is no better way of starting the second day at a conference with – say – some hardcore technical stuff about sandboxes.  This must be my luck day because that is exactly what Rafal Wojtczuk and Rahul Kashyap, from Bromium, will be covering in their talk.

What is a sandbox ?

A sandbox is an environment designed to run untrusted (or exploitable) code, in a manner that prevents the encapsulated code from damaging the rest of the system, Rahul explains.  In this talk, he continues, the researchers will present their findings on various sandbox implementations in Windows, from an architecture point of view.  The focus for this talk is not about sandbox escape exploit code, but rather show generic approaches to escaping from  specific types of sandbox (by, for example, using kernel bugs that can be triggered from within the sandboxed process)

For the sake of the talk, they have divided sandboxes into 2 types:

• Type 1 : OS enhancement based (Sandboxie, Buffer Zone Pro, etc)
• Type 2 : Master-slave model (Adobe Reader X, Google Chrome Browser).

Rahul explains that some applications have quite some significant interaction with the kernel, which is why they focused on this area.

Some facts:

Current OSs are large, complex and exploitable.  In 2012 alone, there are 12 CVE entries for kernel related issues.  In Feb of 2013, there were 30 CVE entries for win32k.sys.   The question is: to what degree does a sandbox limit the exposure the kernel to exploitation ?  (think “Duqu”).

How does a sandbox work ?

Sandboxed app: “Dear kernel, please open a file for me, the file name is at this address X”.  Kernel checks if app is allowed to access the file and informs the app.  If there is a bug in the sandbox routine, the kernel could corrupt its own memory, allowing for the injection and execution of arbitrary code in the kernel.

Type 2 : OS enhancement based Sandbox

(Sandboxie is used as the example)

Sandboxie is a custom kernel driver which modifies Windows behaviour to protect certain system components.  The sandbox has direct access to all OS functionality, which means almost all kernel vulnerabilities can be exploitable from within the sandbox.  The sandbox won’t be able to contain the malicious code because everything runs with the kernel.

Bypassing Sandboxie

Example : CVE-2012-0217 (MS12-042): This User Mode Scheduler Memory bug allows you to run arbitrary code in kernel mode.  In this particular case, when running in sandboxie container, the usual SYSTEM-token-steal shellcode is not sufficient to break out of the sandbox.  The exploit needs to use the “unlimited” power of the kernel to disable the sandbox driver or just migrate into another process (which runs outside of the sandboxie protection) so the shell code would run outside of the container, Rafal explains, and then moves on to demonstrating the exploit on an (unpatched) Windows 7 machine.

Bypassing Buffer Zone Pro

The approach is quite similar to Sandboxie, but BufferZone Pro also attempts to prevent data theft.  Rafal demonstrates that the same exploit (sysret.exe) as the one used in the demo for Sandboxie works for BufferZone as well.  In other words, a kernel bug is used to get code to run in the kernel (from inside the sandboxed cmd.exe process).  Once you have kernel privileges, you have enough power to break out of the BufferZone sandbox.

Type 2: Master/Slave type sandboxes

This type of sandboxes have 2 processes, a master and slave, which use some kind of IPC to communicate.  The slave process capabilities are limited by what the master defines.  For OS-based confinement, Rahul says, there is no protection for mounted FAT or FAT32 volumes, no protection for TCP/IP.  Access to most existing securable resources will be denied though.

To break out of this sandbox, you’ll need to attack the master.  The question is, how resistant is the master to a malicious slave, which runs with low integrity (Adobe) or “untrusted” (Chrome).  A recent exploit found in the wild, which breaks the Adobe Reader sandbox, shows that it is in fact possible to attack the master from he slave, using the IPC communication, but using a bug in the master.  The reality is that in general, this is quite complex to do and often requires a chain of exploits to be successfull.  Rahul mentions that, In Chrome, access to a FAT32 filesystem is denied.

How about attacking the kernel directly from the slave?  Rahul states that win32k.sys is still exposed to the slave process, so this might be a viable attack vector to break out of type2 sandboxes.

Bypassing the Chrome browser sandbox

MS12-075 / CVE-2012-2897 will be used to demonstrate how it would be possible to break out of the Chrome sandbox. Since the bug is based on a TTF Font Parsing Vulnerability, all you need to do to trigger the bug is visit a specifically crafted webpage.   Rafal says that the chances of achieving kernel code execution is much better if you can run code in the slave process first.

Bypassing Adobe Reader X

The approach here is very similar. Using a kernel bug (MS11-087), and the ability to run code inside the slave (renderer) process, the researchers were able to break out of the sandbox and get system permissions on the machine.  During the demonstration, they triggered a reader bug (allowing code to run in the slave… which is still sandboxed), injected code into the slave, which uses a kernel bug to break out of the sandbox.

Rafal continues by demonstrating that the same kernel bug can be used to break to of the Chrome sandbox as well. As soon as you can execute/inject arbitrary code in the slave process, you could try to break out of the sandbox by attacking the kernel, and not the master process.

Conclusion

• Many Windows kernel vulnerabilities have been discovered and can be used to leverage sandbox escapes, if you can trigger the bug from the sandboxed process.  One of the exploits used at pwn2own last week uses a kernel bug to break out of the sandbox, so this is still a viable attack vector.
• Virtualization based sandboxing might offer additional protection, because the entire OS is wrapped into a sandbox.  OS vulnerabilities will be nonfatal, but you need a special hypervisor (which can be a target by itself).
• SMEP may not solve the issue, as it focuses on exploitation and not preventing bugs.

© 2013, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.

Similar/Related posts:

BlackHatEU2013 – Day2 – Who’s really attacking your ICS devices ? BlackHatEU2013 – Day2 – Advanced Heap Manipulation in Windows 8 BlackHatEU2013 – Day2 – DropSmack: How cloud synchronization services render your corporate firewall worthless HITB2012AMS Day 1 – WinRT The Metro-politan Museum of Security BlackHatEU2013 – Day1 – Hacking Appliances