So Pwnium 2013, held at Cansec West, started today. And while details of the attacks aren’t out, one in particular stuck out to me. This post can be considered something of a “Part 2” to my “Securing Insecure Systems” because it highlights the absolute number one most important thing – a secure kernel is necessary for a secure system.
MWRLabs was the only contested booked for Chrome hacking, and they were successful, leveraging initial RCE/ASLR bypasses on Windows 7 to gain access to Chrome. From there they exploited a kernel vulnerability, and that’s where the fun is.
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.
What people need to realize is that no matter how tight Chrome’s sandbox (Untrusted has no read/write access to the entire file system, and that’s where they started) there’s an entire complex full-of-vulns kernel sitting right there, ripe for exploitation. And MWRLabs took advantage of that – they broke through the sandbox.
And what does that prove? It proves that no matter what the hell you do to restrict things like file access, if you leave your kernel exposed, you are vulnerable.
On Linux I see, time and time again, that people feel they don’t need PaX/Grsecurity. These people state “Oh, well we have SELinux”. This proves that MAC is not enough. You’re trying to solve an insecure kernel by putting a piece of code in your kernel that restricts file access… nope.
Thankfully, on Linux, there are ways to limit kernel attack surface. You’ve got seccomp mode 2 filters, which filter access to the kernel. By limiting kernel attack surface you make the kernel more difficult to exploit – though this does not negate the need for a patched and hardened kernel.
So what do you want to take from this?
1) No. You aren’t secure if you don’t patch.
2) No. You aren’t secure just because you use SELinux.