The window of vulnerability. ˲ Browsers can reduce this window by improving the user experience for installing browser updates, thus minimizing the number of users running old versions that lack security patches.

The frequency of exposure. ˲ By warning users before they visit known malicious sites, browsers can reduce the frequency with which users interact with malicious content.

Each of these mitigations, on its own, improves security. Taken together, the benefits multiply and help keep users safe on today’s Web.

In this article, we discuss how our team used these techniques to improve security in Google Chrome. We hope our firsthand experience will shed light on key security issues relevant to all browser developers.

Reducing Vulnerability severity

In an ideal world, all software, including browsers, would be bug-free and lack exploitable vulnerabilities. Unfortunately, every large piece of software contains bugs. Given this reality, we can hope to reduce the severity of vulnerabilities by isolating a browser’s complex components and reducing their privileges.

Google Chrome incorporates several layers of defenses to protect the user from bugs, as shown in Figure 1. Web content itself is run within a JavaScript virtual machine, which acts as one form of a sandbox and protects different Web sites from each other. We use exploit barriers, such as address-space layout randomization, to make it more

difficult to exploit vulnerabilities in the JavaScript sandbox. We then use a sandbox at the operating-system level to limit the process itself from causing damage, even if exploits escape the earlier security mechanisms. Here, we discuss in more detail how these layers of defense are used.

Security Architecture. Google Chrome uses a modular architecture that places the complex rendering engine in a low-privilege sandbox, which we discuss in depth in a separate report. 1 Google Chrome has two major components that run in different operating-system processes: a high-privi-lege browser kernel and a low-privilege rendering engine. The browser kernel acts with the user’s authority and is responsible for drawing the user interface, storing the cookie and history databases, and providing network access. The rendering engine acts on behalf of the Web principal and is not trusted to interact with the user’s file system. The rendering engine parses HTML, executes JavaScript, decodes images, paints to an off-screen buffer, and performs other tasks necessary for rendering Web pages.

To mitigate vulnerabilities in the rendering engine, Google Chrome runs rendering-engine processes inside a restrictive operating-system-lev-el sandbox (see Figure 1). The sandbox aims to prevent the rendering engine from interacting with other processes and the user’s operating system, except by exchanging messages with the browser kernel via an IPC channel. All HTTP traffic, rendered pages, and

 

figure 1. Layers of defense around Google chrome’s rendering engine.

os-level sandbox

os/runtime exploit barriers

os/runtime exploit barriers

Javascript sandbox

browser kernel (trusted)

Web Content (untrusted)

IPc channel

Browser Kernel Process

Rendering engine Process

user input events are exchanged via such messages.

To prevent the rendering engine from interacting with the operating system directly, our Windows implementation of the sandbox runs with a restricted Windows security token, a separate and invisible Windows desktop, and a restricted Windows job object. 12 These security mechanisms block access to any files, devices, and other resources on the user’s computer. Even if an attacker is able to exploit a vulnerability and run arbitrary code in the rendering engine, the sandbox will frustrate the attacker’s attempts to install malware on the user’s computer or to read sensitive files from the user’s hard drive. The attacker’s code could send messages to the browser kernel via the IPC channel, but we aim to keep this interface simple and restricted.

Getting existing code bases such as rendering engines to work fully within this type of sandbox sometimes presents engineering challenges. For example, the rendering engine typically loads font files directly from the system’s font directory, but our sandbox does not allow such file access. Fortunately, Windows maintains a system-wide memory cache of loaded fonts. We can thus load any desired fonts in the browser-kernel process, outside the sandbox, and the rendering-engine process is then able to access them from the cache.

There are a number of other techniques for sandboxing operating-system processes that we could have used in place of our current sandbox. For example, Internet Explorer 7 uses a “low rights” mode that aims to block unwanted writes to the file system. 4 Other techniques include system-call interposition (as seen recently in Xax2) or binary rewriting (as seen in Native Client14). Mac OS X has an operating system-provided sandbox, and Linux processes can be sandboxed using AppArmor and other techniques. For Windows, we chose our current sandbox because it is a mature technology that aims to provide both confidentiality and integrity for the user’s resources. As we port Google Chrome to other platforms such as Mac and Linux, we expect to use a number of different sandboxing techniques but keep the same security architecture.

Exploit Mitigation. Google Chrome