Scudo Allocator exploitation

we actually had to uh swap laptops uh so uh the the demos for the next talk are on uh the conference laptop which uh so be easy on the presenter uh and and and appreciate the work that um he's done to to get this to work for us today we have a really great talk uh It Is by Zach EOB talking about the scudo allocator exploitation so let's welcome Zach to the stage uh cool thank you oh wow mik is working good to know um yep welcome to my talk it was Jess introduced so this sl's a bit redundant uh starting off with who am I uh I'm just a unw computer science student in my second year um do a lot

with the uh uni security group called sexo um in general I'm just binary exploitation nerd uh anyn B exploitation and I'm interested uh and then I play CTS with a few teams like Bliss C emu exploit uh one down under CTF for a few years that's the main uh gist of it now to the actual talk um the sco allocator is a memory allocator which is you know wow uh it's developed originally as part of llvm uh and it is like security focused in that um when designing memory allocators typically the main considerations are like performance and memory footprint and not much else um whereas like scoo inherent to the design was like uh safety against memory

corruption uh the reason why you should care about this is that it's the default allocator for Android since I think Android 11 off the top of my head um and so that's why you're going to see it used if you have memory corruption on Android you're going to probably need to be interacting with this um the motivation for this talk and why you're going to like hopefully sit through you know 30 minutes of me Ram Ling is uh these new exploitation techniques which I'll be uh showing off uh mainly uh with the Heap allocator you know you get allocated a heap and hopefully it's in the uh chunk region of like the Heap region of memory uh

however with uh some certain exploitation techniques you can get a chunk returned at an arbitrary address which is very close to just having uh arbitrary right anywhere which uh should hopefully give you execution control in pretty much any scenario uh the main way go about these and you don't need to know these buzzword yet but it's about either corrupting or forging uh secondary chunks or via smuggling in transfer batches uh there are some few extra T tricks provided but not like enough to be considered a full technique one thing to note is that uh these aren't really bugs in the actual allocator uh all of these rely on bugs in user programs which are making use of

the scooo allocator um but the reason reason why this is important is that like new situations are exploitable from uh certain like bug types uh going to run through a quick design overview because I must assume most of you have not dug through the internals of scooo before um one thing to note is that scoo is a highly configurable uh allocator um yeah so many options uh I'll be going off of the uh Android config found within sco's code because that's what I considered the most relevant um but on the platform or I guess how a given like person sets it up uh the behavior can vary uh significantly the first thing to note is

that the scoo allocator uh actually has two allocators the primary and the secondary one the first uh primary allocator is what will service the majority of allocations uh and the chunks served by this are small so like less than a page size uh we'll be mostly covering this allocator because it's got the main complicated internals of managing all of these like small chunks in a given page the secondary allocator is what is responsible for handing large allocations say like 64 kilobytes or whatever uh and it's essentially a wrapper over M map um so it's uh essentially a lot simpler one important thing to note when handling the secondary allocator is that all chunks have like a primary header which is

needed to store metadata um but the secondary allocator also has a second additional header uh which is important for exploitation with it later um now the security approach uh there was a recent article by trenchant and I am stealing this uh slide from them because it was very well put but essentially a large uh I guess categorization of how scooo approaches security against memory corruption is first off a lot of randomization SL nondeterminism a lot of like shuffling and like essentially based on the same idea as like aslr it's like without an info leak and that sort of uncertainty you either have to like brute force or you might like fail typically um some things in this uh

which you'll I will cover soon are guard pages and uh shuffling chunks when allocating them uh secondarily is data Integrity to try and detect memory corruption um each chunk will have a Chuck uh a check sum uh and when corrupted will like check against that and that's the main example of uh you know Integrity checks to try and prevent uh userland like uh malicious actors from just corrupting memory freely all right now onto the actual internals uh first thing to note is that the scooo allocator has regions for essentially size brackets so each region will Service uh a given like range of sizes say like 0 to 32 bytes uh 33 to 64 so on uh one one important thing to note is

