What is a sandbox ?<\/h3>\n
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. \u00a0In this talk, he continues, the researchers will present their findings on various sandbox implementations in Windows, from an architecture point of view. \u00a0The focus for this talk is not about sandbox escape exploit code, but rather show generic approaches to escaping from \u00a0specific types of sandbox (by, for example, using kernel bugs that can be triggered from within the sandboxed process)<\/p>\n
For the sake of the talk, they have divided sandboxes into 2 types:<\/p>\n
- \n
- Type 1 : OS enhancement based (Sandboxie, Buffer Zone Pro, etc)<\/li>\n
- Type 2 : Master-slave model (Adobe Reader X, Google Chrome Browser).<\/li>\n<\/ul>\n
Rahul explains that some applications have quite some significant interaction with the kernel, which is why they focused on this area.<\/p>\n
Some facts:<\/h3>\n
Current OSs are large, complex and exploitable. \u00a0In 2012 alone, there are 12 CVE entries for kernel related issues. \u00a0In Feb of 2013, there were 30 CVE entries for win32k.sys. \u00a0 The question is: to what degree does a sandbox limit the exposure the kernel to exploitation ? \u00a0(think \"Duqu\").<\/p>\n
How does a sandbox work ?<\/h3>\n
Sandboxed app: \"Dear kernel, please open a file for me, the file name is at this address X\". \u00a0Kernel checks if app is allowed to access the file and informs the app. \u00a0If 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.<\/p>\n
Type 2 : OS enhancement based Sandbox<\/h3>\n
(Sandboxie is used as the example)<\/p>\n
Sandboxie is a custom kernel driver which modifies Windows behaviour to protect certain system components. \u00a0The sandbox has direct access to all OS functionality, which means almost all kernel vulnerabilities can be exploitable from within the sandbox. \u00a0The sandbox won't be able to contain the malicious code because everything runs with the kernel.<\/p>\n
Bypassing Sandboxie<\/h4>\n
Example : CVE-2012-0217 (MS12-042): This User Mode Scheduler Memory bug allows you to run arbitrary code in kernel mode. \u00a0In this particular case, when running in sandboxie container, the usual SYSTEM-token-steal shellcode is not sufficient to break out of the sandbox. \u00a0The 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.<\/p>\n
![\"20130315](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2013\/03\/20130315_101805.jpg.jpeg\" "\\"20130315_101805.jpg.jpeg\\"")
<\/p>\nBypassing Buffer Zone Pro<\/h4>\n
The approach is quite similar to Sandboxie, but BufferZone Pro also attempts to prevent data theft. \u00a0Rafal demonstrates that the same exploit (sysret.exe) as the one used in the demo for Sandboxie works for BufferZone as well. \u00a0In other words, a kernel bug is used to get code to run in the kernel (from inside the sandboxed cmd.exe process). \u00a0Once you have kernel privileges, you have enough power to break out of the BufferZone sandbox.<\/p>\n
Type 2: Master\/Slave type sandboxes<\/h3>\n
This type of sandboxes have 2 processes, a master and slave, which use some kind of IPC to communicate. \u00a0The slave process capabilities are limited by what the master defines. \u00a0For OS-based confinement, Rahul says, there is no protection for mounted FAT or FAT32 volumes, no protection for TCP\/IP. \u00a0Access to most existing securable resources will be denied though.<\/p>\n
To break out of this sandbox, you'll need to attack the master. \u00a0The question is, how resistant is the master to a malicious slave, which runs with low integrity (Adobe) or \"untrusted\" (Chrome). \u00a0A 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. \u00a0The reality is that in general, this is quite complex to do and often requires a chain of exploits to be successfull. \u00a0Rahul mentions that, In Chrome, access to a FAT32 filesystem is denied.<\/p>\n
How about attacking the kernel directly from the slave? \u00a0Rahul 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.<\/p>\n
Bypassing the Chrome browser sandbox<\/h4>\n
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. \u00a0 Rafal says that the chances of achieving kernel code execution is much better if you can run code in the slave process first.<\/p>\n
Bypassing Adobe Reader X<\/h4>\n
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. \u00a0During the demonstration, they triggered a reader bug (allowing code to run in the slave\u2026 which is still sandboxed), injected code into the slave, which uses a kernel bug to break out of the sandbox.<\/p>\n
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.<\/p>\n
![\"20130315](\"https:\/\/www.corelan.be\/wp-content\/uploads\/2013\/03\/20130315_104301.jpg.jpeg\" "\\"20130315_104301.jpg.jpeg\\"")
<\/p>\n<\/p>\n
Conclusion<\/h3>\n