Skip to content ↓ | Skip to navigation ↓

Exploit mitigation techniques have come a long way. In the 90s, any stack overflow was trivial to exploit for arbitrary code execution but over time, the protections have expanded.

We now have DEP to prevent execution of user-writable data and ASLR to randomize the addresses space, making it harder to predict where a payload or a library would exist in memory. These protection tactics, of course, led to more creativity among exploit developers, including the completely brilliant idea of return-oriented-programming (ROP), in which an attack payload chains together small sequences of instructions already present in predictable locations.

This exploitation technique turns basic computer functionality completely on its head by using the stack pointer the way a CPU would normally use the instruction pointer. These short instruction sequences, referred to as ‘ROP gadgets,’ are chained together to undermine modern exploit prevention techniques.

This has become the standard approach for attacking hardened systems and has led to a plethora of technology dedicated to recognizing ROP exploitation and preventing system compromise. Microsoft’s EMET, while not perfect, is a great example of this.

The idea behind preventing ROP exploitation is to enforce control flow integrity (CFI) policies. Daniel Lehmann and Ahmad-Reza Sadeghi gave an excellent overview of these CFI policies in their Black Hat 2014 talk, ‘The Beast is in Your Memory: Return-Oriented Programming Attacks Against Modern Control-Flow Integrity Protection Techniques.’ As they explained, the most popular methods for CFI involve return instruction restrictions (i.e. you must return to code, which follows a CALL instruction) and behavioral analysis (i.e. there should not be too many short instruction sequences in a row as implemented in kbouncer and roppecker).

While these CFI policies go a long way towards recognizing unexpected execution flow, the research presented at Black Hat demonstrates that it is, in fact, possible for exploit developers to work around these exploit mitigations. Using kernel32.dll as an example, their research showed that it is possible to get enough gadgets for a Turing complete set of ROP instructions compliant with these main CFI policies.

Two techniques led to this achievement. First, locate all ROP gadgets that follow CALL instructions, and then introduce a ‘ROP NOP’ gadget to defeat the behavioral analysis. A ROP NOP gadget contains 20+ instructions and is inserted between every set of 7 short ROP to defeat the behavioral analysis. The trick here is that the long sequences must be carefully selected to avoid altering registers used in subsequent gadgets.

Lehmann and Sadeghi created tools to analyze binaries and locate appropriate gadgets. Based on the small size of kernel32.dll, and the fact that it is included in essentially all Windows applications, the researchers surmise that most any sufficiently complex codebase should contain a turing complete ROP gadget set.

As proof, they demonstrated an existing exploit being blocked by Microsoft’s EMET, and then used their rewritten exploit, which successfully spawned Windows Calculator (the ‘Hello World’ of exploit payloads). While this is not the first demonstration of EMET bypasses and certainly will not be the last, this research should not deter users from using tools like EMET, kbouncer, etc., as they do still raise the bar for exploit developers.

Fortunately, we have yet to start seeing EMET bypasses in the wild and Tripwire VERT encourages its use as a great free tool for hardening Windows based systems.




picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].

Header image courtesy of Shutterstock.