2017 - Cisco ASA Episode 3: A Journey In Analysing Heaps by Cedric Halbronn

okay so hi everyone so I'm gonna talk about Cisco si firewalls so just a little bit about us because it's a it's been a work that I did with the iron atoms and we're a part of EDG which is the exploit development group of NCC group and we do basically energy research reverse engineering explore development so a little bit of context first if you don't know what an is a firewall is it's basically what you have at the bottom left it's it's a sa stands for adaptive security appliance and it's basically full of features it supports firewalling VPN gateway router and it's pretty it's pretty amazing system and you can have different sizes but basically underneath

it's the same software internally and now you say it's a Linux with a special a sa folder which contains everything related to a sa and it's a little bit different than iOS in that that Nancy Squires in that Cisco is is a proprietary operating system here we are we have a Linux space let's support both 32 and 64-bit devices and the main binary is called liner and it's in a SI bin liner and it's basically a 40 Meg binary that contains everything it's kind of a critical device because it's it's the entry point for basically all company's networks and so basically if you control an AAC device then you can basically access to the VPN you can

access to the routing stuff credentials and you basically have access to all the the internal network and you can see everything that goes through the VPN so it's it's really scary if we if we think about it but let's let's understand something in 2016 last year existence our released an exploit for foreign ability or hip over proven ability in in the Cisco essay they called their research executive Ike at the it was responsibly disclosed to Cisco before releasing its basically the the nobility that targeted is in the Cisco fragmentation payload so it's something that is related to Cisco like the name Cisco fragmentation it's basically a payload specific to to their need to do reassembly inside Ikey itself so the

idea is you would send different fragments and they're going to be already assembled into a packet that's going to be interpreted as Ikey and there was an ability in the way the reassembly worked we're going to talk about it I'm gonna explain you how it what was the burn every table basically for now we just need to know that there was a nobility in the way there is on the packet what the packet was reassembled and it wasn't integer overflow and it it resulted into a heap overflow so what is really interesting about this rarity is its in its pre off so meaning Ikey is used to establish a VPN so it's it's the VPN is not

established yet so it's preauth and Ikey is available on the internet everywhere because it's used for the VPN so they released their exploit in April 2016 and their explore targeted I give it to a specific sa version nine to four and 32-bit only it's pretty awesome research if you think about it and they actually got the pony awards up last year so it was pretty cool so what what are we going to do from that the thing is exploiting a heap overflow requires understanding heap internals so we can abuse them we we actually understood their research and then we ported there exploit to Ikey v1 with different constraints and also both for 32-bit and 64-bit and all AAC versions but to do

that we had to understand heap internals also we built three gdb plugins to analyze heaps and understand and basically abstract things so we could basically exploit bugs without just relying on Radames and without understanding anything and it really has to assisted us in to exploit exploiting the bugs so what I'm going to propose you to do is to participate to an awesome journey into a scale a heap internals and and flows so we're going to focus our our talk on 32-bit just for the sake of simplicity but lots of concepts actually applies to 64-bit ok so let's go so what is cisco fragmentation so the idea is you have a fragment ID which is going to

be the same for all your fragments and then you have a sequence number which is different for each segment in each fragment so you have six wins number sequence number two one seconds number two and then one of the flag is to set the last fragment to one for example what happens is the derailleur knows it received all the fragments and it can reassemble then now every time if a fragment is receive is going to be added to a queue and when they are all received it's it's reassemble so you can have another fragment ID then you can have sequence you can have fragmented with different sequence number they can be in different orders it doesn't really

matter number two then one three and then at the end when you get their last strike you know you can we have some of your packets okay so we're at the pin ability the thing is the way the the the fragment are received the each fragment will have a header and some data and the header will tell basically the size of it of the data and and you will have the last frag bits also to indicate if it's the last fragment but basically because each fragment has a header we don't care about the header because it's just metadata to say what the fragment is for so when you're save a fragment you add it to the queue but the the header is

