Unlink Exploit

Summary

In this approach, we overwrite PREV_SIZE to shrink the size of the previous chunk. This tricks the heap into thinking that the previous chunk's metadata starts where our data does, enabling us to control chunk metadata. As we can control the fd and bk pointers, we can execute an unlink exploit. We can bypass the unlink security checks by pointing fd and bk to the chunklist, which contains a pointer to the chunk.

This enables us to overwrite a chunklist entry with the address of the chunklist itself, meaning we can now edit the chunklist. This gives us the ability to write to wherever we want, and we choose to target the GOT. We can overwrite strlen@got with puts@plt as that makes it functionally equivalent and then read a libc address. From here we overwrite free@got with the address of system and free() a chunk containing /bin/sh.

Exploitation

The Unlink

To bypass the unlink check, we need P->fd->bk to point to the address of P, meaning P->fd has to point 0x18 bytes behind it. Because we want P->fd to be within the chunklist (most simply at the beginning), we will allocate 3 chunks before the chunk we use for the unlink() exploit. Each chunk we allocate takes up 0x8 bytes of space on the chunklist (this will make more sense later, I promise).

We'll choose a size of 0x98 for the chunks. Firstly, this means the chunk does not fall in fastbin range. Secondly, the additional 0x8 bytes means we do in fact overwrite prev_size. Other sizes such as 0x108 would also work, but make sure Chunk 4 overwrites Chunk 5's prev_size field.

Now we will create a fake chunk. The fake size we give it will be the difference between the start of our fake data and the next consecutive chunk. In this case, that is 0x90 - as you see from the image, the difference between chunks 4 and 5 is 0xa0, so if we remove the metadata the fake chunk is 0x90. We'll also overwrite PREV_IN_USE to trick it into thinking it's free.

And if we send this all off, we can see it worked perfectly:

radare2 tells us chunk 4 is free. Chunk 5 has a new prev_size and P is no longer set. If we run dmhc again to view the chunk at location of chunk 5 - 0x90, our fake chunk is set up exactly as planned.

Now we free chunk 5, making Chunks 4 and 5 consolidate. This triggers a call to the unlink() macro on Chunk 4. Let's look at how we expect the unlink to go.

Both writes write to CHUNKLIST + 0x18, and the value written is the address of the chunklist. Now, if we edit Chunk 3, we're actually editing the chunklist itself as that's where the pointer points to.

We also manage to bypass the by getting FD->bk and BK->fd to point at the chunk's entry in the list.

Note that the value written was the location of fd, so if the chunk we overflowed with was Chunk 0 we would have had to write to a location ahead of the chunklist in memory in order to bypass the check, and pad all the way to the start before we could edit chunklist entries. By allocating 3 chunks before the overflow chunk we were able to write the chunklist address to entry 4 directly and bypass the check, meaning we had to mess around with padding less.

And it definitely worked:

LIBC Leak

Editing Chunk 3 now edits the chunklist itself, meaning we can overwrite pointers and gain arbitrary writes.

If we go back to the disassembly of edit(), we notice strlen() is called on the chunk data. We can overwrite strlen@got with puts@plt to print out this data instead - and using puts has an additional benefit: puts also returns the length of the string it reads. This means the program will not break, but we'll still gain the additional functionality.

Once we overwrite strlen@got, we'll call edit() on another GOT entry (free) to leak libc.

Now we just attempt to edit Chunk 0. Because it would print the libc address as soon as we enter the index, we'll have to do this part manually or the p.sendlineafter() lines would skip over the leak.

The response we get is

So it worked! Let's just parse the response and print out the leak.

Perfect.

Getting a Shell

This is quite simple - change a GOT entry such as free and replace it with system. Then, if the chunk contains /bin/sh, it'll get passed to the function as a parameter.

You may notice the 2nd and 3rd chunks have been untouched so far, so we could easily place the /bin/sh in one of those right at the beginning for use now.

We're currently halfway through using edit() on free@got, so we can just continue inputting system@libc as the data, then free Chunk 1.

And boom - success!

Moving to Remote

There are a few changes we need to make remotely. Firstly, the libc may be different (it was for me). Simply leak a couple more libc addresses and use somewhere like to identify the libc version. We can also change the beginning of our script.

Secondly, the way the service uses socat means it echoes our input back to us. Because of the way we use p.sendlineafter(), this doesn't affect us until we parse the libc leak. We can just listen to the extra data if it's on REMOTE mode.

Thirdly, the socat used has pty enabled. This means it interprets the \x7f we send as the ascii representation of backspace, which would delete anything we sent. To mitigate this (it's only relevant when sending system) we just check if we're on REMOTE mode and if we are we can escape the \x7f with \x16, the socat escape character.

And it works perfectly!

Final Exploit