Playing In The Sandbox
Alan: So, if an attacker were to compromise the rendering engine, he still would not be able to circumvent the restriction on writing files because Windows treats the renderer process with restricted access? Unless the attacker could simultaneously crack Windows file security, the threat would be eliminated?
Collin: The threat would be contained within the renderer process, which is a big improvement from having your machine completely pwned. However, the rendering engine is responsible for enforcing origin isolation. If it's compromised, the attacker can try to interfere with that isolation and hijack your sessions with other sites.
Alan: What do you mean by origin isolation?
Collin: With a few exceptions for things like script libraries, Web applications are only supposed to read data from the "origin" server that served up the application. This isolation is what prevents attacker.com from reading your Gmail, for example. However, a single instance of the rendering engine can often end up in charge of handling data from multiple origins, so Chromium lets the rendering engine handle the enforcement of this policy.
Alan: What happens when you run Chrome with the “safe plug-ins”
Adam: The --safe-plugins option is an experimental feature that causes Google Chrome to run plug-ins (like Flash Player and Windows Media Player) inside the sandbox. Sandboxing plug-ins helps mitigate vulnerabilities in these plug-ins, but might break some of their functionality. For example, a sandboxed plug-in won't be able to auto-update itself.
Alan: In order to take advantage of the most security features, users need to be running NTFS and Windows Vista. What specifically about FAT32 and Windows XP make them more vulnerable to attack?
Adam: The FAT32 file system doesn't have access control lists, so Windows doesn't prevent the rendering engine from accessing FAT32 files. In practice, most Windows users use the NTFS file system, which has been the default since Windows 2000. There are some minor differences in the sandbox on Windows XP and Windows Vista, but these differences are largely theoretical.
Alan: How does Chromium maintain compatibility with Web-based file uploads? What are the instances where the sandbox between the rendering engine and the browser kernel is broken?
Adam: To secure file uploads, we borrowed a trick from the capability literature. The browser kernel displays the file picker dialog and keeps track of which files the user has picked. Later, when the rendering engine asks to upload a file, the browser kernel checks to make sure the user actually picked that file for upload. Without this check, a compromised rendering engine would be able to read arbitrary files by uploading them to attacker.com.
Alan: Why limit the design to a rendering engine and a browser kernel? Why not break Chrome into even more sandboxes so that the cookie database and window management and are all sandboxed from each other, along the lines of Opus Palladium?
Collin: Breaking up the browser into separate sandboxed components is not free--it imposes performance costs and can be hard for developers to maintain. Furthermore, a sandboxed component is as powerful as the interface you provide it, so you have to design this interface carefully to make sure it can't be abused. Despite these obstacles, I suspect we'll see more fine-grained sandboxing in the future, and I'm happy that researchers are trying it out.
