also makes vulnerabilities more difficult to exploit by using several barriers
recommended for Windows programs.
These include DEP (data execution prevention), ASLR (address space layout
randomization), SafeSEH (safe exception handlers), heap corruption detection, and stack overrun detection (GS).
These are available in recent versions
of Windows, and several browsers have
adopted them to thwart exploits.
These barriers make it more difficult for attackers to jump to their desired malicious code when trying to exploit a vulnerability. For example, DEP
uses hardware and operating-system
support to mark memory pages as NX
(non-executable). The CPU enforces
this on each instruction that it fetches,
generating a trap if the instruction belongs to an NX page. Stack pages can
be marked as NX, which can prevent
stack overflow attacks from running
malicious instructions placed in the
compromised stack region. DEP can be
used for other areas such as heaps and
the environment block as well.
GS is a compiler option that inserts
a special canary value into each stack
call between the current top of the
stack and the last return address. Before each return instruction, the compiler inserts a check for the correct canary value. Since many stack-overflow
attacks attempt to overwrite the return
address, they also likely overwrite the
canary value. The attacker cannot easily guess the canary value, so the inserted check will usually catch the attack
and terminate the process.
Sophisticated attacks may try to by-pass DEP and GS barriers using known
values at predictable addresses in the
memory space of all processes. ASLR,
which is available in Windows Vista
and Windows 7, combats this by randomizing the location of key system
components that are mapped into
nearly every process.
When used properly, these mechanisms can help prevent attackers from
running arbitrary code, even if they
can exploit vulnerabilities. We recommend that all browsers (and, in fact,
all programs) adopt these mitigations
because they can be applied without
major architectural changes.
Compatibility Challenges. One of the
major challenges for implementing
a security architecture with defense
every large piece
Given this reality,
we can hope to
reduce the severity
by isolating a
in-depth is maintaining compatibility
with existing Web content. People are
unlikely to use a browser that is incompatible with their favorite Web sites, negating whatever security benefit might
have been obtained by breaking compatibility. For example, Google Chrome
must support plug-ins such as Flash
Player and Silverlight so users can visit
popular Web sites such as YouTube.
These plug-ins are not designed to run
in a sandbox, however, and they expect
direct access to the underlying operating system. This allows them to implement features such as full-screen video
chat with access to the entire screen,
the user’s Web cam, and microphone.
Google Chrome does not currently run
these plug-ins in a sandbox, instead
relying on their respective vendors to
maintain their own security.
Compatibility challenges also exist
for using the browser’s architecture to
enforce the same-origin policy, which
isolates Web sites from each other.
Google Chrome generally places pages from different Web sites into different rendering-engine processes,
it can be difficult to do this in all cases,
as is necessary for security. For example, some frames may need to be rendered in different processes from their
need to be made between pages from
different origins. For now, Google
Chrome sometimes places pages from
different origins in the same process.
Also, each rendering-engine process
has access to all of the user’s cookies, because a page from one origin
can request images, scripts, and other
objects from different origins, each of
which may have associated cookies. As
a result, we do not yet rely on Google
Chrome’s architecture to enforce the
Recently, some researchers have
experimented with browsers (such
as OP7 and Gazelle13) that do attempt
to enforce the same-origin policy by
separating different origins into different processes and mediating their
interaction. This is an exciting area of
research, but challenges remain that
need to be overcome before these designs are sufficiently compatible with
the Web. For example, supporting existing plug-ins and communication
between pages is not always straightforward in these proposals. As these