that we do have a special region which is region zero uh this is only used for allocating structures that the uh allocator uses internally for like you know handling stuff um and so a user allocation should never come or like end up in there if though that is a very uh you know dangerous thing uh onto guard Pages which is the first example of I guess randomization SL nondeterminism security um each region is I guess like a block of virtual memory but they also have guard Pages uh guard page is just uh a page or actually several randomly chosen from 1 to 16 uh of virtual memory but it has no memory protections so any sort of access

to it will cause like a seg fault and your exploitation will probably fail prematurely the main thing that this does is to stop uh contiguous outof bounds access so you can imagine like a very classic like get S vulnerability you're just like filling up uh your buffer contiguously and you'll eventually bum bump into the guard page uh before being able to grr upt stuff in a different region uh however uh say if you could have an outof bounds access where you control the offset you can jump over these guard pages and corrupt different regions however because the number of guard pages is randomly chosen from 1 to 16 then you either have to conservatively isue that you have the

maximum number and that might you know cause difficulties in trying to Target a specific thing in a different region or if you don't assume that you might risk bumping into a guard page and and crashing the next thing to note is that uh regions are shuffled during initialization uh and what this mean what this means is that region one is not necessarily after region zero uh and this again goes into like if you're trying to Target a specific region but you're not allocating in it uh then you don't know if that region is before you in memory which might not be accessible if your type of bug doesn't allow that access or even if it is after you in

memory like how far away is it yeah and that's a general overview of like regions which is like storing the uh memory and the chunks for the primary allocator now on to the sort of like allocation uh process uh so essentially you can imagine like malok for like 100 bytes or however much um the first thing you do is you translate into that given Regional class because each one uh corresponds to a given size bracket uh then there's a lot of like caching and I guess Fred local stuff to prevent locking because locking is the devil um essentially you you retrieve a chunk from a cache called uh the struct is called per class if you cash Miss

essentially there's no chunks left then you have to refill a cach with a thing called a transfer batch and if there are no more of those then you need to uh essentially carve up the like free virtual memory in the region to create new uh chunks to use uh then lastly you attach a header to the chunk and return it uh going through that in more detail this is this first step and you have a sort of diagram up here showing one possible translation between sizes and classes once again it's like very configurable Um this can be adjusted however you want and yeah each Fred uh has its own cash for allocating not technically true if you allocate like a

thousand Freds they do share some caches but the goal is to prevent locking so yeah uh this cache that uh I call is a struct c per class uh it's very simple you just have a field for count which is how many chunks are still in there uh and then an array of things called compact poters um another security I guess quote unquote like mitigation or like conscious decision is that uh essentially each chunk is associated with a given region and the internal allocator knows that Region's uh start address so essentially uh each chunk when you're storing it in the cache you can just store it as an offset from that region start and also there's a u42s

rather than uh U 64s uh that does mean say if you corrupt uh somehow this cash then you can only store chunks based on an offset from the start of the region uh which might not even be enough of a distance to say corrupt like a shared Library as opposed to if they just store the full pointers then you can get a chunk anywhere if you corrupt this and yeah just allocating from this cache you just index the array via the count you get the compacted pointer uh decrement the C of course and then you decompact it according to the region start which is just like the region start plus compacted pointer uh with a

bit of bit shifting like I said uh caches can have like cache misses uh so what if the cache is empty uh then we have these structure called transfer batches which are also very simple also very similar um they just store compacted pointers for that uh region they count how many and they also form a linked list um these are stored in a struct called region info which store a link list of them uh and then when a given cache needs to uh you know refill it it just gets the first off of the linked list and gets the chunks from this batch into the uh cache it's literally just like a M Copy like

yeah like yeah like I said you have the unpadded region uh structure uh with this free list sing you don't need to read this but it's just showing yes we pop off the front of the free list uh and then uh getting to the end of allocating the free list may be empty of course if we keep allocating and allocating pop off and off free list and then there won't be any left uh we then call populate free list which essentially creates transfer batches from the free space in the region uh once again uh security conscious decision uh when we're creating transfer batches we're essentially cutting off like chunks of virtual memory um but we're not doing it in a contiguous

