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

Key Takeaways

last video we had a look at the DL Malo implementation of free we discovered the unlink macro that can be used to write almost arbitrary data to another address we constructed a proof of concept Heap with GDB and observed a successful right to the global offset table but eventually we realized that our plan would not work because it contains too many null bites and we can't write those with a St copy let's quickly recap and summarize what we know about the Heap and the free algorithm to refine our exploitation plan the last video was more explorative taking you along how you could discover the exploit yourself but this video will be more of a presentation this way we have two different styles of videos about the same topic which I hope increases the amount of people who understand how it works so let's look again how keep chunk looks like when you allocate a chunk of a certain size the size of the chunk will be written to the second word and Mello will return the address here this means you have this area for user data the last bits of the chunk size have special meaning most importantly the last bit is the previous in use bit so that is information about the chunk before so that's a little bit weird to wrap your head around at the beginning this means if this block here is allocated the block afterwards would have the last bit set because the Chunk in front of it is in use now a free chunk could contain more information so once we free this Chunk we obviously can set the last bit of the chunk afterwards to zero to indicate that the previous chunk is not in use anymore now imagine there is a third chunk a chunk after the second one which has its previous use bit not set this means the second chunk is free now the algorithm would like to merge consolid at those two blocks this is where the two words after the size start to become important they are the forward and backward pointer just as a side note this only applies to chunks that are bigger than the fast bin size because fast bins are very small chunks and they don't use a double link list so our chunks are bigger let's consider this Heap setup we have a chunk we want to free which is followed by an already free chunk and that free chunk has two pointers forward and backwards pointing to some other free chunks so they are in this double link list now what will happen is the free algorithm will merge these two blocks together it will do that by First unlinking the free block from the list by using the unlink macro and we learned what that does it takes the forward pointer address and writes it at the forward pointer of the previous chunk and it will take the backward pointing address and write it to the backward pointer of the next chunk and when we obviously control the pointers of a free chunk that will be unlined we can point into the global offset table and write there the forward address in the last video we stopped here and didn't check out what happens next but let me tell you now so next we will increase the size of the Chunk we are freeing with the size of the already free block and then we will insert this block into the double link list which means we take one chunk and look up its forward chunk and then we update the pointers accordingly to now include our chunk this is the whole Magic of the Heap now let's get back to the famous Frack article Once Upon a free and Voodoo Melo tricks to see what they tell us about the unlink exploit both articles contain a cool little trick to overcome the limitations of the null bite so when we want to construct a fake chunk that we can unlink we want to make sure that no field has to contain a albite this means we have to use very very large values for the size but it doesn't seem useful because the Heap is not that big hm but the clever ideas showed in the frag articles make use of how computers handle negative values so let's quickly explore what happens with a 32-bit integer value when we add a very very large number for example F FFC that would be over 4 billion now what happens when you add 64 which is decimal 100 to that 4 billion that doesn't fit in 32bit and the carry of the addition will be lost now you have a very small value again in fact it's hex z0 which is four less than the 64 this means by adding 4 billion the FFC to 100 we actually subract four and that's a really useful behavior for our case because this value that doesn't contain any nbytes behaves like a very small substraction so when we skim over the source code again we can now make a plan first of of all we again have to overflow the size of our chunk with a bigger value than 80 so let's do the 100 like last video but then we could also not care about the first consolidation attempt of the previous block this way we don't have to set up another fake chunk so we make sure that the last bit of the block we are going to free is set to one so it's still in use but we could do the consolidate forward part there we take the next chunk and check from its next junk the pre new bit and if that is not said we attempt to unlink Consolidated BL this means we need two fake blocks one that contains the forward and backward pointer we want to use to override the go with an address from the Heap and the second chunk has to have a size with the lowest bit set to zero but we can't use small size values but if you look in the code how size is used it's just used as an offset which is added to an address the code doesn't check that it's a ridiculously huge chunk it just adds the value and here where the trick comes into play we could use FFC as the size of the chunk which results in a minus 4 now think what will happen it will take the size of that chunk adds it to the current address to find the next chunk which Falls free into thinking the next chunk is at minus 4 from here now it will read the size of that chunk which we could also set to FFC which doesn't have the last bit set and concludes yep the block before was not in use let's unlink it and boom it's very beautiful and clever it doesn't contain any null bites so let's see if we can fill the Heap in a way that we can do that with string copies so string copies stop at null bite this means we have to use one of them to overflow the size of the Chunk we want to free with 100 hex 64 uh obviously we want to pref in US spit set so we need to overflow it with 65 this works because we don't want to override more than that it ends in an all bite and keeps the size clean the other string copy could be used to fill up the 100 byte until the weird conjoined fake junks with FFC and afterwards the two addresses we want to write now like in the previous video we will set the one address to the global offset table so that we override puts and the other one will be pointing in into the Heap this means we will redirect code execution to this Heap address and we can use the first string copy to place some Shell Code here keep in mind that the unlink will also write some data from the global offset table to this Heap area so we have to either keep the Shell Code short or jump over the smash data and continue Shell Code afterwards but we just want to call winner so let's construct the exploit you could do it in one line but let me break it up to make it easier to follow in each of these windows we will construct one parameter one string for each string copy so maybe let's first take care of the string copy of the middle chunk because that should be the one to overwrite the chunk size with1 of the third chunk I use Echo for that and I counted the amount of characters necessary to hit the size of the chunk where we then write 101 hex 65 I redirected the output into a file B and we can use it with back ticks and cat as a parameter in GDB we can then run it and investigate the Heap looks perfect the the size of the third chunk is now hex 65 next let's take care of the third chunk which is after the Overflow so it's 100 by big so we want to write like 100 characters to fill the chunk and then eventually we arrive at the next chunk where we want to write the FC's for the trick from earlier followed by the global offset table address and the Heap address here I get the table address for puts and subtract minus 12 from it because the Heap address will be written as at plus 12 and then comes the last string copy the first chunk where we want to include our Shell Code to call winner I quickly Googled for an online assembler to create the Shell Code we want to call an absolute address to do this we have to go via a register so we could move the address of winner into e and then call E we can simply copy the string representation of the Shell Code and write it into the file a cool now that we have all three parameters we can rerun the program let's execute the free and single step into puts call oh great we follow into the heat but somehow our shell Cod is wrong you can see that it's completely garbage instead of our Shell Code we have some addresses here oh of course we perform multiple freeze not just the one we obviously write metadata over these values but we can simply fix it by pointing to a different area of the Heap how about here at 14 now we change the address and prepend some characters to our Shell Code and try it again we run it single step into puts and arrive at vinner let's try it without GDB it worked gosh I love this [Music] [Applause] oh