---
breadcrumbs:
- - /Home
  - Chromium
- - /Home/chromium-security
  - Chromium Security
page_name: binding-integrity
title: Binding Integrity
---

Binding Integrity Project

Motivation

One of the reasons that browsers are easier to compromise than other kinds of
client software is that they provide scripting capabilities to a potential
attacker. As such, many of the exploits we’ve seen begin with a JavaScript
program obtaining and manipulating a freed block of C++ memory. Although the
Chrome sandboxing architecture provides excellent protection in this situation,
we’d like to prevent JavaScript from getting freed blocks of memory in the first
place, so as to make the full exploitation of Chrome even harder than it already
is.

Approach

At the time a C++ object is created, we know the corresponding V8 type with
which it will be later wrapped for use by V8. We devise an unguessable (by the
attacker) representation for each type and put it into the C++ object when it is
constructed. We similarly zero out this information at destruction time.

At the time of a method callback into the C++ object, V8 happens to know the
type that is expected to be associated with it. It can then determine what type
representation should have been set into the block of memory at creation time,
and check that it is still valid. Free blocks will have zeros (or will have been
clobbered by heap freelists), and will fail the check. Mis-typed blocks will
have different values, and will fail the check. Blocks crafted by the attacker
won’t have valid values because the type information representation is
unguessable, and will fail the check. At this point the renderer can shoot
itself, rather than proceeding into C++ with corrupted memory.

But these method invocation calls are very hot code paths, and we don’t want to
introduce the overhead of another test and branch here.

As it turns out, the V8 wrapper objects contain reference pointers back to the
blocks of C++ memory, and these do a good job of keeping the memory alive. Once
wrapped, a block is unlikely to be freed. Hence, most of the cases involve
wrapping a block that is already free, and we get nearly the full benefit by
doing the check at wrapper creation time only, where performance is not
important.

Implementation

It is important that we do not bloat the size of the objects in order to hold
this type representation.

Many (but not all) objects wrapped by V8 inherit somewhere from a class called
ScriptWrappable, which is a single pointer wide. It holds a pointer to the C++
object’s wrapper when it is wrapped, or NULL otherwise. We can re-use the slot
that holds the the wrapper pointer (which would otherwise be NULL for an
unwrapped object) to hold the type information, because we only need the type
information for unwrapped objects. Masking in a 1 in the bottom bit (otherwise
unused due to aligned pointers) allows us to distinguish between the two cases.

Hence, for objects that are to be checked in this manner, they must inherit
somewhere from the ScriptWrappable class (which need not be a common base
class).

This implies that all objects that inherit from ScriptWrappable and have their
own .idl files will have to call

ScriptWrappable::init(this);

as part of their constructors. Passing “this” is necessary to select between N
overloaded versions of ScriptWrappable::init() based upon the type of the
object.

The implementations of the N overloaded versions of ScriptWrappable::init() are
automatically generated by the .idl compiler (CodeGeneratorV8.pm at present)
from the .idl files. The .idl files need not specify which objects are
scriptwrappable, as the compiler can deduce this from type inheritance via
partially specialized template tricks.

The unguessable nature of the type representation is achieved by relying on ASLR
to randomize the address of a per-type instance of an existing V8 data structure
called WrapperTypeInfo. The address of the WrapperTypeInfo structure for a given
type thus already provides what is required here.

Note that ScriptWrappable was originally invented to provide a performance
improvement. One additional benefit of this change is that making more objects
ScriptWrappable makes chrome faster.