manner like we figure out how much virtual memory we want we split it up into like you know the appropriate chunk size uh but then we Shuffle it around so that uh once again if you have two allocations from these like allocator you don't know if they're going to be contiguous in memory which then poses issues for like uh even if you're just doing overflows in a given region uh trying to Target a specific uh chunk that you might want to corrupt though you know hip spring still valid of course uh this uh is another diagram which is just from The Amazing trenchant article hopefully this helps clear things a little bit up but yes you have

this per class um cache the transfer batch which essentially uh is used to refill it which is coming from this region info structure cool uh and then uh like I said you obviously need to attach a chunk header to a chunk before you like give it back to the user uh there are six Fields uh the two main important ones are the check suum and the state at least for like security conscious reasons the check suum is a cc32 uh formed from the header contents which uh should be known to the attacker the chunk address and a global secret decided initialization now uh if you corrupt this check Thum and you're trying to forge a malicious header then uh when

the allocator uses this chunk at all it will will do an Integrity check it will calculate the expected check sum and match it against the check sum in the header and if there is a mismatch then it will like error out like abort die Panic um so to forge checksums you typically need uh two of those free uh most likely the trunk address uh then uh second is the state um which is either allocated available or quarantined uh these are sort of related to Lifetime of a given like variable or chunk essentially at any given moment in time it should be in a given State say if you've allocated it you can probably guess it should have

the allocated state in the header uh what that's preventing is say if you have a double free when you free a chunk it will be marked available and you free the chunk again it will see the chunk is marked available instead of allocated and it will once again uh Panic yeah so that is attached to the chunk it's returned to the user for you know general purposes onto freeing uh so the overview of this is that there is that sanity check that it's the uh allocated uh then we decide to quarantine it or not I'll explain quarantining shortly uh we then get the regional class from the size and the header put it in the cache uh and if the

cach is full we need to turn some of the chunks in the cach into transfer batches here yes the state should be allocated or it will report it then we decide to quarantine it the quarantining decision is a is the quarantine enabled at all uh B is the chunk uh too big even in primary or C uh this slide says it's a trunk from the secondary allocator these are admittedly slightly old from when I was originally poking at it so maybe by like a month or two um recently a quarantine for the second secondary allocator has been introduced uh won't be too relevant to any of the exploitation techniques I think um but yes technically you can Quant in

secondary chunks so yeah uh assuming of course that we don't quarantine it then you get the Fred local cache uh you figure out the class of either the size and then you uh take the pointer you need to compact it according to the start of the region of course before you store it in the array but then yeah it's just indexing into the array storing the compacted pointer increment yeah very simple uh if the cache is full then of course you can't keep um putting chunks in there so you need to call uh the function which is allocator push blocks uh what that does is it will take typically half of the chunks in the

cache form transfer batches from them uh and add them to the appropriate region info once again this is just the inverse of the diagram taking shrunks from a per class to create a transfer batch and store it in the region info uh onto quarantine uh it isn't the most unique idea it's not like it's pioneered it but essentially a quarantine is that occasionally we will delay a chunks availability um memory allocators typically want you know like memory reuse you free a chunk it immediately gives it back um however for bugs like use after freeze that's a very nice behavior to exploit so instead what scooo does assuming you uh enable the quarantine is essentially um oh also one thing yes uh performance

memory footprint penalty uh any Chunk in the quarantine is not being used for anything it's just sitting there and performance penalty for any like handling of the quarantine that's needed yeah so the uh overview of the quarantine is that once again Fred local quarantines because we hate locking uh what those are is a linked list of things called quantin batches those are a very simple structure which is essentially glorify array of chunks and a count of how many chunks and a size of how much memory this given batch is quarantining now of course with the quarantine we inevitably need to release chunks from the quarantine back to being freed otherwise we would never reuse memory and that's not exactly the best

