Archive for the ‘Exploit development’ Category

ROPC — Turing complete ROP compiler (part 3, implementation)

31/07/2014 2 comments


This is the third (and last) post in a series (first post here, second here) about ROPC, describing implementation of its features like tables, conditional jumps, recursive calls, etc. Please familiarize yourself with the two first posts, otherwise this one might be hard to follow.

Read more…

ROPC — Turing complete ROP compiler (part 2, language)

01/01/2014 2 comments

This is the second post in a series (first post here) describing ROPC. Programs accepted by the compiler are written in ROPL (Return Oriented Programming Language). ROP programs are usually used as stage 0 payloads. They compute addresses, change memory protections, call few OS APIs. For this reason, language expressing them doesn’t have to be complex.

Read more…

ROPC — Turing complete ROP compiler (part 1)

13/12/2013 12 comments


This is a long overdue post describing ROPC (Return Oriented Programming Compiler, available here: with its own “higher level” language and features like conditional jumps, loops, functions (even recursive ones), tables, etc.. ROPC was released in 2012. Since then, Christian Heitman made a fork [0] capable of compiling ROP programs expressed in C (!).

Read more…

Leaking information using timing attacks on hash tables, part 2

14/08/2012 2 comments

This is the second part of Leaking information using timing attacks on hash tables, discussing implementation details of the leak. Read the first part for a high level overview.

Read more…

Leaking information with timing attacks on hashtables, part 1

07/08/2012 10 comments

Timing attacks [1] are an important subclass of side channel attacks used to reveal cryptographic secrets, basing only on time needed by targeted devices or applications to perform specific computations.

It turns out these attacks can be applied in a more prosaic context — instead of encryption keys, they can help us leak pointers to objects on the heap or, if we are lucky, in .code/.data sections of targeted application. Leaking a pointer with fixed RVA reveals the imagebase, so ASLR becomes ineffective (ROP). Leaking a heap pointer makes expoitation of WRITE-ANYWHERE bugs easier, so in both cases it’s a win :).

This post provides a high-level description of a POC implementation of a timing attack on hashtable used in Firefox (tested on v4, v13, v14). POC is quite fast (takes few secs) and leaks a heap pointer to a JS object. A detailed explanation will be provided in a different post (part 2).

Read more…

Exploiting CVE-2011-2371 (FF reduceRight) without non-ASLR modules

22/02/2012 2 comments

CVE-2011-2371 (found by Chris Rohlf and Yan Ivnitskiy) is a bug in Firefox versions <= 4.0.1. It has an interesting property of being a code-exec and an info-leak bug at the same time. Unfortunately, all public exploits targeting this vulnerability rely on non-ASLR modules (like those present in Java).

In this post I’ll show how to exploit this vulnerability on Firefox 4.0.1/Window 7, by leaking imagebase of one of Firefox’s modules, thus circumventing ASLR without any additional dependencies.

Read more…

Universal ROP shellcode for OS X x64

23/07/2011 12 comments

One of the hurdles one will encounter during OS X exploitation is ASLR/DEP combination for 64-bit processes (32bit don’t have DEP [1]). When implemented correctly, it’s an effective mitigation, which can be circumvented only with an info leak. (Un)fortunately, OS X versions up to recent Lion (10.7) offer only incomplete ASLR which still allows attackers to succeed in their efforts to execute arbitrary code. One of the problems (among others) is dyld (dynamic loader) image being located at the same address in every process. This makes ROP possible — by controlling the stack, we can reuse snippets of code from dyld and, in effect, execute arbitrary code.

The only public ROP dyld shellcode for OS X was presented in [1]. Charlie Miller’s version works under the assumption that that rax/rdi have specific values. Due to x64 calling convention [2] it is very probable that this precondition is met. Nevertheless it would be useful to create a shellcode with weaker assumptions — that’s exactly what this post is about. We will create a generic ROP shellcode, similiar to sayonara, but for OS X :).

Read more…