removed so you you basically we subtract eight to the length of the of the data but the thing is you can fake the actual fragment length and basically if you specify your length of one minus eight it gives minus seven so basically the queue is it's going to be added a negative length and you decrease the actual length of the of the the total length of the different fragments so when you basically reassemble when the the bucket is reassemble the buffer that is going to be allocated is going to be less than the actual fragment data and then basically when you copy the different fragments you overflow into the batter and you guys you can basically corrupt

things on the heap so what we try to achieve is quite hard because basically we don't control the allocation or the free but we can still gain code execution by correcting things and by making the right request at the right time but what I haven't explained what how so we we actually need to understand the heats because we're going to correct things on the heap but we want to get codification right so at the moment like one of my colleague Chris and I would say it's it's a little bit like like if we're trying to pick a lock through an instrument fan in the dark and with a paper clip so we basically need some tool right

because it's it's really hard otherwise so our talk is going to be about understanding a sa heaps understanding cisco sa modifications that actually made it worse and then in the process of the presentation I'm going to show you some tool that we've developed that helped us exploiting the bugs okay let's let's go through what is a heap so I'm going to talk about three well-known heap alligators that are of interest here we have D alma rock which is the dog lee alligator which is quite old 1993 and then we have Peeta Mellark which is the past red alligator which is the this real three - okay ders I'm going to talk about are really related

because they are folk from each other so we had gel Mellark pitting lock is a fork of the El Morocco so they share things that basically patema rock was developed in order to support mr. in a better way the hip irregular would support misreading and avoid lock contention and then we had the new lead see here alligator which is probably the most famous because it's used everywhere on Linux and is used a lot on all the system that are based on Linux so hip manager usually assists us in a location allocating and freeing chunks so if we want to get some memory to do some stuff we're going to ask the Gila garage to that for us so it provides the api's

malloc and free usually so it usually it has some kind of region that the hip alligator controls and know it can use for for allocating stuff and basically when we do a malach we're going to basically get some parts of this region that's going to be given to us so we can do whatever we want and when we don't want it anymore we call free and the hip alligator knows you can retrieve it for another use so we allocate stuff and basically the hip alligator there are two strategies it could either track allocated chunks there are actually three strategies you could you could track free chunk allocated chunk or both before primer performance reasons usually the

hipergator only track free chunks because if you if you track three free trunks when you do malloc it knows the free chance so it's gonna basically take one of them give it to you remove it from the list and then last time you call free it's gonna take it back and put it back in the fridge and it doesn't need it doesn't really need to track allocated chunks and obviously because malloc and free are called Lots it's worth performance reason so let's say we want to allocate something detective free trunk it becomes an allocated and and so on so I've talked about Chuck's chunks a chunk is a memory part that is basically returned by the

heap alligator for us to use that's we call it chunk and what is really important about the the three hip alligators up I've been talking about is that the the they store the metadata for the chunk before the chunk so when you basically have a heap overflow so for example if we the the chunk on the Left we can correct memory we're going to basically corrupt some memory of the following chunk and basically corrupt some metadata on the heap so that's why we need to understand what the how the heap works because we're going to be able to corrupt things on the heap the last term we use is bin so the bin is basically a way to track

free chunk we have been of different size so if for example you want to allocate a 100 byte chunk it's gonna look at the bin for 100 bytes chance and just take one of them it's easier for the he burger to return you a chunk if you thought the chunks by by being and the last thing that is important it are all open source so if you actually want to understand what a HIPAA locator is it's more complex that then I'm not gonna explain everything in one talk but basically if you look at the source it's the best way in my opinion to get used to what a HIPAA regular is okay so now we have these three heap alligators we

want to know what is used on Cisco si they are based on Linux so probably one of the string we're gonna figure sound a little bit and we actually if you reverse engineer the liner binary you will realize that it uses a version of dilma lock which is compiled directly into the elf rather than national GDP so that's quite interesting and it does link with GDP but it doesn't use the malloc function from gilepsy so if we look at the disassembly even if you're not familiar with x86 you can see strings that are used next P news P and if you look at the source code you can directly see that you have this kind of