choice for an allocator um we have also a global quarantine so when a Fred local quarantine is storing too much memory its footprint is too big it will just attach its linked list of quarantine batches to the global quarantines list uh that quarantine can also end up becoming too big uh and then we start deing batches from that until we're happy with the size and those deced batches get properly freed this uh is taken from another amazing article by people called UNIF um but yes you see the global quarantine these quarantine caches which are the Fred local ones but also Global one has one and these batches which just have an array of pointers a count and a size

post their link lists so how we actually end up entering the quarantine is yes when we're freeing a chunk we uh decide with that bypass quarantine sort of variable um if quarantining we initially put it in the Fred local quarantine with quarantine dop put which essentially boils down uh very simply to refine the quarantine batch in that Fred local quarantine the one at the end of the list and then we just index into the AR array store the pointer uh increase the size to update the memory footprint then uh on release the uh put function May if the yes Fred local quarantine is too big call drain um and yes what that does is this list append

back which is appending to the global quarantines linked list um the Fred local quarantines list which then completely empties out the Fred local quarantine similarly like I said the global quarantine may end up too big uh which we may start to recycle the global quarantine um here we essentially just do a loop and we DQ batches mainly here um until we are happy with how many we've dced um and dqs uh call they end up in do recycle which just call De allocate on every uh chunk cool that is um an overview of the uh allocator uh of course there's going to be missing details uh if you are interested it will be better to just of course Deep dive in

yourself and properly like Croc everything but now hopefully you're ready to understand the uh related research um some past research uh Sy there uh you might know him uh did some research on uh cc's in the header which is yes about having uh that header check sum which tries to prevent corruption with Integrity check uh the motivation is that you want to be able to forge check sums to corrupt headers um and this what the article was mainly about uh knowing the content headers which you should know given you're the one corrupting it uh and if you have an info leak on the Heap for that chunk then you can um it's like with the free leak the cookie value um

and then if you have all free or even just all two you can um start forging check ons uh next is this group called UNIF fuzz or unwan fuzz I'm not actually sure uh which is focused on corrupting those quarantine batch structures uh the reason for that is that uh the quarantine batch structure is used internally by the allocator for storing stuff like for working of the cartine um however uh it doesn't end up in it's not allocated from region zero it's uh allocated in regions used by um Noble data as well um and that's because of like internal details um but because of that it makes a very attractive choice that um if you have an outof bounds

access in the region then you don't need to deal with stuff like guard Pages or a lot of that you can just say spray a lot of quantin batches then overflow and corrupt one uh the techniques they developed with that were to get a chunk to be returned twice you know the same chunk um and that's pretty close to you know you can cause like type confusions with that um the other one is uh an almost arbitrary uh address chunk return so like return a chunk at a quote unquote almost arbitrary address but it did have some uh I guess pretty decent limitations and then a fast un quarantine which uh yeah that's not really a proper technique but

yeah um I won't be running through the double return because it's not relevant to uh this talk specifically um but I do have some improvements on the arbitrary address return later so I'll do a quick uh run through of how this uh sort of works like I said we're targeting the quarantine batch structure um we have the count variable uh when we're adding a chunk to that quarantine you have the uh you're indexing into an array and throwing the pointer um now assuming you can corrupt the account for that quarantine batch then you have a right pointer where primitive uh important to this is that the pointer is a chunk which you can assume you control with uh

like data where you want now getting into a lot of the internal uh like details of structures uh this long structure called size class allocator local C cache um which handles a lot of well you know the local cache uh operations uh has a allocator variable and this is just a pointer so uh essentially if you boil down looking through the source code if we control this allocator variable then you control a large part of cache Behavior Uh mainly you control uh the transfer batch lists uh so you can essentially empty out a cache uh call The Transfer batch to come into that cache and you allocate a chunk and then you know of course you control

