Written by: cr01nk ([email protected])

Before you start reading this blog, i would like you to know that i like to be wrong because i believe that it is the only way i can correct myself. So if anything you feel is wrong, or is not addressed in its proper terms. Please leave comments below. Thanks

Recently i have been working on a paper that was presented at Blackhat DC 2010 by a Dion Blazakis, in which he demonstrated technique that could be used in bypassing ASLR and DEP in software that provide JIT based capabilities in itself. For example in all browsers that have capability to use either Flash code which have its own intermediate language which is compiled once the flash is loaded into browser.

JIT compiler works with loading intermediate language code into the IL compiler (in case of flash it is Flash.ocx) and then it would compile this to x86 based code in memory location with “r+x” permission on that paper. See Figure-1 shows the user level code that has been written by the developer and Figure-2 for what actually it turns out to be when JIT compiler has done optimization and all the other usual stuff that a compiler do.

It is clear from the above instructions JIT compiler modifies code but the logic remains the same. Coming back to what Dion Blazakis presented in his paper, he demonstrated that compiler would only do optimization when required, infact he demonstrated that if we do XOR many times (as shown in Figure-1) we could control the instruction that are generated by JIT compiler (see figure-2).

Figure-1 : User level code written in Action script

Figure-2: Previous Code that is been translated into x86 language

Thus on controlling the opcode, the paper makes a very interesting observation about the instruction and how to control them.

In this blog I would explain all the difficulties i have faced while making a stable exploitation of CVE-2010-0188 possible.

Before starting this, I got the CVE-2010-0188 code code from here go check it out. For those who dont know CVE-2010-0188 is Adobe Reader vuln. which is there in all versions of adobe reader < 9.3.0 . Now i am sure that you might have checked this code out, it is written for Windows XP2. After a small binary analysis on this vuln. i would continue with its exploitation difficulties in Adobe acrobat 9.3.0 which is both DEP and ASLR aware on windows 7.

JIt code debugging : We all love to know what happens when, but it is not easy to make this happen just as easy it sounds in JIT based debugging. I have made a script on Immunity Debugger that hooks VirtualProtect, HeapCreate and VirtualAlloc functions with all the variables and output logged once this file is loaded into any process. This method seems to be most logical implementation method of creating a process to compile as well as change the permission to “r+x” on the runtime (for more details look up MSDN for these functions). But this theory was broken or i might have messed up with the implementation but I could not get any source which could explain the internals of JIT (if you know some let me know). See Figure-3 for hooked results of VirtualProtect while loading the process.

Figure-3: VirtualProtect Hooked, It prints VirtualAlloc but it is actually VirtualAlloc

Figure-4: Jit Spraying in Acrobat Reader

Making Adobe Flash Embedd and run as soon as the PDF is opened in PDF reader. Problem is solved by this blog and with a little help with Adobe Supplement ISO32000 reference found on Adobe Acrobat SDK.

Finally after doing all this i was able to write a stable JIT spraying on Adobe Reader. There are lots of shellcode available for exploiting JIT based exploit for example have a look at this one.

The point that i want to make here is that now every other software comes with some level of JIT based code support. Some examples of intermediate languages are Java, Actionscript and .Net to name a few.