string so you can say okay they are using the element inside the binary and actually if you look at more strings and you try to find more that our in the injection mark source code you you can find variable this one and another one you realize that if you actually look for this too you can actually determine the exact exact version of GL Malaga's embedded into the binary because it's it's the only one that has this two is to dot I dot string so it's it's it's actually very it's a very nice step to understand that it's a person to a three because you have some mitigations that are added over time in the analog so for example

we know that this specific versions doesn't have safe and linking which is a mitigation to deal with memory corruption on the heap metadata because it's only unable laughter 285 so it's it's good to know okay so more concept about DML up 2.8 because now we know it's still mark 2.8 we have this concept of n state and M space I'm set on a V space it's basically the memory region I was talking about that the here alligator need to deal with an enemy state actually can contain several segments it's just a way for them to say okay if we want to have several segments allocated in different places they are going to be managed by the same the same

m space so I'm gonna use n States instead of M space and vice versa there are very close concepts so that's why but basically when you look at things is going to be allocated in one segment or another it does we don't really care but what is important is if you actually know how the heap allocated works then you can basically build tools to part the memory and give you a representation so you can interpret the stuff you know in an easy way so for example first thing we wanted is to be able to pass on M States because basically it it outpost for example to okay add that here we have the bin so

here we have the bin so the bin for each size when we have a list a doubly linked list that's going to list us all the chunks of a specific size so if we allocate stuff we want to find our chance we're gonna find them here and then we have this map that basically indicates how many chunks there are in the or if the indicates basically if a chunk is if a specific bin is empty so if you have one it means it's not empty and if you have zero it means it's an empty bin and then you have other interesting concept is for example this magic we're going to talk about it it's it's like a global

cookie that is used to cause some kind of security which is helpful and then we have DV with it which which stands for visit designated victim basically when you free a chunk the latest chunk it's going to be pointed by the DV the idea is usually when you have locate stuff and free stuff it's gonna be already the same kind of size so it's an optimization to say if you free something and then relocate it it's gonna basically access the TV and it know the TV size so it can know if it can reuse it it's actually something that we want to exploit in terms of exploitation because usually we rely on freeing things and then having a hole

before staff and correcting this so if you if you if you can access DV it's helpful for us because we can check our exploits is actually on the right path and you have the segment which basically indicates where in memory are our data so we it's easy to determine the address of the EM state because it's passed to M space malloc so let's talk about that so they introduced this term F n space the idea is before it was it was called an end state but it was because the the HIPAA regular would manage the heap on its own but what you can do with the new deal malloc is you can manage your own m

space which is like a name state but you can manage it and you can have several ramps pace and and you're going to pass the n space to the n space malloc function and you can irrigate things on different end spaces so you define M space and instead of calling malloc you can call em Spice Malik and pasty in space at the function so you create your own space um and the idea is the alligator maps the mirror segments and stole the EM state into the the first second the first chunk of the M space so this is how it looks like when you call em space model so you have your M space your you have

your segment inside the space and the M state structure that we saw earlier which is just here to track things is basically in the first segment it's not really useful from an exploitation point of view but it's useful to know where to find things because we want to build tools to analyze the heap okay so theoretically you can still use the malloc and free so you can have your own m space and still use the MV and call your M space malloc and you can still call the malloc function that's going to be handled by the he bragger itself but you you can also choose to not use the maroc so basically you define only m

spaces and then you you won't have the manag functions anymore that's actually what we have in AAC so if you actually look at a disassembled firmware you you look at mallik calls and under underneath it's actually calling several wrappers but at the end of course and space malloc and you can match that the end the the function you don't have the the symbols and everything but you can write this function and space Malik has all the the GL malach debiting strings and it's it matches with the actual source code of the unmarked so you have basically a wrapper that calls their space model so they based their implementation on the analog and they they don't use real malloc so they

