 |
|
project zeus |
|
 |
"You will not be informed of the meaning of Project Zeus until the time is right for you to know the meaning of Project Zeus."
|
|
 |
|
|
|
|
|
The Chrome Sandbox Part 1 of 3: Overview
|
|
|
Earlier this year, CanSecWest hosted the popular "Pwn2Own" contest, whereby contestants attempt to exploit vulnerabilities they have discovered in popular software packages. The contest has a strong focus on web browsers, and this year, it didn't disappoint: all of the major web browsers were successfully compromised, with the notable exception of Google's Chrome. I believe Chrome's survival was largely due to its integrated sandbox, which aims to isolate the browser from being able to perform any potentially adverse operations on the system upon which it is running. I have been working with Google for the last several months on Chrome, with one of my major charges being a security review of the sandbox and its related components. Therefore, with Google's blessing, I thought I might take some time here to discuss the basic sandbox architecture, the attack surface, and present a few examples of vulnerabilities I uncovered during my time working on it.
There is a fair bit of topic material to cover, and so I have decided to split up my this brain dump over three posts. This first post will discuss the basic Chrome architecture and process interaction. It is intended to be a high-level introduction to set the stage for the more technical discussion that will be presented in the follow-on posts. The second post will focus on the messaging facilities that Chrome processes use to communicate with each other. These communication failicities are fundamental to the Chrome sandbox's functionality, but more importantly expose an extensive attack surface for privilege escalations. The final post will detail the specifics of the Linux and Windows OS features used to sandbox renderer processes from the rest of the system.
Multi-process Architecture
Chrome adopts a multi-process architecture as part of Google's "principle of least privilege" security strategy. In essence, the sandbox attempts to isolate processes from accessing anything of value on the target system - including files, other processes, and IPC objects (with the exception of those used by Chrome itself). In order to understand Chrome's sandbox, it is important to be familiar with how work is partitioned among the various processes that are typically present during a browsing session. The diagram below illustrates Chrome's multi-process architecture.
Figure 1: Chrome Process Architecture
Note
Several other processes may potentially exist that have not been depicted, depending on the actions taking place in the browsing session. For example, an installer process may be spawned when Chrome extensions are downloaded. These auxiliary processes have been omitted from the diagram for simplicity. |
Browser Process - A single privileged browser process exists for the duration of a browsing session. The browser process is responsible for spawning other processes as needed, provisioning tasks to them, and performing privileged operations on behalf of processes that do not have the required system access to perform the operations themselves.
Renderer Process - A renderer process is spawned each time a new tab or window is opened, and is responsible for performing the parsing and rendering of the web page being viewed. This includes HTML parsing, JavaScript functionality, and image processing.
Plugin Process - Plugins are hosted inside their own private process and communicate with the renderer and browser processes. There is a single process for each different plugin, regardless of how many different embedded object instances there are of that plugin. Plugin processes actually run with full privileges by default (like the browser process does), although this will eventually change when certain compatibility issues are solved.
GPU Process - A single GPU process optionally exists to perform GPU-related tasks on behalf of renderer processes. The GPU process is not confined to a sandbox.
IPC Channels - The IPC Channels make up Chrome's messaging framework, which provides facilities for the various Chrome processes to interact with each other over local OS-specific transport mechanisms.
Attacking Chrome
It should be evident from the description above that finding flaws in some of the browser components have more severe security-related consequences than others, due to the privileges associated with the process performing the operations. The table below provides a basic breakdown of some of the major components of the browser exposed to attack and where that processing takes place.
| Component | Process |
| Network Protocol Parsing | Browser |
| Creating/Managing Tabs/Windows | Browser |
| Caching of Input Text | Browser |
| Spellchecking/Normalization | Browser |
| Clipboard Management | Browser |
| HTML Parsing/Rendering | Renderer |
| JavaScript Parsing | Renderer |
| Image Processing | Renderer |
| Plugins | Plugin |
| GPU Processing | GPU |
| IPC Message | [All] |
Of all the processes listed, only the renderers are sandboxed. Therefore, targeting exposed functionality that is performed by anything other than the renderer (such as network protocol parsing) can potentially yield bugs that result in remote access to the target system without any additional restrictions that the sandbox would usually impose. Having said that, the functions that the renderer performs encompass a large portion of the usual attack surface for a web browser, and so it is likely that most of the flaws uncovered in Chrome in the future will continue to be related to these components. Due to the restrictive nature of Chrome's sandbox, it would be necessary for an attacker to escalate their privileges using a second vulnerability after compromising a renderer to gain further access to the system. Therefore, privilege escalation vectors within Chrome are also a key focal point of any security audit. There are several primary attack surfaces for privilege escalation, which are as follows:
IPC Messaging - Parsing flaws within the messaging framework used for inter-process communication would provide an ideal way to gain privileges of one of the non-sandboxed processes. This area will be examined in depth in the next blog post.
Exposed Services - Each process participating within the Chrome browsing session exposes services to other processes via the aforementioned IPC channels. It is important to evaluate all of the exposed functions that can be called from the renderer for programming flaws or inadvertent security exposures that lead to sandbox bypasses. This attack surface will also be covered extensively in the next blog post.
Sandbox Weaknesses - When attacking any sandbox, it is necessary to be familiar with exactly what the sandbox protects against, and how effective it is at enforcing the various restrictions it is attempting to place on processes in isolation. The third blog post in this series will discuss the sandbox itself and how it is implemented on Linux and Windows. I will also give examples of flaws uncovered that I uncovered in both of the sandbox implementations
Shared Resources - It should be noted that there are several indirect forms of attacking the more privileged processes. Specifically, some of the Audio, Video, and Graphics data is supplied by a renderer process to a more privileged process (such as the GPU process) by placing that data in a shared memory buffer, and then notifying the more privileged process about it. Since some of the parsing of this data occurs in the more privileged processes, it is a potentially useful avenue for targeting parsing flaws to gain further access to the system. This avenue, although quite interesting, is not discussed further, and is left as an exercise to the reader.
- OS/External Software - Of course, an attacker could target flaws in the OS kernel or external software compoonents such as local services instead. These vectors are out of scope of this discussion and will not be considered further.
Conclusion
As you can see, there is a significant amount of material to cover. Tune in for my next two posts where I will dig in to the details of the sandbox a little further and present several flaws that I uncovered throughout the course of the review!Labels: Browsers, Chrome, Privilege Escalation, Sandbox, Vulnerabilities
|
|
|
|
It would be great if font would be bigger. It does not matter under RSS reader but in original form it's pain in the ass.
Very nice and looking forward to the next posts, but please make the font larger. I had to manually raise the font size in Firefox to be able to read it.
The font size looks fine in my browser, but I will make it larger in future..
It's like the wolf and the three little pigs. Why mess with the brick house when so many pigs live in straw houses?
Nice intro. Looking forward to the rest!