The Heap: dlmalloc unlink() exploit - bin 0x18

[@rootabeta9015]

One of my favorite things about this channel is his ability to break down topics that I find impossible to grasp into pieces that I can understand, then assembling them to a final product, managing to coax my brain into actually understanding the material in a way that no textbook or article I can find has managed to pull off. One of my absolute favorite channels and learning resources, all in one.

[@yaseen_elolemy]

man this is hard af

[@creature_of_fur]

Videos about heap overflow make my brain overflow the heap. And SIGSEGV

[@nikoshalk]

Very brilliant solution and your explanation was equivalently thorough!! Thank you a lot for these series!! I managed to solve it by inserting a fake chunk between "b" and "c" instead of using the nasty trick of overlapping chunk metadata. I believe this was the toughest exploit so far. As a side note, the actual exploitation in the video (from 7:47 and so on) felt a little bit hasty, but the theory definately makes up for it!

[@Valbz0r]

already liked while still in the recap at 2 minutes. Really consolidates and makes things clear

[@Bart4Games]

my mind exploded! thank you for your clearly explaination!

[@paryuljain6057]

Hi liveoverflow. I am getting this error, while executing the exact same steps on the same code. Please help me out. This happens when we change the input from tmp/A, before that, all the heap values were changing properly as shown in the video Program received signal SIGSEGV, Segmentation fault. 0xb7e7c3c0 in __GI___libc_free (mem=0x804b058) at malloc.c:2968 2968 malloc.c: No such file or directory.

[@jacckiechan60]

Hi Liveoverflow, Thanx for all these very informative videos. I understood the whole thing except the one where we are subtracting -12 from the got address of puts. Why are we subtracting 12 from the got address of puts? Can you please explain the subtraction part in detail.

[@LiveOverflow]

+jacckiechan60 it's because the implementation of free will take the address and add +12 to it, because that's the location of the pointers. So in order to end up with the correct value we first need to subtract 12.

[@steefant]

It would have been interesting to hear about the segfault at the end. If I am not mistaken, after winner returns, the free call that has triggered it also returns(?) but the clean up code after main returns (the approximate equivalent of an exit(0)) trips over the corrupt heap, right?

[@womenkiller71]

I tried to inject shellcode, which was just "call 0x8048864"(winner function) but it resulted in SEGFAULT. Why is that a case? Cant call instruction just be supplied with a direct address?

[@hancloudstrife1764]

Hi @LiveOverflow, your video is very awesome... however, I have a problem about `bk` in block three. In your case, I think `bk` is not need, right? We just only care *fd* must have to point to shellcode, and `bk` can point to arbitrary address, right?

[@SolomonUcko]

Don't we need a pointer into the Global Offset Table?

[@tretree3781]

Great tutorial! I follow the steps but segfault in Kali & ubuntu since Heap isn't executable :( In order to exploit successfully I have to call mprotect(0x804c000, 0x1000, 7) after 1 malloc() from gdb, then continue the exploit.

[@BrainFood155]

How can you add a static address as the fake chunk's `bk` word? Doesn't the heap change the base address all the time between different runs? It doesn't seem repeatable on my system.

[@LiveOverflow]

on a system without ASLR, yes it stays the same. On a system with ASLR, you need another bug to leak a heap address first.

[@maxvc2330]

In the case that the prev. adj. chunk is free, why is unlink applied to the previous chunk and not to the chunk itself? If P is the previous chunk, then FD=P->fd is our current chunk, so BK->fd=fd doesnt point at the beginning of our new chunk, but somewhere in the middle. Is this the way it is supposed to be or am i misunderstanding the concept?

[@maxvc2330]

After looking through the malloc.c again, i realised that this is undone later in the code. Still, i'm wondering why they did it that way, but okay im fine for now :D

[@robindimyanoglu4369]

Because the current chunk is being freed just now, therefore it doesn't belong to any lists yet. And previous chunk is already freed, therefore it belong to a list. So it should be first unlinked from that list before consolidating into the current chunk. Previous chunk can not be in the same list because it's not a chunk anymore but instead a part of a bigger chunk. Hope this clarifies.

[@quocanhnguyenle4330]

Hello @LiveOverflow, what is the version of malloc are you viewing? Could you give me its source?

[@quocanhnguyenle4330]

and why we insert -4(fffffffc) instead of something else?

[@quocanhnguyenle4330]

I got the malloc version.

[@uuuuuhhlettuce3909]

