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