the transfer batch so you control the addresses and you can get that most arbitrary chunk um here is the size Class allocator 32 uh or 64 they're very similar uh you can actually see it here but in the size class info array that's where it's holding the link list of those transfer batches with the compacted pointers um the main thing is that you figure out an offset from quarantine batch the one that you've corrupted to the cach structure um you overwrite the count count variable accordingly then when you free uh that Forge chunk which you control and you've made to look like a size class allocator of 32 or 64 then you've corrupted the cache uh allocate

and once you get that transfer batch those chunks into the cache then you have an arbitrary chunk address um however because the compacted pointers uh they are limited in that they're based on the beginning of the region like offset um so yeah you might not always be able to escape the Heap if the maximum like uh distance you can get still places in the Heap for example also there is um some randomization in uh guessing the distance from the quarantine batch to the uh cache so that can also go wrong uh onto the new methods I guess the the main part of the talk uh this is forging transfer batches um I guess to motivate you listening to me I will do a

quick demo which hopefully Works given that I have uh oh cool password ah one wonderful now everyone has access to the special infos laptop um quickly looking through fake region zero yes I remember what I name my files oh goodness this is quite large but hopefully you guys can read it to a decent degree now I won't be explaining this in detail until you know I actually run through it but essentially we uh we'll allocate a chunk we get the check thumb here uh you want to free the chunk so that it enters quarantine as a normal chunk then we calculate a new state which is uh still quarantined because we're Curren and we don't want it to

complain about the state um but we say it is in region zero um you then calculate the appropriate check sum and you corrupt the header accordingly now it's in the quarantine so you need to get it out of there the best way to do that is to free and allocate a lot of memory so you do this enough that it um flushes the uh now corrupted chunk um out of the quarantine into the region zero fre list now region Zer is for transfer batches so when a transfer batch needs to be allocated it takes it from the um well freist SL I actually meant cach of region zero which is what our chunk is so now we have a

chunk which we can uh presumably corrupt with like an outof bounds right assuming we've already corrupted the header if

if we corrupt the count variable of the transfer batch here then essentially uh when the transfer batch is uh called refilled on the given cache the uh per class which is the cach where refilling has a fixed offset from that uh size class allocator local cache and so the allocator pointer so you don't need to uh guess the offset like you do for a quarantine batch here we have the fake allocator which we' forged and this is the correct offset from the given cach uh overwriting to uh corrupt the allocator pointer then importantly you set this next thing to zero which will be the uh actual chunk returned by the per class uh when it's

done refilling then of course we want to get a chunk in an arbitrary address so we have a global Target which is in the BSS not in the Heap and we set this now the main uh difference is that whereas like unifos would uh say corrupt the transfer batch of linked list which are compacted pointers um for region infos you actually also have this field called a region beg or region beginning uh which is what you compact pointers and decompact point is against so of course if you overwrite that to uh the place you want a chunk to come from from then um any chunk would be compact like based as an offset of that so this

zero up here we saying you know no offset from the target which is region beginning and when that chunk is returned uh then it should just be pointing at a uh Global Target uh I've run the export command here to set options right um one thing to note this can take some time so you'll listen to me ramble um this exploit does fail some of the time for some re reasons I'll get into in the sides properly so oh wonderful one failure it should have a 50% chance to succeed let's see okay if it it might just be broken because I have had to uh move it from my own lap from my own laptop to here which

is very tragic um okay just pretend it worked for me please thank you thank you this is the overview I just talked about yes so the region the reason that we uh free the chunk and then corrupt the header rather than corrupting the header to get it to region there initially is that when deallocating a class ID of zero is actually associated with a secondary chunk which we don't want a chunk to uh go to so first we must free it it enters quarantine as like a normal chunk and then make it uh crop the header to be region zero uh like I said um quarantines can only have so much memory in them like

