Don't like this style? Click here to change it! blue.css
LOGIN:
Welcome .... Click here to logout
Intro to the heap
We will dive into heap exploits.
There are many heap primitives that
create write-what-where gadgets. So this will be a more painful way of
achieving what your printf vulnerabilities do quickly. The good news is that
these heap exploits are often achievable by clever manipulation of a program's
state. This is the place where you start to make real zero-days using the
insights from older and simpler attacks.
I don't know how far we'll make it and I'm not a great heap expert, so I ask
your patience up front. We'll go through this together. Here are 13 heap
exploits I'd like to talk about:
House of Force
Fastbin Dup
Unsafe Unlink
Safe Unlink
Unsorted bin attack
Tcache Dup
House of Orange
House of Rabbit
House of Spirit
House of Lore
House of Einherjar
Poison Null Byte
House of Corrosion
At the moment I write this, I have personally done 5-6 of them in a live CTF.
So I'm going to be just barely ahead of you in aiming at all 13. It will challenge
our mental models of the professor/student relationship from here on out.
GLIBC versions
There is a timeline of glibc versions and when protections
are made against these vulnerabilities. The result is an
ever more complex playing field for heap vulnerabilities.
Protections are introduced and new vulnerabilities are created
for the new contexts. It's a dogfight. As we go pay attention to which versions
of glibc prevent which exploits.
The Basics
Let's do this first lecture just allocating some memory and visualizing what is going on under the hood.
We won't be exploiting anything today per say, just building mental models and learning and playing with pwndbg.
Compile this program and run it, enter a few characters and observe the addresses and their gaps.
GDB cheatsheet:
break *address or just b *main
start
step or s
next or n to step over
continue or c to go until next break
disass main
vis to visualize the heap
Now let's run it in our new tool gdb a.out then do start.
Let's step through until malloc then n (next) to skip that malloc step. Now do vis
We will see the heap for the first time. It has the following basic structure:
There is a starting 8 bytes, then chunks, each chunk has a starting 8 bytes then user space.
Every chunk is either free or allocated. We want to get comfortable with the way these both look.
Let's step through this program and see where data is saved, how the top chunk behaves,
how free'd chunks look, etc.
This is step 1. There are a ton of variations on how malloc makes it's choices for where your memory should live.
Basic Structure
When you first call malloc a "heap" is mmap'ed into existence. GLIBC holds the data about that new segment in
the main_arena (there can be many arenas). The arena is just a struct that manages heaps and bins.
Inside the big old heap segment live "chunks". Chunks contain the user data and some meta-data.
Chunks come in two states, in_use or freed.
Free'd chunks use up some internal quadwords for recycling of the space.
