The Rapidly Evolving Exploitation Playground

Hey there, Vincenzo and Fermin here!

Next week we will be giving two talks at BlueHat. Vincenzo will be talking with Tim Kornau, Ralf Philipp Weinmann, and Thomas Dullien, about return-oriented programming and how to automate the creation of ROP payloads. Also, Fermin and Andrew Roths will be talking about EMET and how it can prevent the successful exploitation of vulnerabilities.

Since 2004, a lot of things have changed in the exploitation playground. The cat-and-mouse game between offensive and defensive researchers has brought us two important and game-changing mitigations: ASLR and DEP.

In fact, exploits targeting modern platforms and applications that support DEP and ASLR work by either leveraging weaknesses in ASLR (e.g., non randomized DLLs) or lack of DEP enforcement (e.g., JIT spaying).

Practically speaking, this means that exploits, most of the time, work as follows:

1) Find, in the process address space, a DLL that is not randomized.

2) Chain together some ROP gadgets taken from the DLL (we can consider a gadget to be a set of assembly instructions that performs a given task).

3) Disable/bypass DEP with the ROP shellcode.

4) Execute a standard (non-ROP) payload.

During our presentation, we will show you a toolkit that allows you to write a payload in a custom language that will be translated into an ROP shellcode.

Some of you might point out that most of the time an ROP payload is very tiny and therefore there might be no need for such a tool. Unfortunately, we have learned during the past few years that the exploitation playground evolves rapidly.

For example, in some mobile platforms, such as the iPhone OS, the third step of the workflow cannot be performed. Therefore, the entire payload has to consist of ROP gadgets. Furthermore, in order to defeat ASL, it is often necessary to write ROP egg-hunters to locate payload pieces in memory.

These two are common scenarios where a tool like ours can be handy.

Some research has been done on ways to permanently stop ROP payloads and probably one day we will get there, but at the moment some of the best mitigations we have are tools like EMET (Enhanced Mitigation Experience Toolkit), which makes the above exploit workflow somewhat harder.

As you probably know, EMET 2.0 was released some weeks ago. It is a tool that enables security mitigation technologies to be deployed for arbitrary applications, helping to prevent vulnerabilities in those applications (especially line-of-business and third-party apps) from being exploited successfully. For more information, see the SRD blog.

EMET offers several mitigations, even for down-level operating systems (DEP, heap pages pre-allocations, SEHOP, mandatory ASLR, and EAT filtering).

Mandatory ASLR is one of the most interesting mitigations. Even when an application has opted in to ASLR, some of the DLLs being used could be placed on predictable mappings. This is because these DLLs were not compiled with the /DYNAMICBASE linker option. EMET, when mandatory ASLR is enabled, solves this problem by forcing the relocation of these DLLs.

Let’s take the metasploit module for the latest Adobe vulnerability as an example. This exploit relies on several gadgets located on a non-ASLR-aware module, icucnv36.dll.

The first ROP gadget used places the stack at a controlled place. This can be done because the attacker can reuse these lines of assembly from the non-ASLR module.

0:000> u 0x4a80cb38 L3


4a80cb38 81c594070000 add ebp,794h

4a80cb3e c9 leave

4a80cb3f c3 ret


When EMET is in place and Mandatory ASLR is enabled, this DLL will get relocated to a random place. The exploit will try to jump to 0x4a80cb38 but, since the DLL was relocated, the change of ESP to a controlled place will fail.

0:001> u 0x4a80cb38 L3

4a80cb38 ?? ???

^ Memory access error in ‘u 0x4a80cb38 l3’


Even the author of the metasploit module for this vulnerability suggests installing EMET so it will be harder to successfully exploit this vulnerability.

Clearly EMET is not the definitive answer, but what we have now is a slightly more intricate workflow for exploits development:

1) Find a memory leak or another similar weakness, as shown at Pwn2Own 2010, which allows us to find the base address of a DLL.

2) Chain together some ROP gadgets taken from the DLL (we can consider a gadget a set of assembly instructions that perform a given task).

3) Disable/bypass DEP with the ROP shellcode.

4) Execute a standard (non-ROP) payload.

This workflow clearly requires significant more work on the attacker’s side in order to write reliable exploits.

At the end of the day, EMET and our tool are yet more proof that the game is evolving fast! So stay tuned and come watch our ROP talk and Fermin and Andrew’s EMET talk.

– Vincenzo Iozzo and Fermin J. Serna