The Security Architecture of the Chromium Browser Adam Barth∗ Collin Jackson∗ UC Berkeley Stanford University Charles Reis∗ Google Chrome Team University of Washington Google Inc. ABSTRACT There have been a number of research proposals for mod- Most current web browsers employ a monolithic architec- ular browser architectures [8, 27, 5, 7] that contain multiple ture that combines \the user" and \the web" into a single protection domains. Like Chromium's architecture, these protection domain. An attacker who exploits an arbitrary proposals aim to provide security against an attacker who code execution vulnerability in such a browser can steal sen- can exploit an unpatched vulnerability. Unlike Chromium's sitive files or install malware. In this paper, we present the architecture, these proposals trade off compatibility with ex- security architecture of Chromium, the open-source browser isting web sites to provide architectural isolation between upon which Google Chrome is built. Chromium has two web sites or even individual pages. The browser's secu- modules in separate protection domains: a browser kernel, rity policy, known as the \same-origin policy," is complex which interacts with the operating system, and a rendering and can make such fine-grained isolation difficult to achieve engine, which runs with restricted privileges in a sandbox. without disrupting existing sites. Users, however, demand This architecture helps mitigate high-severity attacks with- compatibility because a web browser is only as useful as the out sacrificing compatibility with existing web sites. We sites that it can render. To be successful, a modular browser define a threat model for browser exploits and evaluate how architecture must support the entire web platform in addi- the architecture would have mitigated past vulnerabilities. tion to improving security. Chromium's architecture allocates the various components of a modern browser between the browser kernel and the 1. INTRODUCTION rendering engine, balancing security, compatibility, and per- In the past several years, the web has evolved to be- formance. The architecture allocates high-risk components, come a viable platform for applications. However, most such as the HTML parser, the JavaScript virtual machine, web browsers still use the original monolithic architecture and the Document Object Model (DOM), to its sandboxed introduced by NCSA Mosaic in 1993. A monolithic browser rendering engine. These components are complex and his- architecture has many limitations for web applications with torically have been the source of security vulnerabilities. substantial client-side code. For example, a crash caused Running these components in a sandbox helps reduce the by one web application takes down the user's entire web severity of unpatched vulnerabilities in their implementa- experience instead of just the web application that misbe- tion. The browser kernel is responsible for managing persis- haved [21]. From a security point of view, monolithic web tent resources, such as cookies and the password database, browsers run in a single protection domain, allowing an at- and for interacting with the operating system to receive user tacker who can exploit an unpatched vulnerability to com- input, draw to the screen, and access the network. The ar- promise the entire browser instance and often run arbitrary chitecture is based on two design decisions: code on the user's machine with the user's privileges. 1. The architecture must be compatible with the existing In this paper, we present and evaluate the security ar- web. Specifically, the security restrictions imposed by chitecture of Chromium, the open-source web browser upon the architecture should be transparent to web sites. which Google Chrome is built. Chromium uses a modular This design decision greatly limits the landscape of architecture, akin to privilege separation in SSHD [18]. The possible architectures but is essential in order for Chro- browser kernel module acts on behalf of the user, while the mium to be useful as a web browser. For example, the rendering engine module acts on behalf of \the web." These architecture must support uploading files to web sites modules run in separate protection domains, enforced by a in order to be compatible with web-based email sites sandbox that reduces the privileges of the rendering engine. that let users add attachments to emails. Even if an attacker can exploit an unpatched vulnerability in the rendering engine, obtaining the privileges of the entire 2. The architecture treats the rendering engine as a black rendering engine, the sandbox helps prevent the attacker box that takes unparsed HTML as input and produces from reading or writing the user's file system because the rendered bitmaps as output (see Figure 1). In par- web principal does not have that privilege. ticular, the architecture relies on the rendering engine alone to implement the same-origin policy. This design ∗The authors conducted this work while employed by Google. decision reduces the complexity of the browser kernel's security monitor because the browser kernel need only enforce coarse-grained security restrictions. For exam- . ple, the browser kernel grants the ability to upload a 1 file to an entire instance of the rendering engine, even Sandbox when that privilege is only needed by a single security origin. Rendering The architecture does not prevent an attacker who compro- Engine mises the rendering engine from attacking other web sites (for example, by reading their cookies). Instead, the archi- tecture aims to prevent an attacker from reading or writing the user's file system, helping protect the user from a drive- by malware installation. To evaluate the security of Chromium's architecture, we examine the disclosed browser vulnerabilities in Internet Ex- IPC plorer, Firefox, and Safari from the preceding year. For each vulnerability, we determine which module would have been affected by the vulnerability, had the vulnerability been present in Chromium. We find that 67:4% (87 of 129) of the HTML, JS, ... Rendered Bitmap vulnerabilities would have occurred in the rendering engine, suggesting that the rendering engine accounts for a signifi- Browser Kernel cant fraction of the browser's complexity. Not all rendering engine vulnerabilities would have been mitigated by Chromium's architecture. Chromium's archi- Figure 1: The browser kernel treats the rendering tecture is designed to mitigate the most severe vulnerabili- engine as a black box that parses web content and ties, namely those vulnerabilities that let an attacker execute emits bitmaps of the rendered document. arbitrary code. If an attacker exploits such a vulnerability in the rendering engine, Chromium's architecture aims to re- strict the attacker to using the browser kernel interface. We find that 38 of the 87 rendering engine vulnerabilities al- Organization. Section 2 defines a threat model for browser lowed an attacker to execute arbitrary code and would have exploits. Section 3 details Chromium's architecture. Sec- been mitigated by Chromium's architecture. These account tion 4 describes the sandbox used to confine the rendering for 70:4% (38 of 54) of all disclosed vulnerabilities that allow engine. Section 5 explains the browser kernel API used by arbitrary code execution. the sandboxed rendering engine. Section 6 evaluates the se- To evaluate the security benefits of sandboxing additional curity properties of the architecture. Section 7 compares browser components, we examined the arbitrary code execu- Chromium's architecture with other browser architectures. tion vulnerabilities that would have occurred in the browser Section 8 concludes. kernel. We find that 72:7% (8 of 11) of the vulnerabilities result from insufficient validation of system calls and would 2. THREAT MODEL not have been mitigated by additional sandboxing. For ex- In order to characterize the security properties of Chro- ample, one such vulnerability involved the browser improp- mium's architecture, we define a threat model by enumerat- erly escaping a parameter to ShellExecute when handling ing the attacker's abilities and goals. The security architec- external protocols. Although counting vulnerabilities is an ture seeks to prevent an attacker with these abilities from imperfect security metric [24], these observations lead us to reaching these goals. We can use this threat model to eval- believe that Chromium's architecture suitably divides the uate how effectively Chromium's architecture protects users various browser components between the browser kernel and from attack. the rendering engine. By separating the browser into two protection domains, Attacker Abilities. We consider an attacker who knows an one representing the user and another representing the web, unpatched security vulnerability in the user's browser and Chromium's security architecture mitigates approximately is able to convince the user's browser to render malicious 70% of critical browser vulnerabilities that let an attacker content. Typically, these abilities are sufficient to compro- execute arbitrary code. The remaining vulnerabilities are mise the user's machine [20]. More specifically, we assume difficult to mitigate with additional sandboxing, leading us the attacker has the following abilities: to conclude that the architecture extracts most of the secu- 1. The attacker owns a domain name, say attacker.com, rity benefits of sandboxing while maintaining performance that has not yet been added to the browser's malware and compatibility