basically use M spaces and only n spaces and it's statically compiled into line now Oh so the last concept we need to understand is the concept of men poles it's something specific to this query say that they added on top of Dominic the idea is they want to track different M States and and then they use this term which is men pores so men poles is like a region of memory dedicated to allocations for Cisco SI components so we built this tool which basically shows a structure which is the member list with which contains different members and each member will point to a end state which a different name so we have the one for GM a related allocations and

the most important one which is the general purpose allocation so the M State we saw earlier is actually is actually tracked from an mmm pool so if we actually look more in detail on the different wrappers why they use wrappers and what they actually do with that we're going to explain that basically rest rest manager CL oak doesn't do much except dispatching to the next wrapper and then mmmmh CL oak will actually add different things to the metadata it will basically it will basically inject booking structures into the allocation so if you reverse engineer it you realize that it's indeed it's calling and space mallow which is which is what we saw we told earlier and EBX is the length and

it's going to add 24 before calling malloc so basically it's asking malloc to allocate more than the actual requests that was made from from the user perspective so why does it do that actually it's adding another header inside because we saw we talked we saw we said earlier that gel malach has its own metadata but mempool actually cisco adds another layer so after the the allocation we can see that it's it's storing the length it's storing the magic and it's storing a magic at the end ubx being the size so at the beginning is during the magic which which is quite funny because they use a lock a 1:1 see a lock one two three and

a log cdef pretty cool when you look at them and then you the another interesting thing is they actually store the color of my log so basically here they retrieve the stack pointer well the base pointer but it's points to the stack and basically use that to find the address the return address from maroc in order to store the return address which is basically the color of the function malik so if we actually now that we've done the reverse engineer part we're going to build the actual header that is specific to Cisco this is a structure like this you have a magic you have which is only the same you have the length of the data with that without

this header and the the al-malik header and you have two pointers that points to another allocated chunk and then you have a log PC which is the address of the color so easy now now we can build a tool to see what chunk looks like so if we look at a specific chunk and specific unspecified - V to specify that it's we want to to see rubber city for the chunk we see the this is the general option so it's gonna contain a footer and and the size of the chunk and then we have the cisco specific header which which contains the magic we saw our the lengths and this this double W link lists pointers and then the a log PC so

here for example we can see that the color of this chunk is Ikey I'd receive frag it's pretty cool because it means we can actually track who allocated what chunks so that that's something is not it's not possible to do it with DLR but with their audition from our perspective it's it's pretty useful and then we if we don't specify - V for our chunk we can just print like a simple representation of the chunk so the way we chose to represent things is we print the address then M formal exchange or F for free Chang then the size then the flag that correspond to if it's current in news previously news and then the

allowed PC because we found it's pretty cool to to have to know the allowed PC so we just decided to print it as well but we didn't print all our stuff in the simple representation and here for example for this chunk if we take the forward pointer which is M H F D link - 8 - punch to the DL manag header and we print it we can see that it still something valid and it's another chunk that was allocated from I key so that's but it means our opportunities working here we have another example where yeah that's the same chunk as here but with detailed information just for them completeness so if we take that yeah

that's just what I say okay so if you look at actually the Cisco shell you can see that there is a common which is show mem detail which basically allow you to print information about allocated chunks and free chunks and this is a hint that something is going on under the hood because usually a HIPAA regular will only track free chunk so it wouldn't know how many chunks were allocated but because they added a specific header they are able to track free and allocated chunks just interesting another interesting thing is when a chunk is freed there is no safe and linking and meaning that even though the gel mark would have safer linking their mempool header doesn't Hammett's

say anything even though I said earlier that's anyway the two version version 283 doesn't have safe and anything anyway it's actually interesting to see that it evolved and the recent version now has anything but the mempool still has safe the mempool still doesn't have safe and linking so anyway this this the fact that it doesn't have same fun inking is used by the exodus Intel I give it to exploit together to get me rights and another interesting thing about these mental structures is that if you have a memory Revolution bag where you can leak data from the heap you can actually get some really useful information because you have the pointers for the from the