footprint wise reason um So eventually it starts deuring these quarantine chunks and it will see oh region zero I'll add this trunk to the region zero free list um this should not happen uh the region Z chunks should never be in quarantine but it doesn't have a check appropriately for it so it still works and then yes um when you need a transfer batch created uh it obviously comes from the region Z cache which our chunk is now in um yes the warning and which is why I think uh that demo was failing is that um with region shuffling right um when our chunk is added to the region zero free list it is compressed now if the region which the

trunk is coming from is um be for region Z in memory then of course that would be a negative offset from the start of region Z now it calculates that and it stores it um however when we later sort of try and access it this will cause like hideous issues for um you know allocating and it will like Sig sag vult and crash and your xlo will fail and uh assuming uh I somewhat understand math uh there is a 50% chance of this happening because if you're sort of just shuffling randomly there should be like a a random chance that is it before region Z or is it after region zero I think someone someone good at math can

correct me but I hope I'm right right um yeah so assuming we now have that transfer batch and it hasn't gotten mad at us then we corrupt this count variable and then yes this uh structure you see here the size class allocator local cache um we have a array of per class which is the uh cached structures you can imagine that this array you just know at compile time then you have uh stats variable we don't care about stats and then afterwards we have that allocator pointer so for whatever uh like per class like cache or overflowing you know the offset to the allocator pointer and like I said um we set the uh Forge Chunk we have to that allocator we

then add another zero after WS because uh when we actually returning a chunk we want no offset from our region beginning so we set it to zero as our compressed pointer yeah um this refill function which is doing the job of actually corrupting the allocator pointer um I commented before that it's a M Copy uh if I remember correctly it literally is this B copy to array boils down to a M Copy uh and you can imagine because we control the count it just blindly trusts that and starts destroying all of the uh caches before hitting um the the allocator pointer um and then yes we control size class allocator which I've got here like

I said for the uh appropriate region which we're allocating from we can set the region beginning uh variable and that's what we can press against you can see here with' compact pointer internal it's based off the uh base which is region beginning and yes so that trunk of zero is compressed against region beginning uh and a trunk is at our Target uh I'm going to run this like two more times um like Channel your energy so that it it works

TM oh this is like a fast this is an ex oh wow thank you challing challing the energy yes demonstrates that my research actually is valid um okay I I said earlier uh about improving arbitrary return uh that is mainly because yes they choose to Target the transfer batches which are compacted pointers um but if they can hit the size local allocator cache thingy and ver the allocator pointer then you can just set the region be beginning and then they can have arbitrary trunk return with their technique too um also that proof of code could do with some more Heap spraying but that's up to them and it's kind of just self-evident to fix that uh now on to uh the the best know

second best technique and it's much less technical but also much better is corrupting secondary chunks now I said earlier that secondary chunks have an additional header compared to the normal one and you can see that here with like prev next Double link list a commit base a commit size and whatever else commit BAS and commit size are the two we the only two we care about essentially if we overwrite uh commit base then we can map chunks anywhere and you can see here the alak PA is based off commit base and commit size which are just taken from here um I will note that yes the secondary allocator is a wrapper around map however it does cach um I guess like

these MMA chunks because it doesn't want system calls so yes we free uh an M mapped uh block and it will be uh cached to be reused which is why we can uh use this header and corrupt it this is the source code of the demo short enough to fit on the screen thankfully and you can see here with this big chunk uh which will be through the secondary allocator we override at these offsets the commit size and the commit base which is the target we want to hit free the trunk so that it's cached by the secondary allocator and we reallocate it and it should be at the same uh address and I'll demo that at

the end of this which is apparently now okay cool um one thing to note is that uh we're going for this target here um the header values are like written to an updated and that is Ox 50 bytes before if you taken both the primary and secondary header um and so say here this can't be at the start of the BSS region because before it will be read only so like for this to work we have this big array which will be written into that is I guess a minor thing to note like a minor um like stop Gap or thing uh it is corrupt large header it should be fast too yes so you can see here these two

