Spread the love

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 )

Block 1
   mov	ebx,0x01 # fd = sysout
   leave
   ret
Block 2
	mov	ecx,msg # Some msg (e.g. Hello World)
	mov	edx,len # len of msg
	leave
	ret
Block 3
	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.

Related Posts: