Originally Posted by bannedit
Recently, I spent about a week and a half working on the latest 0-day Flash vulnerability. I released a working exploit on March 22nd 2011. The original exploit was just an attempt to get something working out the door for all of our users. The first attempt left a lot to be desired. To understand the crux of this vulnerability and what needed to be done to improve the first attempt at exploiting it I had to dig in deep into ActionScript.
ActionScript is a language which is embedded into an SWF file in the form of a bytecode stream. The embedded bytecode stream is handled by the ActionScript Virtual Machine (AVM) which is tasked with verifying the bytecode and generating native code. This process is commonly referred to as JIT (Just In Time) compiling.
The cause of this specific vulnerability is due to a one byte alteration (fuzzing) within an original well formed bytecode stream found in a file called addLabels.swf. The bytecode passes the verification process and the native code is generated and placed in VirtualAlloc()'d executable memory. The specific results of this code executing is that uninitialized memory is referenced.
The solution was to preform the heapspray within a SWF file which loads the trigger SWF. Using HeapLib.as from Roee Hay I was able to get some basic heapspraying accomplished. This is a lot more reliable because it is using the same Heap management routines Flash uses to allocate memory. A copy of the ActionScript source code I used for this exploit can be found in the exploit.as source file.
Now that I have reliable control over the unintialized memory. Whats the next task? The next task is simply constructing the memory in such a way that the call eax instruction in the JIT code executes my shellcode. This was easily done using the good old Skylined technique of using an address which doubles as a nop instruction (0x0d0d0d0d ftw!).
The next major hurdle I had to over come was now that I have execution control what do I execute? While testing I was using a hardcoded payload within the ActionScript which simply executed calc.exe. This just was not going to cut it. A few initial options came to mind, I could hardcode a meterpreter payload. This was not very dynamic at all and so I had to come up with something else. The next option I thought of was using an egghunter payload to find shellcode I could inject in some other fashion. This would work but really limited things to a lot of payload specifics for example if the hardcoded egghunter payload was for a different architecture than the targeted machine things would blow up and break. That would be pretty tragic since all the conditions for getting a shell would be in place but everything breaks due to the dependencies of a hardcoded payload.
Finally, I came to conclusion I needed to find a way to dynamically read a payload using ActionScript. Now I can simply make a HTTP request for a text file and read in the ASCII hexadecimal representation of the payload. After decoding the payload it can be applied to the heapspray code and now we have dynamic payloads in memory. W00t!
Thats the entire process it took to create a reliable exploit for this vulnerability. I hope you enjoy all the sessions =).