More On Sandboxing
Alan: So things like “sandboxing” are designed to prevent unforeseen vulnerabilities from being transformed into large exploits.
Dino: Yes, as the name suggests, “sandboxing” is meant to contain the spill in the event of a compromise. Sandboxes don’t actually prevent exploits, however. They more prevent those exploits from taking other actions on the system. For example, Google’s Chrome has a very restrictive sandbox for Web rendering processes. And while this won’t prevent an exploit from executing arbitrary code, it will prevent that executing code from harming your system.
Alan: You've really been able to adapt your knowledge from PowerPC era to the Intel-Mac era. With the upcoming Snow Leopard, Apple will be implementing features such as ASLR, code signing for kernel extensions, full NX bit support, and sandboxing for many of the main applications. These are all features currently supported by Vista. How is this going to help secure the Mac? How does "sandboxing" really work when Chrome's first exploit allowed remote applications to be launched from Java, and IE8 was recently exploited at this year's CanSecWest?
Dino: I haven't looked at Snow Leopard yet due to the pre-release NDA, but I am glad to hear that they will be implementing those features.
Alan: You know actually, as you were saying that, I just realized that I don’t think it’s actually 100% confirmed yet. It’s really just the blogsphere right now. But let’s assume that this is what Snow Leopard will add. How is that going to change things?
Dino: I hope their implementations are sound and I will definitely be buying and installing Snow Leopard on all of my systems from Day One. All of these security features hamper attacks at multiple stages. ASLR and NX make it much more difficult for an exploit to inject or re-purpose code in an application. The sandboxing limits the actions that an application can perform so that even if it does begin running attacker-supplied code, the actions that the attacker may perform will be constrained. Finally, kernel extension code signing prevents attackers from installing new software into the core of the operating system. Attackers often install rootkits into the kernel in order to conceal their attacks and maintain access to compromised systems.
There is a difference between operating system-level and browser-level sandboxing. Chrome is the only Web browser to implement browser-based sandboxing. This is a highly smart move on their part and the main reason that Chrome was not compromised at Pwn2Own this year. The limitation of Chrome's sandbox model, however, is that it cannot sandbox Web browser plugins such as Flash and Java. These plugins need full access to the system, so the sandboxing system used for Web content renderers cannot be used. The Web content rendering processes are highly limited and cannot touch the file system at all. Breaking out of the Chrome renderer process sandbox would be an impressive feat in itself.
