Adobe PDF Return Oriented Exploit
The news just keeps getting worse for Adobe. After releasing an out-of-band patch for their other 0-day PDF exploit used to jailbreak the iPhone, the people at McAfee discovered malware in the wild exploiting another 0-day PDF exploit. Apparently this exploit takes advantage of your typical buffer overflow exploit (come on Adobe!) but the way it’s exploited is very interesting; it uses return oriented programming.
Return Oriented Exploitation
This is a very clever exploitation technique that subverts all known countermeasures to mitigate exploitation of overflows such as ASLR, compiler stack protection, and non-executable memory regions. It essentially works by using the prior code on the stack as well as well known (not everything is randomized) locations of library routines as building blocks for executing code. The key is that every “building block” must end in a RET instruction, hence the name return oriented.
Suppose after scanning memory we found the following useful “building blocks” (Commented for understanding )
mov ebx,0x01 # fd = sysout leave ret
mov ecx,msg # Some msg (e.g. Hello World) mov edx,len # len of msg leave ret
mov eax,0x04 #write syscall int 0x80 leave ret
You could construct each of these “building blocks” in reverse order such that the RET address jumped from one block to the next, in essence executing the following code:
mov ebx,0x01 # fd = sysout mov ecx,msg # Some msg (e.g. Hello World) mov edx,len # len of msg mov eax,0x04 #write syscall int 0x80
You’re exploit would print “Hello World” to standard out at this point (not much of an exploit!).
These types of exploitation techniques seem very hard to defend against. I’d be interested to see what mitigation techniques they’ll come up for to defend this! For more info on Return Oriented Exploitation, check out an excellent presentation at trailofbits.com.
Comments are closed.