I know I'm extremely late, but I don't understand the Null byte problem. I found out that a null byte tells strcpy that the string is over and stops copying, but what now? What is the problem?

[@thecrazzxz3383]

Well then if strcpy stops at every null byte, if there are null bytes at the middle of your payload (the data you exploit with), let's say you have something like : "AAAAABBB(NULL BYTE)CCCCDDDD", strcpy will only copy AAAAABBB and everything after it will be ignored, now imagine there was something essential for the exploit after the (NULL BYTE), the exploit wouldn't work as it should do

[@sahilsharma-hj4gq]

This was good but you in video you are saying you added 0x65 in second input and 100 C in third input string, but in reality you added 0x61 in second input and 88 C in third input. When I tried to add 100 C also , I am getting segmentation fault. Then I tried with 88 C, it worked. dont know why... I think it has someting to do with last bit not set of 0x64

[@nopnopnopnopnopnopnop]

If you guys are doing this excercise in Phoenix Heap 3, then I wrote a walkthrough for that, based on this video: pastebin.com/jy1yRhBc If you want to ignore the explanations, then the payloads are copy pastable.

[@minhcuongtran8504]

thank you

[@Born2KillHF]

Ok I watched the whole video and this is awesome.. but I missed just one step(the improtant one lol).. At 02:51 I got the logic of the unlinking method. But what I can't get is how [fwd Pointer = GOT] and [bk pointer = heap] allows you to execute your code. I mean I got that when the code execute the free(c) fucntion, the fake freed chunck (the "FFFFFFFC" ones) is unlinked then the FWD pointer (GOT) should be placed as FWD pointer of chunk pointed from bk Pointer (HEAP).. So in few words you put the GOT pointer into the first HEAP chunk.. Then the bk Pointer should be placed as bk pointer of chunk pointed by fwd pointer.. So in few words you put the the HEAP pointer into the GOT chunk. But can this be usfull for you.. Even if I'm pretty sure that I have misunderstood this proccess.. (i hope I ve been clear about by problem)

[@LiveOverflow]

haha I'm a bit unsure if O get what you try to ask. But I understand your confusion - it's confusing to me too. So I think you understood that we can write an address from the heap into GOT, thanks to this unlink. So we overwrite a very specific GOT entry, such that next time we call puts, it will find the heap address in the GOT instead. And thus jump into the heap - as if there were our puts function. So then we execute shellcode on the heap - so we control execution flow. Did that answer it?

[@Born2KillHF]

Ahahah.. Sorry for my bad english.. I will try to explain me better splitting it in two questions: 1) Are free(b) and free(a) relevant for the success of the exploit?? 2) What I can't understand is what happen when the the fake chunk is unlinked. I explain me better trying to figure out what the computer/processor does to execute our code step by step(Of course correct me if I m wrong I m here to learn ;) ): 1. It allocates chunk A (32 bytes) 2. It allocates chunk B (32 bytes) 3. It allocates chunk C (32 bytes) 4. Put the shellcode on first chunk data 5. Now it puts shitty stuff inside the second chunk data until we reach the third chunk size and overwrites it with 65 (that is 100 in decimal plus the prev-in-use bit set) 6. Now put other shitty stuff ( 100 "C" in order to fill the memory allocated) and then overflow again in the "eventual 4th chunk. 7. The first magic is here: you overwrite the fake 4th chunk's size with a negative value in order to have a fake 4th chunk that has the prev-in-use bit set to 0, followed by fd pointer and bk pointer(like it was freed). Now the heap looks like: Chunk A ---- Chunk B with prev-in-use bit set to 1 ------ Chunk C with PIU bit set to 1--------- Fake Chunk D with PIU bit set to 0, fd pointer, bk pointer. 8. The computer now calls free(c): it sees a chunk that we want to free (C) followed by a chunk already freed (D) so it triggers the Unlink() function. 9. Let's unlink it: this fake Chunk D has two pointers, one that points at the forward chunk and the other that points backward chunk. The processor now needs to link the Backward chunk with the Forward chunk and merge the Chunk C with the FAKE Chunk D. The forward chunk in question is the GOT and the Backward chunk is the chunk A (where we have the shellCode) 10. free(b) 11.free(a) 12.call puts What is not clear for me are steps 9, 10(if necessary), 11(if necessary) and 12. I don't undestand how we execute the shellcode located in chunk A.. I m pretty sure that the problem is that I have misunderstood the step 9. Thanks A LOT for your time anyway. ( I hope now I ve written in a more comprehensible way)

