Post navigation

Native Client Sandbox – Sandboxing Sandboxing

For those of you don’t know, Google’s Native Client is a way for browsers to run native code within the browser. In other words, I can write a C/C++ program (or any other LLVM supported program) and run it within the browser – pretty cool! The benefits are all over the place but, basically, ChromeOS has been largely criticized for being a ‘limited’ operating system, with apps that aren’t very powerful, and NaCl provides a way for developers to create secure and powerful applications.

But NaCl isn’t the first project to try to do this. The infamous Active X tried beforehand and, as we all know, totally sucked in terms of security. Will NaCli be a massive hole in an otherwise secure browser? Nope. Because Google poured on the security goodness here once more. Seriously, I realize most people don’t have the monetary capabilities of Google, but they do a hell of a lot when it comes to securing products these days.

We all know by now (if you don’t, read more of my posts!) that Chrome runs in a pretty cool sandbox. On Windows sandboxing is limited and, while Chrome does an excellent job, Linux provides more tools for sandboxing that address critical issues. On Linux, even conservatively, the sandbox is very impressive. Your renderer process, the most exposed codebase, is running with no rights – it can’t interact with the kernel, it has no file access, it basically gets fonts and that’s it. It’s locked into a tight sandbox. Yet Google decided that, for NaCl, they’re going to add *yet another sandbox*, which means that all NaCl code runs within the Chrome sandbox and the NaCl sandbox. In short, the Native Client process is a PPAPI process that runs in the Chrome Renderer process, so it is limited in the same ways.

That’s pretty cool. What’s cooler is how the NaCl sandbox works (without getting into PPAPI and the proxy it’s kind of not doing it all justice, but I’m writing this spontaneously at 3am oh well!).

On x86 NaCl uses a processor specific feature called segmentation. Segmentation, something I’ve seen used in PaX, the group who invented security techniques such as ASLR, is a method for the CPU to change which areas of address space are accessible to programs, and their rights. Unfortunately, segmentation is not supported on other architectures, and NaCl supports ARM and 64bit as well as x86. Just like PaX found a work around, so did Google – the implementation differs between ARM and x86_64 but the goals are all the same. (Upon watching a video on NaCl he also skims over it – anyone know more on the documentation? Seems like for 64bit they just use guard pages to separate the data/ code ‘segments’.)

NaCl executables are built with a toolchain that does a couple of pretty interesting things. NaCl executables are compiled without specific instructions, they’re blacklisted and will simply not be allowed into the codebase. Interestingly, they ban ret… so instead of returning, you jmp, push, pop. There’s a toolchain feature that has to do with alignment of instructions, rather than get into the details, the point is that you can’t jump into the middle of a chain of instructions, you have to jump to the beginning. When the toolchain returns your assembly it’s provided a safer and saner memory model that invalidates the ability to exploit specific types of vulnerabilities.

NaCl also performs instruction validation. If it sees any blacklisted instructions it kills the process, naturally. It basically does a check, before runtime, on the file to ensure that it’s not trying to perform actions that shouldn’t be allowed (though if you use the toolchain these should never be built in anyways).

Again, all of the visible attack surface from a NaCl executable is also sandboxed. That means that even if I get out of the NaCl sandbox through the proxy interface or through the renderer I’m still stuck in what are essentially the strongest sandboxes currently implemented on consumer systems and I still need to leverage another attack to get out.

I’d love to take each specific area of the sandbox (like the ret removal) and just break down exactly how that works and how effective it is, but this was a post of boredom and inability to sleep. The sandbox itself is very complex, but pretty cool. I’m not quite sure how I feel about it right now, but, as an extra layer I think it’s somewhat ideal in its goals at least. We’ll see how it works out, I’m looking forward to the next Pwnium when we’ve got NaCl built in. I’d also love to see Google add a 20,000 dollar bug bounty reward for NaCl sandbox bypasses like they’ve done for broker sandbox bypasses..

I probably missed a lot of stuff, most of what I’ve read was a while ago, but I’m hoping that we get more documentation soon.

Honestly, I just wish every company had the resources to do what Google does with security. NaCl was some experimental little project hack they made, and they are able to pour massive resources into fuzzing and all sorts of stuff. Really cool.