This is going to be an in-depth explaination of the overlapping chunks techniques on GLIBC 2.27, this technique can also be produced on the GLIBC 2.23 but for this blog, I did a challenge from HITCON CTF 2018 which seemed very interesting in itself. I loved this challenges as I learned a lot about heap internals and how the heap really recycles the chunk and how prev_size plays a big role here.
Foreword
This technique of overlapping refers to the scenario when a free‘d chunk actually overlaps into an already allocated chunk resulting in overwriting the heap pointer of the other chunks. This is usally chained with the Off By Null overflow resulting in the PREV_INUSE bit of the next chunk being overwritten.
The best way to understand this technique is to make use of the challenge(s) since that way we will analyse the heap as we step in. Now, to start off, there are two binaries taken from the HITCON 2018 CTF, following are the link to the binary, Libc, exploits and IDA database for the corresponding binary.
Attachment
- Children Tcache : https://github.com/D4mianWayne/PwnLand/tree/master/Heap/GLIBC%202.27/Overlapping%20Chunks
- Baby Tcache : https://github.com/D4mianWayne/PwnLand/tree/master/Heap/GLIBC%202.27/Overlapping%20Chunks/baby_tcache
Now, let’s continue on the challenges.
Children Tcache
This challenge was remarkably easier than the Baby Tcache from the same CTF, that being said, let’s start with checking the binary’s security:-
vagrant@ubuntu-bionic:~/sharedFolder/training/hitcon$ checksec baby_tcache |
As expected from the good CTF, all the security mechanisms are enabled but little do we know, it doesn’t even matter, let’s work on. Now, for this part, explaining the whole binary functionalities would be tiresome and won’t be needed at all, all we need to is to find the overall workflow of the binary and where exactly the vulnerability reside. The vulnerabilty as mentioned before the technique we are going to discuss here usually chained with the Off by Null vulnerability.
unsigned __int64 add() |
The read_string is not vulnerable here, actually the issue here is the strcpy(dest, &s), since strcpy copies the data from the &s to the dest including the terminator \0 null byte, this leads to Off by Null overflow, as the technqiue implies, the man strcpy says:-
The
strcpy()function copies the string pointed to bysrc, including the terminating null byte ('\0‘), to the buffer pointed to bydest. The strings may not overlap, and the destination string dest
must be large enough to receive the copy.
Now, since we know that there is a vulnerability, we need to know the overall workflow of this binary, the workflow is as following:-
It implements 3 basic functions,
add,deleteandview.It used a global pointer to store information about chunks and the size allocated.
The
addfunction is vulnerable to the Off by Null vulnerability.It allows the allocation size upto
0x2000.There’s no Use After Free vulnerability.
It allows the active number of allocations upto 10(inclusice) times.
Exploitation
First and foremost, I created the wrapper functions such that we interact with binary more freely:-
from pwn import * |
This being aide, now let’s jump into the heap exploitation part, to start off, we will create following number of chunks:-
0x500size chunk.0x68size chunk.0x5f0size chunk.0x18size chunk.
This is because, we will need the 2 chunk of size such that when tcache bins would be full they’ll land into the unsorted bin. Moving on, we will fill the tcache bins for the size of the chunks we allocated:-
p = process("./children_tcache") |
Now, this will do the allocation, as nothing important to see as much, to explain the size allocation here, we will be unsorted bin size for doing the overlapping chunk here, to move on, we will delete the chunk_1 and chunk_0, the chunk_1 belongs to the unsorted bin since it’s size is morte than the tcache can hold and the chunk_0 will go in the tcache.
# we need to delete chunk_1, this is because we will be using this chunk to |
Running the exploit:-
ef➤ heap bins |
Now, as you can see the chunk 0x555555757260 belongs to the unsorted bin and the chunk 0x555555757770 belongs to the tcache‘s bin[5] being the size 0x70. Now, the tricky part is that, whenever the chunk is free‘d, the program memsets the free‘d chunk with the 0xda byte by byte, overwriting whatever was written in the chunk so far.
# when we free a chunk, programs writes 0xDA to the whole chunk |
So, what we do here is, since the free‘d chunk’s contents is being overwritten by the 0xda byte by byte, to mitigate this in such a way that the chunk_1, the chunk which went into the tcache, so here doing constant allocation of the size ranging from the 0x5f to 0x68, all of them will land into the tcache bin[5] since the rounding size for the chunks allocated in that range will have the 0x70 size and will be in the bin[5].
Now, doing allocation and the deletion of the chunks accordingly, since the strcpy will append the \0 to the adjancent chunk and the continual deletion and the allocation of the chunks as the size is same as of 0x70, for every allocation it’ll just return the chunk from the bin[5], this will result in the PREV_INUSE flag of the adjacent chunk being overwritten.
gef➤ heap bins |
Now, as you can see the heap_list is at the address 0x555555756060 which have the chunk 0x00005555557577e0 at the index 2, seeing the PREV_INUSE flag for that chunk we see that it is cleared. Now, to work on with this, we will overwrite the prev_size for the chunk_2, what we will do is allocate a chunk of size 0x68 such that it’ll be returned by the tcache and we will overwrite the adjacent chunk’s i.e. chunk_2‘s prev_size.
# heap_list[0] => chunk_1 (0x71) |
Doing so,
gef➤ heap bins |
Now, we will have to free(2) such that the chunk_3 the target chunk having the prev_size value 0x580 will consolidate with the chunk 0x0000555555757770, so when we allocate a chunk of the size being the 0x508 this will result in the fd and the bk being populated with the main_arena‘s address for the chunk 0x0000555555757770, so initially the chunk_0 i.e. 0x0000555555757770 was not cleared but consolidated but since the global pointer contains this chunk’s pointer on the index 0, doing show(0), we will have the LIBC leak, with the help of it we can defeat the ASLR.
# heap_list[1] => chunk_4 (0x511) |
Now, doing so:-
gef➤ x/10xg 0x0000555555554000 + 0x202060 |
Having the leak:-
vagrant@ubuntu-bionic:~/sharedFolder/training/hitcon$ python3 children_tcache.py |
Now, we have the LIBC leak, defeating the ASLR, we have to now force the malloc to return a pointer which we can overwrite like __malloc_hook or __free_hook by taking advantage of the heap layout. To do so, initally we will take the overlapping of these chunks to get the duplicate entry, to replicate it, we will allocate a chunk of size 0x68 this will return the chunk as same as of the chunk_1. So, when we do the free(1) and free(5), it’ll result in the same chunk being deleted, since two chunks are free‘d the tcache will have the duplicate entry for the chunks, making a loop, due to which we will be able to overwrite the fd & bk of the free‘d chunk and let it return the chunk.
# heap_list[2] => chunk_5 (0x71) |
Now, doing so, when we see the heap layout:-
gef➤ heap bins |
As shown from the tcache bins, we have a free‘d chunk’s fd is pointing to it’s own address, which commonly refer as tcache dup entry. Now, we will overwrite the fd of the same chunk with the target chunk, for the target chunk I used the __malloc_hook but you can also go with the __free_hook way:-
Now, to do so, we will allocate a chunk, which will return the chunk 0x0000555555757770, then we will overwrite the fd pointer with the target chunk __malloc_hook, then we will do one more allocation such that it’ll have the tcache head pointing to the target chunk adress:-
# we can create a fake chunk i.e. target pointing to the __malloc_hook |
Doing so:-
gef➤ heap bins tcache |
Now, the next allocation will return the address 0x7ffff7dcdc0d, which we can overwrite with the one_gadget, resulting in the __malloc_hook being overwritten with the one_gadget‘s address and trigger the __malloc_hook by allocating a chunk, hence getting a shell:-
# heap_list[6] => fake_chunk (0x7f) |
Doing so:-
vagrant@ubuntu-bionic:~/sharedFolder/training/hitcon$ python3 children_tcache.py |
This was an interesting challenge.
Baby Tcache
This was another challenge proposed in the HITCON 2018 as a part of the pwn category, although the general idea for the exploit was same but the catch here was the show function was not there anymore, this made the approach to this challenge significantly harder than the Children Tcache. In order to pwn the binary, we have to get the LIBC address but since there is no show, we will take the advantage of the stodut structure, in order to get leak of the LIBC address, we will first understand the _IO_2_1_stdout_, so let’s delve into it without wasting any time.
To save the time, we are not going to reverse engineering the binary since it is same as of the children tcache, the only difference is that this binary doesn’t have show function making considerably harder for the LIBC leak but not impossible.
The address might be different in the snippets but the core principle is same, ASLR was on during the test as well, so the address randomization could be seen.
Using the same wrapper function from the previous challenge:-
from pwn import * |
We will follow the same approach, this being said, as we did in the above challenge, we overlapped two chunks such that the main_arena address was populated to the allocated chuk as from the heap_list making us to leak the addresses, this time since we don’t have a show function, we will overwrite the last few bits of the populated address such that it points to the _IO_2_1_stdout_ so that the fd of the free‘d chunk from the unsorted bin would point to the _IO_2_1_stdout_ such that it’d be return to us upon next allocation.
Now, we will alllocate the chunk of following size, usually the ones which will go to either the tcache bin or the unsorted bin:-
|
Now, here we allocated the chunk[0] and chunk[4] in an unsorted bin range and the rest of them usually belongs to the tcache bin range. Now, what we will do here is, free the chunk[3] of size 0x10 and then allocate a chunk of size 0x18 but at the same it’ll belong to the bin of the 0x20, the same chunk will be returned. When that will happen, since the actual size we allocated and we are allowed to write to will be of size 0x18 allowing us to write into the metadata and if we will look at the layout of the chunk:-
The 0x20 chunk |
Now, what will happen here is we will trigger the off by one vulnerability and as well as the prev_size this will result in the chunk layout being:-
++++++++++++++++++++++++++ |
So, when we look at it ourselves in the gdb:-
free(3) |
The chunk layout in the memory will be:-
gef➤ x/40xg 0x0000555df391c810 |
So, now when we will free the chunk[0] and chunk[4]:-
free(0) |
Running so:-
gef➤ heap bins unsorted |
Now, the total size of the chunk belongs to the unsorted bin is 0xad0 is the summation of the 0x500 and the size we gave it as the 0x5d0, hence 0xad0. But at the same time when we see the whole heap layout, it turns out to be like this:-
gef➤ heap chunks |
If you pay attention, we had almost 6 chunks allocated in which we free‘d 2 of them, that leaves the 4 of them allocated, but as the gef output we can definitely see only two chunks here referenced, first is the one we free‘d and went into the unsorted bin and other one is the last chunk we allocated to prevent the top_chunk consolidation. But when we look at the gloabal array which keeps the track of the allocated chunks,
gef➤ x/30xg 0x55dd713f3050 |
It shows we have 4 allocated chunks, this shows that the chunk[1] and the chunk[2] and the chunk[3] now is within the unsorted bin chunk. It overlaps the chunks contigously laid out. So, now we will free the chunk[1] and the chunk[3]:-
free(1) |
Checking the bins and the heap chunks layout:-
gef➤ x/400xg 0x5623a643c250 |
Now, if we do pay attention the chunk[1] and the chunk[3] which we free‘d a moment ago is within the chunk we free‘d with the extended size, resulting in the overlap. Now, we will just allocate a chunk of size 0x4f0 giving the chunk 0x500 from the unsorted bin and then again allocating a chunk of size 0x90 and this time, we will get a chunk from the unsorted bin, since the given chunk will have it’s fd and bk populated with the main_arena, we will attempt to write the last 4 bits of the fd address such that it would point to the _IO_2_1_stdout->flags:-
add(0x4f0,"a") |
Doing that so, we get the _IO_2_1_stdout_ address populated to the heap_chunks global array at the index 3, this happened because when we allocated the chunk of size 0x4f0 that made the all the chunks which we free‘d belonging to the tcache bin as they overlapped into the unsorted bin result in the free‘d chunks also being populated with the main_arena address. So, when we allocate a chunk of size 0x90 will be given from the unsorted bin, from the overlapped region, hence we could overwrite the last 4 bits of the address and made it point to the _IO_2_1_stdout_:-
gef➤ x/10xg 0x56431531d050 |
Now, what we will do here is make the flag to be 0xfbad1800 and the associating member of the struct to be of the NULL, hence resulting in the next puts call, which will call the _IO_new_file_xsputn hence, giving a huge buffer dump:-
gef➤ p _IO_2_1_stdout_ |
add(0x60,"w") |
This resulted in:-
Now, such that this has happened, we carefully parse the leak which resulted in a success LIBC leak:-
libc_leak=u64(p.recv(6)+b"\x00\x00")-0x3ebff0 |
And we get a success LIBC leak, thus defeating the ASLR:-
[+] Starting local process './baby_tcache': pid 4839 |
Now, from this point we will just overwrite the fd of a free‘d tcache chunk with our target address such that during next allocation, depending on the size will return the target via malloc allowing us to overwrite it. Given the heap condition as of now, when we look at the available bins, we see:-
gef➤ heap bins |
If you pay close attention, the chunk of the unsorted bin is pointing to the address 0x55.....0800 and at the same time the tcache bin[0]‘s chunk point to the 0x55....0810, this proposed the idea of allocating a chunk of a size which will return the exact chunk pointed by the unsorted bin, that way we will be able to overwrite the fd of the tcache chunk 0x55......0810.
add(0x400,p64(0x00)*2 +p64(free_hook)) |
Doing that so, this will overwrite the fd of the chunk 0x55...810 to the address of the free_hook, for which we can get it in next allocation-
gef➤ heap bins tcache |
We successfully overwritten the chunk 0x55..810‘s fd to the address of the free_hook, now we will just do two allocations, one will return the chunk 0x55..810 and the other one will give us the target i.e. __free_hook.
add(0x10,"a") # Gives the chunk 0x55....810 |
Given this, it’ll result in the __free_hook being overwritten with the one_gadget address:-
gef➤ x/xg &__free_hook |
Great, we successfully overwrote the __free_hook address, now we will just do free(0) which will just result in the one_gadget being called, spawning a shell:-
free(0) |
Now, we get a shell:-
[+] Starting local process './baby_tcache': pid 6009 |
This was it, although this could be more explainative if we go in-depth about the _IO_2_1_stdout_ part, for that, I saved the analysis to later on. Now, that was that, have fun pwning.