isolation techniques improve, all
browsers will benefit.
Reducing the Window
Even after we have reduced the severity
of vulnerabilities, an exploit can still
cause users harm. For example, a bug
might let a malicious Web-site operator
circumvent the same-origin policy and
read information from other Web sites
(such as email). To reduce the danger
to users, Google Chrome aims to minimize the length of time that users run
unpatched versions of the browser.
We pursue this goal by automating our
quality assurance process and updating users with minimal disruption to
Automated Testing. After a vulnerability is discovered, the Google Chrome
team goes through a three-step process
before shipping a security patch to users:
The on-duty security sheriff triages 1.
the severity of the vulnerability and assigns an engineer to resolve the issue.
The engineer diagnoses the root- 2.
cause of the vulnerability and writes
a patch to fix the bug. Often security
patches are as simple as adding a missing bounds check, but other patches
can require more extensive surgery.
The patched binary goes through a 3.
quality assurance process to ensure that
the issue is actually fixed; and the patch
has not broken other functionality.
For a software system as complex
as a Web browser, step 3 is often a
bottleneck in responding to security
issues, because testing for regressions
requires ensuring that every browser
feature is functioning properly.
The Google Chrome team has put
significant effort into automating step
3 as much as possible. The team has
inherited more than 10,000 tests from
the WebKit project that ensure the
Web platform features are working
properly. These tests, along with thousands of other tests for browser-level
features, are run after every change to
the browser’s source code.
In addition to these regression tests,
browser builds are tested on one million Web sites in a virtual-machine farm
called ChromeBot. ChromeBot monitors the rendering of these sites for memory errors, crashes, and hangs. Running
a browser build through ChromeBot
often exposes subtle race conditions
and other low-probability events before
shipping the build to users.
Security Updates. Once a build has
been qualified for shipping to users,
the team is still faced with the challenge of updating users of older versions. In addition to the technical
challenge of shipping updated bits to
every user, the major challenge in an
effective update process is the end-user experience. If the update process is
too disruptive, users will defer installing updates and continue to use insecure versions.
Google Chrome uses a recently
open-sourced system called Omaha
to distribute updates.
6 Omaha automatically checks for software updates
every five hours. When a new update is
available, a fraction of clients are told
about it, based on a probability set
by the team. This probability lets the
team verify the quality of the release
before informing all clients. When
a client is informed of an update, it
downloads and installs the updated
binary in a parallel directory to the
current binary. The next time the user
runs the browser, the older version defers to the newer version.
This update process is similar to
that for Web applications. The user’s
experience is never disrupted, and the
user never has to wait for a progress
bar before using the browser. In practice, this approach has proven effective
for keeping users up to date. A recent
study of HTTP User-Agent headers
in Google’s anonymized logs reveals
how quickly users adopt patched versions of various browsers.
3 We reproduce their results in Figure 2. In these
measurements, Google Chrome’s
auto-update mechanism updates the
vast majority of its users in the short-est amount of time, as compared with
other browsers. (Internet Explorer is
not included in these results because
its minor version numbers are not reported in the User-Agent header.)
figure 2. Auto-update mechanisms in Google chrome.
Mozilla firefox 3.0.8
Google Chrome 1. 1.154.48
Release Dynamics summary
apple safari 3. 1. 1
apple safari 3. 2. 1
opera 9. 63
days since release
Credit: Duebendorfer and Frei.
Reducing frequency of exposure
Even with a hardened security architecture and a small window of vulnerability, users face risks from malicious
Web site operators. In some cases, the
browser discourages users from visiting known malicious Web sites by
warning users before rendering malicious content. Google Chrome and
other browsers have taken this approach, displaying warning pages if a
user tries to visit content that has been
reported to contain malware or phishing attempts. Google works with Stop-
Badware.org to maintain an up-to-date
database of such sites, which can be
used by all browsers.
One challenge with using such a database is protecting privacy. Users do
not want every URL they visit reported
to a centralized service. Instead, the
browser periodically downloads an efficient list of URL hashes without querying the service directly. To reduce the
space required, only 32-bit prefixes of
the 256-bit URL hashes are downloaded. This list is compared against a list
of malicious sites. If a match is found
for a prefix, the browser queries the service for the full 256-bit hashes for that
prefix to perform a full comparison.
Another challenge is minimizing
false positives. Google and StopBad-