top for the W link list which basically leak in pointers to the heap and you had these pointers to the text section which is a function powder and basically you you leak that an address from the text so it can be useful to bypass a etc okay so we know they use the analog we know they use this M space only way but actually one interesting thing is Delman lock has security features and it shouldn't be that easy to exploit but we're gonna see that actually C square say I added modified the code and actually made it made it worse so this is the dilma lock header which is before the the cisco main pool header so it has

a preferred the size which is called head and then for free chunk you have these free boundaries but was into injury what is interesting is usually heap managers reuse the first field for as a spillover when the chunk is allocated because if the chunk is allocated well usually this this field will be will hold the size of the previous track but if the site if the check is allocated you can reuse that and base keypad and use that as a spillover so it's really handy for HIPAA regular because it can save space and simplify the lineman's but for DL for the newest version of DL manag basically if you define footers instead of using this

part of memory as a spillover when you create an image chunk it will basically store into the the pref foot of the adjacent shank spot some specific magic as a security measure so it's not called pref size anymore like previous size but but is its it's like a it's like a global cookie which the purpose is if you corrupt the adjacent chunk you don't know the cookie so you it's going to break and HIPAA regular is gonna abort or assert well actually if you look at the the source code of the anak it says this check words are the same within each execution of program using malloc but differs across execution so externally crafted fake chunks cannot be freed so that's

exactly what I said if you if you have a chunk before another chunk if you corrupt the preffered you don't know in advance what the cookie is you're not gonna be able to do anything so how does it work refuge is calculated when the chunk is allocated so if you have the address of the N state M P the pointer to the image chunk and s the size of the chunk it doesn't mean it's going to basically take the P the chunk plus the size to point to the next previous to the next chunk take the pre-flood field field and set it to the address of the M States X so this magic and this magic is like a

global magic so we can see that the security relies on the inability to predict both m and the magic if you look at the source code of DMARC again Emperor magic is initialized by the certain function called init parents and it uses either a deadly random to read the number of bytes to to set this value to a random value or call time zero okay so it looks it's secure and then you need to have additional checks when the chunk is huntable to check that the cookie is correct right so the thing that is done is when you free a chunk it's going to take the address of the other chunk make it point to before the

general Chiang get the end state for this chunk and then check the magic from the M States so how does it work get'em States for is actually taking the chunk plus the size to access the private prep food field of the adjacent shank XOR that with a global and we should it's basically the reverse operation as when we we set it at the beginning so we are supposed to get an M State address and then once we have this M State address we basically just access the magic and it should be the same as our global if we don't get that it means something went wrong so it's an interesting mechanism in that if we define n spaces

and footers we have this global cookie so how is it implemented into a say the first thing we can notice is they don't use dev random because if you reverse engineer the function you're going to call that the creating space with good base you're gonna see that there is a call to time zero so it uses time zero instead of copying a random cookie from dev you random the other thing is that is interesting is because some for some reason it's called really early at boot wrap zero wrap time zero actually return a static value which is this value and this corresponds to an NTP time stamp which is the new epoch but what is it

what is interesting is it's it's constant so what can we do with that week all right time it's returned the constants and then we see a bunch of operation XO with five high five which is basically these three operations so times 0 is constants XO constants it gives us a constant so you can actually confirm that with our tool because the dalm state so I didn't show the whole structure it like a big structure but the magic that is stored is always the same it doesn't change which makes sense now we know why and if you actually do the operation to set a prayerful into a chunk n space X or the magic if you take for example this and space

value X all this it gives you this magic and we could see that in our chunks the preffered is always set to this is it it's still rely on on the M State address right we still need to know the M state address well on an SI 505 where there is no SLR we only observed two different addresses for the my name states so in meaning we have two different address and we have two different values right right it's still online in a non-ideal from an expectation point of view because we still need to override this pray fruit for field and if we don't know it in advance it's really hard well it turns out there is another Christianisation

