Researchers and attackers alike are quickly discovering you don’t need a fancy Java or Flash exploit to beat application sandboxes. Exploiting an unpatched kernel vulnerability in the underlying operating system, one that’s likely to stay unpatched for a long time, will do just fine.
Twice this month, folks on the research side have demonstrated successful attacks using this technique, first at CanSecWest during the Pw2Own contest, and then last week at Black Hat EU. On the attacker’s end, the Duqu malware is probably the most notorious and malicious demonstration of kernel-side sandbox busting.
“The interesting part is that this hasn’t been a scary topic,” said Rahul Kashyap, chief security architect at Bromium, a virtualization security company. “There haven’t been a lot of kernel vulnerabilities, but in the last year or so, there have been a lot more kernel patches coming out of Microsoft, which indicates the bad guys are targeting more on the kernel side. Unfortunately, it’s incredibly hard to patch these issues. If your OS is vulnerable, you are only as good as your next OS patch.”
Exploiting these fundamental architectural limitations isn’t trivial; a kernel exploit is more difficult to write than a Java- or PDF-based exploit, experts said. The majority of it has emerged from well-funded campaigns such as Duqu, which used an exploit in a Word document containing an embedded TrueType font file that exploited a vulnerability in the font’s parsing engine.
Kashyap and fellow Bromium researcher Rafal Wojtczuk took a similar path at Black Hat EU with research they did against Sandboxie, a commercial Windows-based sandbox used for application isolation and popular with malware analysts. While the tool operates as advertised in safely executing code within its isolated container, it also has to interface with the kernel on some levels in order for arbitrary code to run properly. With fonts, for example, Kashyap said a kernel call has to be made from the sandbox to the kernel; the sandbox has to allow the call to pass in order for, in this case, the font to render properly.
“Duqu exploited this vulnerability in font parsing to compromise the host. All of these kernel interfaces are bypassable by Duqu,” Kashyap said. “Using several exploits for bugs in the way calls are handled by the kernel, it was easy to get a blue screen.”
Font parsing exists in the operating system kernel for performance reasons. If the sandbox were to intercept these calls, there would be a huge performance overhead because the OS would not see and process the fonts properly, Kashyap said.
“There is a lot of exposure from the OS kernel that people don’t realize,” he said. “The moment you compromise the kernel, you have the same privileges as the kernel. You can disable the sandbox, access other programs and data and breach everything out there. With most Java exploits, for example, you still have to do privilege escalation. With the kernel, this is the worst-case scenario.”
Similarly, the Google Chrome browser sandbox requires some kind of interface to the underlying kernel in Windows and Linux in order for features in the respective applications to render properly. Linux, however, is a bit more hardened than Windows because Linux has a mechanism within it called seccomp-bp syscall filter that further reduces access outside the sandbox; a similar feature is not available in Windows. Using the same True Type font parsing vulnerability, the Bromium researchers demonstrated last week a successful integer overflow attack to force Chrome to visit a malicious web page or view a malicious PDF using the built-in Adobe Reader and trigger a vulnerability.
“Chrome has been hardened and that made it difficult, but we found that it is possible to break out of the sandbox again,” Kashyap said. “They have not been designed to protect against kernel vulnerabilities. The best job Chrome can do is to protect itself; kernel vulnerabilities are out of Google’s design scope. This is a very serious vector.”
Researchers at MWR Labs were also able to successfully compromise Chrome running on a Windows laptop during Pwn2Own, stringing together a number of exploits and vulnerabilities to bypass memory protections in the browser such as ASLR and DEP, and a separate kernel vulnerability to elevate privileges.
“We showed an exploit against previously undiscovered vulnerabilities in Google Chrome running on a modern Windows-based laptop. By visiting a malicious webpage, it was possible to exploit a vulnerability which allowed us to gain code execution in the context of the sandboxed renderer process. We also used a kernel vulnerability in the underlying operating system in order to gain elevated privileges and to execute arbitrary commands outside of the sandbox with system privileges,” MWR Labs said in an explanation of their technique.
Despite successful compromises of sandbox technology, experts said this hardly indicates the technology isn’t viable to contain commodity malware, for example.
“Given that attackers are getting more sophisticated, this is more of an increasing threat than in the past,” Kashyap said. “There isn’t enough kernel-level protection in the endpoint security industry; a bypass of the sandbox, could mean a bypass of antivirus and other security protections. Sophisticated attackers will try to leverage this type of attack going forward.”
