Introducing GOT and exploiting the heap | Exploit excercises

After doing heap0 from Protostar, which was a very easy overflow, I went into heap1.

This one, although not very difficult either, required you to have some sort of knowledge about how GOT ( Global Offset Table ) works. So I thought I could do my own explanation, just to make sure I understood everything. And also to share my notes with the internet :)

~~ The excercise ~~

 

Heap1 - Link

This structure kinda reminded me of the double free technique, but only by structre, because after reading the code a bit you can see that it's not going to employ that technique. But I think it's a good thing to know.

Anyhow, you can see that the exploit is going to consist on overflowing argv[1], that's the most obvious way and the one I used. However, there are also a couple things I still don't understand.

1. What's that declared *i3 exactly doing in there?

2. Why is the program declaring a priotiy?

I know that I don't have to make sense of everything of a program I try to exploit, but this was an excercise, so I am really not sure ¯\_(ツ)_/¯

 ~~ How is the GOT involved in this? ~~

Honestly, I didn't even know you could use the GOT table to exploit the heap, I found the idea around when looking for ways to exploit the heap with "code flow hijacking".

Now this article did an amazing job at teaching how the GOT and PLT worked. After going through it ( and rereading 1099 times more ), I went ahead and crafted my exploit.

But before, just a little explanation of what I understood after reading it.

So, after I overflowed the argv[1], just as in heap0, I still had i2 to overflow and do some trickery to redirect the code flow to the winner() method.

After the first one is overflowed, something had to take the position of i2->name, this something then has to make that the winner() method is called.

Now, what if we swapped some other function for the winner(), so that whenever this another function is called, the code flow just calls winner() instead.

Confusing, yes, I'm sorry.

This is where the GOT enters. This table will hold dynamically allocated functions, meaning that, having full controll of the second strcpy, we can copy winner() into one of the functions in the GOT table and then substitute it. And winner() will be called.

~~ Exploiting the vuln ~~

Right before starting to write the exploit, I wanted to know the padding.

I got it by trial and error: 20 is the larger number before Segmentation Fault occurs. After, I knew I had to dig into the GOT table looking for a function which I could use.

First, let's see what function we can find.I disassembled with objdump -d ./heap1 and:

 

I didn't find anything else aside from puts ( which is used for printing ), so let's go with that one.

Next step was finding it in the GOT table and find its offset with readelf --relocs heap1

There it is, the last one. And the offset is 0x08049774, will this offset match the range in the GOT section? ( readelf --sections heap1 )

0x08049774 is in the range between 0x08049750 and 0x08049778, which means that it's part of .got.plt

The last thing we need to build out exploit would be the offset of winner() method.

 

Now it's time to build our exploit.

1. The padding.

2. The address of puts so we can overwrite it with

./heap1 `python -c 'print "A"*20 + "\x74\x97\x04\x08 \x94\x84\x04\x08"'`

 

:D