cisco made which actually makes it all irrelevant anyway so what did they do if you look at the unmarked 283 you have this n space free function which if footer is defined like I said it's gonna get the M States and then check the magic but if you look at at Cisco implementation what they did is they're checking if the M space is normal and if they know they basically trust the M space and they don't they don't try to get the M space from the chunk itself meaning when they check the magic since the trusty Amster them space is going to access the magic from the end space and it's going to be valued all the time right so and the

thing is all the function actually internally use em space with a space nominal so it assume it's correct em space doesn't rely on using the pointers derived from fooder and we don't even have to guess the footer at all so interestingly you can confirm that by using their IQ exploits that they release because they use a static prep food that when you decode it it gives an m-space address at this c8 address but in our case we did we didn't know we didn't have an M space at this address we only had we only uncultured two different addresses but if you try their exploits on your race a it still worked because they don't check the

actual magic so for Francisco excuse it's it's quite hard to implement like a device which handles a million of packets every day or more so basically they try to do something performant right and and so they they don't want to do extra check where there is no need to well in terms of security we can see that it actually allowed us to to override chunks and code things because there is no check so what is what is this good for oh let's use our tools to rule them all so one thing we can do with our tool is we can send different chunks of the same size and we can count where they end up being stored so we see

for example that the small bin for c0 chunks is empty then we send packets of specific fragment of specific size for example with lots of fragments of the of the same size seven eight bytes itv1 fragments which end up being allocated into c0 byte chunks and then we can check see that our chunks are allocated into this bin for example if we take the first one and we use DL Chang to print the information we can see that it's been it's been allocated by by the ID stack and here we can even see that it's been freed afterwards because it has the F flag and it's been freed by a Nike free or frogs function

so we know it comes for from our Feng Shui so the next thing we can do is we want to neither the heap layouts because it's cool to know that it's out showing the good size but we want them to be adjacent because we want to curb them say something that we control so for example if we print which does she as count 10 chunks we're going to print tensions and we can see that they're all from IQ receiver processed data which is pointing to our data and we can see that there are some free chunks in between so we're going to see why so we can see we have some allocated chunks and some free

chance so it gives us some kind of abstraction if we get a little bit more detail here we are we are analyzing a free chunk so this free chunk that's cool it's been free by Aiki but actually if we free if we show the detail of the chunk with Dodgeville for verbals and dash X for hex dump we can see that it has metadata which is the deal malloc plus the main pool header and then the data actually contain the bytes we send a 42 42 because we send we send acid that payload in our example so we we know for sure it's it's our data right because we're selling something to the rawr we

want to know where it ends up being stored another example with allocated chunks same thing but here we know it's been allocated here and it contains our data so we want to exploit the designated victim scenario for example here we show that the LM states with a designated victim it's the latest chunk that has been freed by by the hip alligator so in this case we can see that it's an 80 by chunk and what is really cool is if you have your debugger attached and you see after you're sending some stuff where what is the digit activity then you can basically send packets of this specific size that end up being allocated in a

specific size and and you know it's going to replace this Chiang because this chunk is going to be taken so you can exploit this this so the other interesting thing is we want to be able to analyze allocated chunks so we saw earlier we are able to track free chunks but here we we are able to track allocated chunk using the main pools the Cisco main pools so in this example we can see that the small bin which contained the c0 byte chunks is here and we can actually found all our chunks in this in this bin and we can see that it corresponds to the to the allocations we we made okay

so now let's say we don't know where our chunks are but we want to find it in an easy way without having to parse the structure by hand because it's it's okay to find you're sorry to find your bin and then find your chunk and do it by hand but actually we have everything you need we need now to actually do it automatically we can just call our new new command and be bin work specify the string data that we wanted the string the data that we want to look for and specify just print me five chunks and I want you to look for chunk of the specific size and it's going to basically print as all the chunks that