[@LiveOverflow]

yeah the magic is all in 9. So 10 and 11 don't do much other than free those blocks, but we don't need them. luckily they don't screw up our exploit either. We execute shellcode in chunk A, because we have written this address to the GOT entry of puts. So when we call puts in 12. instead we call the address from the first block. We have written this address of the chunk A into GOT, because our fake chunk said that the next block is GOT, and the previous block is chunk A. So it unlinked our fake block and wrote the NEXT address (GOT) into chunk A. And wrote the BACK address (chunk A) into GOT.

[@Born2KillHF]

Ohooooh now my brain is running better eheh.. And If I mak bk pointer = GOT and fd pointer = HEAP (in few word the reverse of what you did).. it would work the same?? Because in this way I would have the Got pointing at chunk A and the ChunkA pointing at the GOT as well right?

[@LiveOverflow]

yep pretty much. But as mentioned in the video the pointes will be written at different offsets +4 or +8, depending on bk or fd. So basically the same, just at slightly different offsets.

[@hikaru-live]

I think you should have enough space to construct a call to _exit after the call to puts? xor eax eax; int 80?

[@meithecatte8492]

maybe, but why bother?

[@abdarafi]

@@meithecatte8492 avoid segfault ?

[@R0hirrim]

Consolidates are ok, algorithm also ok, but I dont really understand what is the problem with copying until the null byte by strcpy ? Why we use the ffffffc trick?

[@nadavshemesh1231]

Since null byte indicates the end of the string to be copied, the data wouldn't be fully copied

[@wdp6057]

at 6:03,I misunderstood what you said。Today,by reading the source of dlmalloc.c,I understand inuse_bit_at_offset() is to find next chunk+4 ,is fffffffc,and check out "PREV_INUSE".Maybe I should sit in the corner and think about how to learn English

[@李慕白-j6p]

oh, i'm stuck in this place, could you explain how it works? i just think next chunk + chunk_size(-4) -> size (+4) equal fffffffc. thanks! by the way your English is better than mine :)

[@wdp6057]

before" chunk "is freed ,it would check whether "next_chunk"(ffffffc,ffffffc,fd,bk) is freed .how to check it? dlmalloc use function inuse_bit_at_offset(nextchunk,nextsize). Here ,nextchunk is （fffffffc,ffffffc,fd,bk）,nextsize is second fffffffc(-4), so that "next_next_chunk" is (fffffffc,ffffffc,ffffffc,fd),check flag pre_inuse is 0. so we think "next_chunk" is freed and we can unlink "next chunk" (ffffffc,fffffffc,fd,bk) to attack. hope that it`s useful to you.

[@李慕白-j6p]

thanks! i understand!

[@quocanhnguyenle4330]

Hi, as your explaination that the value "fffffffc " was used to bypass nullbytes? I think it's used to calculate something as well, however I can not catch what is it? and what is it for?

[@wdp6057]

both of them, to calculate where is it` next chunk and make sure dlmalloc think it freed

[@gordonzar992]

i know this is an old video, but keep in mind that these days, the heap is marked non-executable as well as the stack.

[@mrmrjims3865]

is this heap and issues only came with c++ ?

[@marvinmottet5699]

Every program that runs on your computer, phone, etc has a heap. What's different is how the program is going to manage it. That's one for the reason there's so many programing language. Every language has its own way to deal with memory (or to let the programmer deals with it). In this case the code is written in C and not C++ but there are very close concerning memory: the developer has full control on it. It's one of the point that make C and C++ difficult but very efficient language. The issues here comes from the fact that the programmer lets the user uses the strcpy function. As you can see, that function has a lot of power in C/C++! One of the most important rule in IT security is: NETHER TRUST THE USER. Nether let him take control of a critical function and always check his input. In other language, like C# or javascript, you don't have to manage the memory yourself (or at least care about the heap). But that doesn't mean that you can't exploit the memory. Writing code that works is easy. Writing code that works in a efficient way is hard. Writing code that works in a secure and efficient way is a pain in the... In a few words: Every language deals with the heap, no one is perfectly secure, mainly because of the humans creating and using them.

[@mayconufes]

Congratz! Hack N' Roll

[@poseidonsecurity9985]

Hi you guys, I wonder why it does not check *(P->fd->bk != P || P->bk->fd != P) == False ")*? And, which the version of malloc did you use?

[@1e1001]

0:50 twouououo

[@douwehuysmans5959]

Dude if you have arrows crossing over and moving all over the place it doesnt become easier.