Post Memory Corruption

Memory Analysis

Jonathan Brossard

CEO – Toucan System

[email protected] toucan-system.com

Who am I ?

-Security Research Engineer at Toucan System

-Speaker at Blackhat, Defcon, HITB, H2HC, Kiwicon, Ruxcon.

-Organiser of the Hackito Ergo Sum conference (Paris).

-I'm the guy who comes to CCC with 90+ slides...

I don't reverse plain text

Agenda

A few basics

Being environment aware

PMCMA Design

Extending Pmcma

•Stack desynchronization

Tool available at http://www.pmcma.org

We got 10k downloads+ in 2

less than months...

…and every email we get is questioning exploitation of remote stack overflows instead of invalid memory writes... ;(

What's pmcma ?

It's a debugger, for Linux (maybe one day *NIX) ptrace() based.

Pmcma allows to find and test exploitation scenarios.

Pmcma's output is a roadmap to exploitation, not exploit code.

Tells you if a given bug triggering an invalid memory access is a vulnerability, if it is exploitable with the state of the art, and how to exploit it.

Coz you asked for it...

Remote stack overflow automated exploitation

NX/SSP (stack cookies)/ASLR/PIE/STATIC

GOT/Ascii Armoring...

=> No problem, easy cheesy : can be done with static analysis (of the libc/binary) only.

Remote stack overflow automated exploitation

SSP :

cookies can be bruteforced remotely (cf Ben Hawks @ Ruxcon 2006).

Remote stack overflow automated exploitation

FORTIFY :

-Doesn't apply all the time.

-Fails silently (this is bad !!)

-Is consistent under Linux (but not Apple...)

Remote stack overflow automated exploitation

PIE :

-The bug new thing (every deamon compiled with PIE under ubuntu 10.10)

-No public exploits (untill today ;)

-We can bruteforce the saved EIP, then get back to ret2plt or ROP.

DEMO

Now, let's move to the real

thing...

A FEW BASICS

Seriously, can we skip this section ?

How do applications crash ?

*Stack corruptions -> stack overflows, usually now detected because of SSP | studied a LOT

*Signal 6 -> assert(),abort(): unexpected execution paths (assert() in particular), heap corruptions

*Segfault (Signal 11) -> Invalid memory access

How do applications crash ?

*Stack corruptions -> stack overflows, usually now detected because of SSP | studied a LOT

*Signal 6 -> assert(),abort(): unexpected execution paths (assert() in particular), heap corruptions

*Segfault (Signal 11) -> Invalid memory access

Invalid memory access

-trying to read a page not readable. often not mapped at all.

-trying to write to a page not writable. often not mapped at all.

-trying to execute a page not executable. often not mapped at all.

Why do they happen ?

Because of any kind of miscomputation, really :

-integer overflows in loop counters or destination registers when copying/initializing data, casting errors when extending registers or

-uninitialised memory, dangling pointers

-variable misuse

-heap overflows (when inadvertently overwriting a function ptr)

-missing format strings

-overflows in heap, .data, .bss, or any other writable section (including shared libraries).

-stack overflows when no stack cookies are present...

Exploiting invalid memory

reads ?

-usually plain not exploitable

-won't allow us to modify the memory of the mapping directly

-in theory : we could perform a user controled read, to trigger a second (better) bug.

Invalid memory writes

Eg :

CVE-2011-1824 (Opera)

mov DWORD PTR [ebx+edx*1],eax

How to...

To exploit invalid writes, we need to find ways to transform an arbitray write into an arbitrary exec.

The most obvious targets are function

pointers.

Exploiting invalid memory

writes : scenario

-Target a known function pointer (typically : .dtors, GOT entry...).

Can be prevented at compile time : no

.dtors, static GOT...

-Target function pointers in the whole binary ?

-Overwrite a given location to trigger an other bug (eg : stack overflow)

Being environment aware

Problems to take into account

-Kernel : ASLR ? NX ?

-Compilation/linking : RELRO (partial/full) ? no .dtors section ? SSP ?

FORTIFY_SOURCE ?

=> Pmcma needs to mesure/detect those features

ASLR

Major problem when chosing an exploitation strategy.

ASLR : not perfect

-Prelinking (default on Fedora) breaks ASLR

-All kernels don't have the same randomization strength.

-Non PIE binaries

=> Truth is : we need better tools to test it !

Testing ASLR

-Run a binary X times (say X=100) -Stop execution after loading

-Record mappings.

=> Compare mappings, deduce randomization

DEMO : being environment aware

PMCMA DESIGN

GOALS

-We want to test overwriting different memory locations inside a process and see if they have an influence over the flow of execution

-We want to scale to big applications (web browsers, network deamons...)

-We want a decent execution time