contain our pattern and for example here in this example if we take this chunk it does contain the for one for one okay swimmin now so now basically we want to be able to to craft the heap in a deterministic way we are able to print chunks so we set a breakpoint on the the function where we know our interesting chunks for i key are allocated and we use our tool to just print the chunk the data and here we can see all the allocate so we send a bunch of chunks a bunch of fragments that end up being allocated in chunks and we see here the address the addresses are random but at some point it's it's beginning to be

adjacent so we use our tool to say okay that's cool now now we can we can allocate chunks in a deterministic way and all our future chunks are B are going to be allocated in an adjacent way so the other thing is we talked about reassembly we we can send different fragments they are going to be resembled and we can exploit this why because if you send different fragments they are allocated somewhere then you trigger reassembly and we don't need the fragment anymore because now we are going to to deal with the actual reassemble packets so the the the previous fragments are gonna be freed so we can basically control allocation and and free as well so for example here we

want to see what happens a when we send three fragments so we saw in this case we basically set a breakpoint on my log - to see all the allocations and we see that there are bunch of allocations that go on the way so we see allocations for one fragment allocation for another fragment allocation for the third fragment and this just using this we can actually guess by the name what they are useful so you actually have some structures to track the actual packets and then you have the first for the first fragment structure - to track the queue because the queue is antiphonal so we we have this fragment queue and then the queue

entry to point to the packet and then for the other one you have the same kind of structure to track the packets but then we don't need a fragment queue anymore because the queue is already created but we just need to create an entry for the for for adding the element to the queue and same thing for the third packet the only difference is for the third packet because it's the last frag bit set we're going to trigger reassembly so our our I key get a simple packet function is going to be called to trigger reassembly so just setting a breakpoint on my log we can see that there are some allocations and we know

exactly what it's doing without having to reverse engineer everything so the other thing we want is basically we want to be able to control what we correct so let's take a scenario we want basically to allocate chunks in two different sessions the idea is if we control two different sessions we can free one of them but not the other and create some kind of holes before the other which we control still and then use this second one to do start so we're going to use two sessions with fragment for both so we're gonna send fragments one after the other we know we can have this at a jet adjacency because we saw it earlier so we're gonna craft

online do some brainstorming and think we can maybe do that send fragment one from session one fragment one from session to fragment to from session one fragment two from session two at cetera and there is then at some point we send the last flag from for the second session and be and we're gonna create holes and actually if we do that and we actually then look at the other memory we can see that we have M F M F so we can see that we have exactly what we wanted we have our session one still here and we have holes for for them for us to to put stuff in basically so now what we can do is trigger reassembly for

specific size and it will end up being it will end up reusing a hole because the size is correct in this case we can see that it's actually reusing a part of the hole and still be still leaving a hole afterwards so now we want to do better because we want to create more memory to cope more chance and get more data corrupted and more arbitrary right and more me oh right sorry so what we want basically is to send fragment for session one to fill hole the holes then different fragment in different sessions the idea is we can arbitrary free session too by sending the last frag it's going to free the fragments so we can trigger reassembly

into this hole and then when we correct a lot of memory we're going to correct fragment from different session and basically now we are corrupting the metadata for all the chunks and because we control this session we can basically arbitrary free each one and get different me rights when I design but we want to use our tool to check it works so basically we we do that we send our fragment and we and we trigger reassembly and we can see we can see here that our allocated buffer is before a free chunk so once you 0 plus 40 which gives us 200 and we can see that it's before sweet chunks each one corresponding to a different session

because we on propose send different data in there just to to see them in action so it works so here it's a different view where basically we have our allocated chunk before the free chunk and before our control chunk so here I just annotated the different data for our chain so we can follow and then we can basically overflow the chunk so by overflowing the interesting thing is we we we we overthrow the size and we change it to a larger size so what hands up being changes the 40 here which is changed to 6 B zero so basically we just overflowed a little bit to just the adjacent chunk and we just change this this size and the thing

