How To Exploit a Heap Overflow

Key Takeaways

what i've been doing in recent streams we watch for example the pseudo video and you can ask questions about it and i add additional context to the video so if you have not understood something about this hopefully with my additional context you can understand it more now this video is less technical so i assume there are not that many questions or things i can say but let's see it's more about you know setting up the stage to go for the next technical steps and by the way this this thumbnail was done on stream with viewers giving ideas and you know we made it on stream i think there's a video on live underflow my second channel if you want to see how this amazing thumbnail was made i actually like this thumbnail i think it's a good thumbnail let's head in it's time in this video we will discuss possible exploit strategies for sudo in the past eight episodes we have used fuzzing to rediscover the crash in pseudoedit we have analyzed the crash with address sanitizer and found the loop that causes a memory corruption and then we looked at the root cause in detail and now wait i forgot the chapter markers i forgot the chapter markers i didn't enter the chapter markers here that sucks cause in detail and now it's time to make a plan for exploitation how can we turn this memory corruption in sudo into an actual privileged escalation exploit let's head in for heap exploitation there are basically two strategies first you can exploit the heap implementation itself so attacking the heap metadata or you can attack the data stored in the heap let's think about exploiting the heat metadata first you can allocate you can call malloc to allocate memory on the heap and you can call free to free the memory these are very abstract concept you as a programmer use how this is actually implemented simply speaking you just have a chunk of memory you just the program at the beginning basically allocates a huge chunk of memory so there's actually memory allocated already okay but that is not being used yet and when you call malloc some the this malloc function all what it does is it manages this memory area so it looks or where's their space and it returns you an address a function a pointer to that memory area and then you can use that you can write data into it and when you need more memory to save somewhere you can sort somewhere else and the cool thing of this about the heap you can also call free so memory you don't need anymore can be freed and then when you call malloc again it can reuse that part for other stuff so and um so first of all you have just data on in this memory right when your program uses data wants to allocate something and store something in the heap that data is on there so when we have a heap overflow and we can all write stuff on the heap so of course you can overwrite that data stored on there but besides the regular data that you just saw there there's also heap metadata so heap metadata is just additional bits and bytes that are used internally by the malloc function or the free function to manage these different memory blobs because it needs to keep track which memory is in use which memory is free which can be reused and so forth and so there are some additional bits and bytes for that memory management and um should memory uh yeah yeah sorry i answer that in a second so you have this metadata so when you have a heap overflow you can of course overwrite the regular data but you will also overwrite these bits and bytes that are used for managing this memory area and so when you think about using this heap overflow for exploitation you you have to ask yourself will i do i want to carefully control these bits and bytes managing the heap and can i do something evil with that or do i overwrite regular other data on the heap now we have a question in chat shouldn't memory be zeroed before freeing it not necessarily so it doesn't what when you say shouldn't when you mean it should be zeroed uh what do you mean by that because yes so so if you as a programmer when you free memory uh you can malloc again and reuse it in your code you should always assume that the memory might not be zeroed and so uh your code should already you know ensure that when you reuse area it doesn't um expect that it's zero on the heap this can happen and even if you zero your your memory before freeing it uh because of this heap metadata these uh these bits and bytes that are used for you know managing the heap they are not zero and they are from efficiency reasons not necessarily um set to zero or overwritten they might still be around for example when chunks are consolidated into one big chunk i don't believe that the stuff in the middle is zeroed out so you can still end up with a heap that is non-zeroed and so your other code that allocates stuff on the heap should never assume that the code by default is zero so that's the only real reason that's one of the main reason i guess that would be one of the reasons why you would want to zero it so you can always assume that the heap is zeroed but you cannot assume that because of the heat metadata that might be around the second reason is that there's an attack called use after free where [Music] you free a chunk but the data still remains um and then you allocate something else in its place and uh and then that things there's something already allocated something like that so in some cases it could help against that but not necessarily no use after three is a bit different case uh yeah i don't know anyway it's not it doesn't matter it shouldn't be really that important it's not that important uh yes let me let me think for a moment so i mean with use after three you have two components that use the same memory so nulling it wouldn't you free it but it's still being used so you might still be able to write to it but yeah so zeroing it could sometimes maybe break that in some way but no it wouldn't necessarily help against use of the three at all i'm whatever i'm saying sorry it's late it's 9 30 p.m in the evening so i might be a bit dumb today if you have watched my exploit education playlist then you might remember the videos about heap exploitation the heap is basically a data structure with metadata you can imagine it as a linked list so here you can see this very old video of mine the heap dl malloc unlink exploit or yeah episode hex 18 in 2000 oh sorry the screen i'm sorry in 2016 i made this video for the binary exploitation playlist so it's part of it um very mind-bending stuff and this metadata for example contains the size of the junk and some flags like if the previous chunk is in use or not blah blah details are important right now in those old videos we exploited a very old allocation algorithm called dl malloc not gonna lie that heap exploitation of dl malloc was mind bending and it is complex but it also didn't have any mitigations thus it was relatively simple nowadays the default malloc algorithm is a bit more advanced we have for example fastbins which are different data structure additionally to the regular heap that you might know and the malloc algorithms also have gotten a bit more hardened but only in some ways for example some techniques with fast bins are actually a lot simpler but generally in order to exploit the heap implementation directly you need a specific order of memory allocations and free operations so in ctf challenges you often have some kind of menu where you can create or delete stuff and then you can perform the exact order of mallocs and freeze you need yeah so this is very important in typical heap exploitation ctf channels you get some kind of menu and you can already assume from these menu points that either malloc or free operations are being done so the list ingredients will for example there might be an array that points into the heap and we'll just print it add ingredients certainly allocate something on the heap create receipt the same examinate ingredient will read from the memory area delete receive receive will be you know freeing some memory area and so forth so and with heap expectation when you corrupt the heap metadata so these are for example size fields or bits that indicate if something is used or not um there's the wilderness um value it's that's the name of a value that indicates how much space is still left on the heap the biggest free chunk basically and in order to exploit these places it's not as simple as overriding this one address and then the next time you use malloc something happens not necessarily at least so you need a certain operations of allocations and freeze where you in the middle in between you overwrite something and you allocate in free in the right order or things like that it gets weird and complicated and so it requires a bit more active interaction and we only have a heap buffer overflow so we overwrite it once and then it has to do something we we have to get code execution somehow and so we we don't have a complicated or we we don't have that much control over what sudo does we we throw it at one input and things has have to be fine we don't have any interaction this would be different if sudo were some kind of server software where you can for example if it's like an http web server or something where you can keep sending different requests and actions and that will then you know set up everything how it has to be or an and some kind of input menu or a command line tool or something like this right but sudo is just this one shot that's why i consider this fairly unrealistic to be exploited in that way where you can create or delete stuff and then you can perform the exact order of mallocs and freeze you need but in our pseudo vulnerability we have a single shot overflow on the heap we don't have any interaction with the program and on top of that we have to deal with aslr and the typical way of dealing with aslr is to only deal with relative offsets or first have a bug to leak addresses thus defeat aslr and then you can go further but again we don't have any interaction with sudo we can't perform multiple overflows we can't really decide how we want to allocate or free chunks with our one overflow we need to win yeah so aslr is another issue that we have but we ignore uh that issue a bit for now so with aslr the heap addresses would be randomized in the main program code as well in a program where you have a lot of interaction where you send some command and you get something back and send a command like like the ctf menu i showed before you can set up your bug first in a way that it will leak addresses from memory and when you leaked an address based on that address you can then calculate offsets and basically you defeat aslr if you basically you know there's a random value and if you leak one address you basically get that random value and now you know where the stuff is in memory but again we don't have that for pseudo it's one shot we don't have this kind of interaction so anything that would require us to for example overwrite a function point or or overwrite an a heap pointer or something in in the in a free list or something like that it's it would be you know it's not really we can't really do that what you can do is partial overrides uh but yeah that's a different thing yo 0x chips thanks so much for the for the subscription thank you very much that's why i believe attacking the heap directly the heap algorithm the heat metadata is unrealistic i don't want to say it's impossible people always find crazy creative ways but i don't know any reasonable technique that we could try so that's why i want to go for the second strategy attacking data on the heap yeah twitch prime nice case cassette cassettes thanks for twitch prime sub and geek manager as well thanks for so much for the prime sub twitch prime is free with amazon prime just fyi you can steal your parents amazon account yeah thanks so much i appreciate it we have a heap overflow and we can overwrite arbitrary data in other chunks we don't immediately crash when we overwrite this data we crash because of the side effects after we overwrote other data we call this corrupting memory so maybe there are some very interesting and useful data stored after our buffer that we can overwrite as an example if we find a function pointer on the heap after our chunk and is then used afterwards we could overwrite it and when the function pointer is then used at least we would have control over the instruction pointer a's law would still be an issue but we could maybe do a partial override whatever future problems something like that would get us a huge step forward but how can we find something like that what do we need to make this work this is actually the biggest question i had kind of myself um you know i i know a lot of basics and i have a good foundational knowledge of all that stuff but this kind of question how do identify useful stuff uh on the heap um you know the stuff that is after my overflow and what kind of stuff can we overflow that is a question that is very difficult to answer there's no easy solution it's you can't say it's this and that it's it's very unique to each program so you need some kind of methodology to figure this out and you need some creativity for each target individually how you approach this how you figure this out sometimes it can just be a reading code because it's maybe small and there can only be so many objects but something with sudo it's a massive software or it's fairly big but certainly there are even bigger softwares as well how do you figure out what you want to over write in memory what this this is one of the i think important questions that differentiate a professional you know somebody who's like doing professionals exploitation work or something from somebody like me who kind of just has foundational knowledge this this was one of the most important and most challenging parts of trying to exploit sudo finding the vulnerability throwing some fuzzing against a reading source code that i can understand that but now the creativity of exploitation that is like the true question for me i believe around that time i was also tweeting about exactly this issue and asked um if people have tips for that or something i should have dug out that tweet it's probably a long time ago so it's probably not so simple to find but yeah people there was some insightful comments on twitter maybe i should look that up later but yeah this is one of the most difficult things um because it's not simple to answer there's no easy answer for this as i said it's unique to everything you're a superhero another five gifted subs thanks so much we have completed a hype train uh that's awesome welcome everybody thanks so much so yeah so let's see what my first idea was because i thought about this i was walking my dog and thought about stuff how what do i want to try out how can i you know look into that let's look at the heap again with heap chunks in gdb here's our buffer now how could we know what is stored after it what is the meaning of this data how could we know if there is a function pointer so if for example sudo would be a program that is handling files a lot you know reading and writing files some config files maybe or something you know it does read some files like atc shadow or something like that but uh maybe look just looking at the heap and looking at the data afterwards you know if there would be a file path you know we could maybe say okay let's try overwrite that maybe something interesting happens with that file path so you know that is one option you could try to go for but clearly yeah or maybe you know we could think maybe we could all write root here with our username maybe that helps us in some way we don't know that is now creativity and exploration but um i from my again my programming experience and the fourth i i don't have like huge uh bill i i don't think that it's very likely to just look at it like this and finding something so i i think i have to go for something else this is probably the most subs i've gotten in a single stream yeah choo choo that's not easy and maybe there is no function pointer here at all but that's not the only question we should investigate check out this the allocation of our buffer happened right before we caused the overflow time wise right a program is getting executed at some point we look at the heap so the heap screenshot i showed you know happened at some point during the execution actually it happened right after we allocated our buffer so execution wise our allocation happened at the last point and still our buffer was in the middle of everything else so that means there's something else that we have to think about so it's the last chunk that was allocated but our buffer is not at the end of the heap this means that during the execution of this program memory was allocated and freed many times and there was a hole in the middle where our new buffer could so depending on how large our buffer is or how large other stuff is our buffer could be put into different holes in our case here the zeros that is our buffer was just allocated in this hole you can see there's other data before and after it this means not only have to we have we have to think about what is allocated after our buffer and if there's something useful that we can overwrite but we have to think about this buffer could be in many different places in what place helps us the most it makes it even more difficult it would be very static and we would always have this buffer before these other buffers then that wouldn't be a question we can just analyze now what is allocated afterwards we could even like note down the address we could do some debugging and look exactly where these chunks have been allocated and note them down and investigate if there's anything useful but our problem it's not really a problem but the challenge is or the opportunity because it can also be something positive we can influence what where on the heap it will be placed depending on if there are holes in the allocations where it is placed and that changes what we can overwrite so how are we going to analyze all those different options that is one of the main challenges that we will face soon fit in this means depending on the size of our buffer we could end up in different places to rephrase this depending on the length of the arguments so the size we allocate we might have a different heap chunk after the buffer we can overflow but that's not all we have to research we have no clue what influences the sizes of other heap chunks if you casually scroll through the allocated chunks here's a chunk with the folder path and here's what looks like environment variables which means if you have a different set of environment variables and probably many other things that influence what sizes of chunks are allocated on the heap the hole where our buffer will be allocated might be in completely different places the whole heap could be arranged very differently if you control this other data so these animations i don't know if that was clear to you what i tried to do there this these animations so before i started the sudo series i actually made a big summary video maybe it's in the recommendations here yeah this this video here uh how pseudo on linux was hacked um this is basically the summary of the complete research that we are now doing in detail and i made these animations for this video so if you just want a quick summary of the pseudo exploit and how everything went down this is your video these videos are very detailed they are intended to be you know for those that kind of want to follow along so yeah let's look at this animation so on this animation you have to imagine these are two different heap configurations so this is a heap and this is a heap and we look at how the heap chunks are allocated depending on the size of an environment variable that is placed on the heap this is just an example this environment variable has a different length and it will influence the how the heap will be allocated so these are allocated heap chunks okay and at the start they are still uh at the start they are still the same so you have to pay attention you will it will always allocate the same uh let's actually slow this down and just watch it slowly uh it will always allocate the same heap chunk look a big one was allocated still the same heap this was freed this was allocated still the same heap the big one is freed and now we allocate a different size of the of the environment variable and you can see they have different length on the heap and this influences and changes everything now now when we allocate this bigger chunk here it doesn't fit into here now this in this heap configuration using this long environment variable it has to place this chunk at the end while when we had a shorter environment variable it was able to place it here and now you start like completely differently now here the small one did fit right after it but couldn't fit in here so it had to be placed at the end and suddenly the heap is completely different which objects follow you know how and so we keep now and when this buffer is for example freed at some point then this is free then here is freed here new stuff could be allocated there was space in both of us so that is the same but now we allocate this one here so there's a smaller hole and here's a bigger hole now now this was about actually exploiting it so service user structure something that comes later during exploitation this was to visualize and understand how we can override the service user but this is an important struct later that we will learn about and so you know we keep freeing stuff and now we allocate the buffer that that we overflow so this is the buffer with the heap overflow here we can override stuff and so in this heap configuration the service user is after us now so we can overwrite into this struct while in this heap configuration when we keep writing we keep to the right you know we will never override the service user we just keep writing to the right so you see how influencing certain values can influence how the heap looks like which influences what comes after our buffer which is another question we need to ask ourselves how can we figure out the heap configuration that helps us the most that is you know that is the real challenge in all of this might be in completely different places the whole heap could be arranged very differently if you control this other data what does this mean does this make it easier or harder on one hand this means we might be able to carefully control where we want to place our buffer and overwrite the right thing on the other hand it might not work on other systems either way we gotta try and by the way this careful planning and arrangement of heap chunks is called heap feng shui feng shui feng shui is a pseudoscience way i was being told that feng shui is the correct pronunciation also in chinese and this is fake feng shui was wrong i typed it into i went into google and i typed in feng shui feng shui and i went on i probably had it on english or something and then i clicked on listen feng shui oh feng shui feng shui okay maybe maybe i thought it'd say feng shui but it was feng shui feng shui feng shui feng shui okay i mean i did this wrong in two videos i believe now uh you use the energy forces to harmonize individuals with their surrounding environment or in other words the pretty arrangements of objects in a room and i think there is no better word that could describe this for heap exploitation harmonize the heat chunks perfectly so that our exploit can work it's kind of magical anyway i'm not a pawn expert to be honest i rarely solve portable ctf challenges i know many won't believe me because i made the binary exploitation series i must be an expert and do that all the time but that's not true this suitor exploit feels a bit out of my league i think i have the skills to attempt it i have some ideas i want to try but maybe i will fail and that's totally fine for me because i know by trying this i will learn a lot actually i have already learned so many new things working through this project and it is already a success for me remember other people have done the research and there are many good exploits already but that's not the point we use the pseudo-vulnerability to learn and it's cool that others have written exploits already because if we get stuck or if i get stuck i can always look at the other exploits for inspiration so either way huge success for me uh no it's not uh porn expert i said pwn export which comes from pony you know like horses a horse pony so that's what it's about that being said what should be our next steps i have two ideas i want to combine the first idea is to write a tool that helps us okay so now we come to kind of like my the ideas i had we've come to why it's not necessarily my idea but um the strategies so i thought about this you know like how can we deal with the heap how can we figure out what to expect and here i share you what i thought might could work for the exploitation i as i said in this video and as i said earlier i'm no expert in this i have good fundamental knowledge but i lack this kind of research experience this digging into a big real life application and not just a ctf challenge this was the first time i really dug into kind of a real life exploit like this so you know this was all new to me but this is exactly why i did this project and that's exactly why i wanted to rediscover and do this myself and not just read the write up and solution of everything i wanted to understand how researchers can figure that stuff out that's the whole point of it and so i need to go through the struggle of trying it myself and if i fail i can still look at the solutions or all is good but i wanted to try to figure out how i could come up with my own exploit strategy so here are my ideas now i want to combine the first idea is to write a tool that helps us enumerate or fuss different heap configurations by controlling buffer sizes but to be honest this idea is not actually from me when pseudoedit was released i obviously read over the advisory and i remember them saying this to implement this initial technique we wrote a rudimentary brute forcer that executes sudo inside of gdb overflows the user args buffer and randomly selects the following parameters so this is an example of where i read about an idea it seemed obvious and i saved it in my head and facing this exploitation challenge i recalled that i could try to brute force different parameters see uh this is something you know why i also believe uh you still take something away from watching my videos even if you don't understand it when i read over this advisory or skimmed over this advisory read a little bit of it i did not understand all of it here there were so many questions like how did they get figure this out i don't understand and so forth but i read this and that placed a little seed in my head and when i was actually you know i was doing the same project i was also tackling pseudo but this kind of applies could apply to any exploitation thing uh this made me remember this write-up and or you know i i believe my the idea of this brute forcing you know i probably saw in here but it's also not like super a secret crazy tip it could also have been that i maybe you know just thought of it because it's obvious to think of that but what i'm saying is sometimes you pick up on small stuff when you watch and read things even if you don't understand them but these small things spark your creativity on your own problems that you're facing for some other stuff and i read here that this can be done so um you know it probably in it probably influenced why i wanted to you know brute force uh heap layouts um in in a certain in a certain way uh yeah so even if you don't understand videos of mine maybe some ideas or concepts or methodologies stick with yourself and can then be applicable to other stuff you're working on yeah exploitation challenge i recalled that i could try to brute force different parameters now the advisory specifically talks about which parameters they fuss because they have an actual exploit technique they are going for but for my learning attempt i don't want to do that i don't know this technique so i want to see if i can figure something out myself but still using the technique of brute forcing heat layouts that was the first idea but i have a sec notice my magical clothes switch that was insane it's like magic it's a magic trick yeah i i started making this video and i noticed when you know recording and editing it there would be twice or three times as long so i know i know because these are so boring dry and stuff i need to make them shorter and this was a good point to stop where we kind of just you know generally talked about our strategies and about the actual implementation this can be it's isolated video it makes much more sense to separate them because they are different things than putting them together so yeah i had to re-record and a different ending to that video and then go of brute forcing heap layouts that was the first idea but i have a second idea i thought i could specifically search through the heap for function pointers how would i do that i'm sorry not telling you just now but i would love to hear your ideas in the comments below next video i show you how i have done it [Music] fun fact uh some people have suggested this exactly the idea what i've been going for in the subscription so that was very cool [Music] you