pointers are the same which means we've gotten a chunk uh at BSS uh just going to show you the source code that I'm not just writing a program that prints the same address two times that would be fun um yeah back to presenting Wahoo forging secondary chunks the actual best technique now um essentially uh you might not be able to like interface with the secondary like allocated two easily sometimes there's like limitations on how like you can call the program to allocate so this aims to get around like a fair number of those um essentially we're going to corrupt a small like chunk we're going to set it chunk chunk header to region zero before we free it

so that it does go into the secondary uh allocator then we're going to spray chunks in the same region and Forge secondary headers into them and we do need at least one allocation that's like big enough to go through the secondary allocator so you can see here a very similar setup we have this chunk which we are corrupting with a check some which uh is saying that we're in region zero or a new state then from the same region we're spraying here uh this would be the uh commit base and this would be the commit size free that chunk and reallocate it with maloc and it once again should be at the same address uh okay free for free hopefully

um fake secondary it will take some time uh in some of these demos we uh have to corrupt check sums and that can uh reboot force them so it can take a bit but yes same addresses and I will once again show you I am not putting two print statements in yeah so you can see here no buffering get the chunk this is just corrupting the check sum spraying free and reallocate cool that is all the main techniques and then onto some additional cool tricks TM um the primary header does not have any pointers in it which is a very impressive feat and that makes it harder for like info leaks to occur um if you have like an outof bound

read uh however the secondary chunks do have pointers in them which means info leak one thing to note is that you either have to read before uh the allocated pointer you get or you have to read from another secondary chunk which means you'll be having to jump over guard pages but it is like a minor thing to note after they went through so much effort to not have pointed in the primary uh one secondarily secondary chunks are mapped in Via map map has this very fun tendency to put mappings before shared libraries don't know why um if you have outof bounds access and assuming you can jump over the guard page that is put at

the end of secondary chunks then you might be able to corrupt shed libraries without necessarily needing like a bunch of like leaks or offsets one thing to note is that like if you have lib sco uh which is the scooo library then you have a bunch of other shed libraries and they seem to be ordered randomly so might be hard to Target say lib C specifically uh finally cross cach chunks which is just a thing to note that you can corrupt a chunk header and um free to put it in a different region and then free it get it out of cortine and reallocate it this breaks the region isolation uh quote unquote so that you

can't like mix trunks of different sizes uh however it has the same problem as my first technique in that if the region you're coming from is before the region you're going into then it will just die and also after seeing the previous techniques it doesn't have too much of like a payoff uh some brief mitigation ideas uh I'm not smart enough to uh I guess talk about how to properly fix the secondary allocator um but at least from deallocating from quarantine there should be checks that you know if the region uh value is zero when you're like going from quarantine to deallocating it should like panic because control chunks uh assume to be valid control chunks and

the um allocator just treats them without going through quarantine CU you know they should never be messed up the allocator handles them um so yeah that check would prevent that technique it might slow down um when we're like moving stuff out of quarantine there yeah just a brief summary is that past techniques were that leaking of the secret with an info leak uh to forge check sums and the double free and The Limited arbitrary return via UNIF for corrupt via corrupting the quarantine batch and here we have like proper arbitrary return via forging SL and corrupting transfer batches or corrupting or forging secondary chunk headers and the additional things um resources here uh I'll just

ramble for a bit so grab your phones if you want to take a picture um this is the unifa uh unifa website Sylvia's uh article and trenchant article there are some just on like General uh like sko internals but they're not too good for my experience hopefully you've taken pictures where to find me uh I'm unfortunately on Twitter and also LinkedIn um if you want or just walk up to me and talk to me I'll ramble about this very willingly um but also I just have a GitHub IO which I will hopefully be dropping like a a Blog variant of this um sometimes soon if it's not there in like a few weeks just like DM me and

be like where is it give it to me cool and that's uh end of talk time for [Applause] questions great talk are there any questions in the

audience you had your Twitter up there uh what was your Twitter handle oh goodness oh that's a good question uh I think it's just the same it's ironica insist I think without the tea I don't think they they gave me the tea it's too long very tragically well if there are no more questions let's thank Zach one more [Applause] time