is we can check with our tool that the memory is still is still the layout is still valid and for the hip irregular is very important now basically what is important to know is that we were actually in the middle by changing this size we're actually saying to the hip irregular this is this this is all part of the same shank which is free and and this chunk are all part of the chunk so now what what happens is when this one is coalesced with the previous one which is now free it gives us a louder chunk and this larger chunk angels end up ends up being basically all this change and we can reallocate it and correct more

data so that's that's what we do we know the size because we've used our tool to know the size so we can allocate exist this exact size take and exploit the designee designated victim scenario to basically replace the friction with an elongated chunk right so in conclusion for 60 to 64 bits it's the same as 66 for 64-bit is the same as 32-bit for the old 64 bits on your 64 bits you have different hip alligator that is used if you look at and disassemble the actual liner binary you will realize that you have still this chain of wrappers but at the end they end up calling the leap Sima rock but they don't call the m-space malloc

anymore they call an external malach from gilepsy and basically to summarize the d for hip alligator on C square say for all 32 for all 32 sorry for 32-bit version and all 64 bit they use the analog to 83 and for the recent version that you used a lip see so it means now with GDP they have safe and linking which prevents this kind of overflow but they still don't have safe and linking on the actual mempool meta data that the specifics for Cisco so basically you can still corrupt data even though G Lipsy has safe and linking so we actually need a library to pass patema log two chunks so we actually did it and we basically

built three lives which I showed you some part there are very similar to other lives that allow you to pass chunks in memory likely see a log from our own islands or shadow from our P which is to parse GAE Malacca chunks the interesting thing is we've tested it on both GL maroc & peeta mellark and 32 and 64 bits and we've used red sync which is a plug-in to synchronize gdb and Ida Pro to basically retrieve the symbols so that's how we are able to show the the name for the functions and both both both stool actually supports callback to actually deal with the mental headers so del maguey called will call in to lis

mempool and leap it even after fall into even poorer so leap Peeta Mellark we built a fork from leap heap developed by cloudburst because basically even though his stool is pretty awesome we wanted to basically have the same kind of commons for all our tool for consistency it's easier for us to to have the same kind of comments it's the process of using them and we also needed to integrate with the cisco header so to summarize the security of cisco is a old versions used in Melaka 2.8 they don't have safe and linking on the GL maroc they don't have safe and inking on the mempool and their future is is broken in that we can actually curb data and they

don't check the footer and on the more recent version they use peeta mellark which has safe and linking but still the mempool cisco specific data doesn't have safer linking so we can still exploit that and the good thing about cisco as well is when we reverse engineer more versions in more recent versions they actually added a SLR and dep which wasn't supported before so just to summarize good tooling is usually synonym of success future work we want to achieve we want to basic abstract things so our tool can be using other debuggers I want to test on more targets maybe on more cisco devices because we focused our research on cisco essays we want to implement maybe other commands

for now we just implemented the one we needed to actually achieve our goal to speed the process of developing exploits but you can make it more powerful because we can realize it we're going to realize this tool very soon thank you if you have any question yeah no thank you very much [Applause]

that's a good question is very own very method in practice what you do is you try and just do more locations if you need yeah yeah what I should what I showed is basically after I already tried several several times and so I end up having this kind of adjust adjacency and it's a very good question I mean and it's very similar with what you would do on browser bugs where you need to spray some or spray some kind of memory to fill all the holes and at some point you know you've achieved your goal and usually you do a little bit more just to handle yeah but some sometimes you don't have this capability because it's

multi-threading peeta mellark is a little bit more complicated because it's mootisse ready it's gonna allocate stuff in a less deterministic way but with in our case it was deterministic so we are we sorry yeah so we we managed to exploit this this heap management determinism but it's not always the case but it's good to you know that's the way to do that's the way to go but it's good to confirm it's actually it's actually a Justin just because you need that these are just Jason Seifer for exploit purpose but it's a good question yeah okay