← All talks

"Attacks against secure heap allocators" - Silvio Cesare, CSides May 2020

BSides Canberra · 202027:30622 viewsPublished 2020-05Watch on YouTube ↗
Speakers
Tags
CategoryTechnical
StyleTalk
Show transcript [en]

this one's got a huge buyer so next week I think most people know is dr. Sylvia Cesare the managing director of info sect he's worked in technical roles and been involved in computer security for over 20 years including working in Silicon Valley in the US and working in France and of course Australia he's worked in defensive and offensive roles reported hundreds of software bugs and vulnerabilities in operating system kernels he used to work at UNSW Canberra sniper he's worked as the scanner architecture as a developer at koalas he is the co-founder of Bayside's camera and Seaside's he has a PhD from Deakin University a full-time black hat speaker done academic research commercialization and authored a book so we are will be

speaking next about heap allocators [Music] ensure you're not on mute okay well thank you very much thank you for attending virtually the first see slides and I hope that you enjoyed our dance talk and I do enjoy my talk as well and I'm talking about the tax begins secure heap elevators so memory corruption I mean it's mean the detective memory corruption every year for the past 15 years it's still a very common bug in systems software exploit mitigations certainly in the past you know 15 or 20 years have made exploitation less common than they used to be when everything was pretty much exploitable and you know what I said over the pomace 15 years you

know mitigations have increasingly raised the bar to actually deliver a working exploit people afraid is those things that are responsible for don't memory management have likewise also become more harm and more secure so we've certainly seen a lot of mediators in the past 15 years but they're very early safe unlinking in pto up to where we are today with many hardening techniques so this talk will look at some of the he pardoning techniques into ql lieutenants and looking at acts against them and how to bypass them so i'm going to talk about five things actually sent four things in my abstract but i'm gonna actually talk about flat because when I talk about pointy guard

in jelly bean which is the Linux default standard c library implementation booty loop see regularly a heap allocated but it's very much related to protecting pointers and memory on the heap so not always on the heap but protecting memory and pointers and there's variable later to the other attacks and I'll talk about I'll talk about the Linux kernels default pig allocated which is known as the school of allocator that's the default Linux kernel elevator I'll talk about hardened allocator call I say a lot I'll go back to the slob allocator cause we've got another attack that I want to talk about and then finally I'll end up talking about the pseudo elevator which is the allocator used the Android

evil and so quite a few alligators and I'll talk about individual attacks against each one of these elevators so we'll start off with plenty guard include we've seen now 20 guard is actually a mitigation it's the mitigation technically in G we've seen that they call pointy guard that protects against pointer corruption so if you have a winner and there's memory corruption and memory craft remote attacker over writes that pointer with something that they're choosing pointing out is meant to protect against them so you can't arbitrarily corrupt pointers and make them do other things there are other techniques one other after it's just iOS as one or a thin occasion and things like that that might

be another Smoove method to do this type of pointer protection but quanti god effectively works by scrambling the pointer before it's sorting memory ok and then when the pointer is used at these scrambles up and it uses an internal secret that it travels up with so you're not meant to easily be able to get this secret from an interest point of view it's actually part of thread-local storage they can't really easily access that this secret that is using this scrambling operation now pointing out mostly focuses on function pointers that's typically what it protects it doesn't protect all the pointers in GMC it pretty much does protects most of the function points not all the function orders you still found

plaintext function pointers in a process image like melons but we're going to talk about that and the idea of protecting function pointers with pointed out is that it mitigates the troll flow hijacking attacks so if an attacker overwrites a function pointer points points to the beginning of their rock chain will this stack if it all points to some sort of thing execute code well when he got protects against that it protects against an arbitrary write to memory and then check out would be able to use to override a function pointer with their arm treatment now if you looking at the G Lib C source since you'll see a bunch of references to point a mangle and point a D mangle it's

sort of pseudo code that I've shown but this is sort of one of course my pointer mangle and pointed emailing and the way that plenty guard works is the scrambling operation works by X or in the pointer was the secret that secret is sorting tread local storage and that performs a bitwise left rotation and tax 11 bits so that's that's the scrambling operation so explore the secret and then rotate it and D mangling is the reverse of that now the sort of the crux of this this mitigation is if the attacker knows the secret that the scrambling operation works with then the attacker wins they can mangle and that's okay can mangle and D mangle arbitrary pointers whenever

they want providing they have lavatory right actually been a very memory corruption but we're attacking this mitigation point again so the idea is to get the secret now if you just wrap again through G loop C you can start to see where quantum angling is used and there's one particularly interesting case in the pthreads initialization code which I'll show you in this slide hopefully you can read that and it basically says that in p3 loop CP thread in it which is some peace friends initialization code there's pointer mangling happening with a function pointer table I think there's a function pointer table that's passed to this initialization routine and then there's one in mangling occurring in each of

those function pointers now the thing that and you can defeat 20 God with is well if you know what pointer is being manually atlas of the point of that's been mangled you can recover the secret and in fact in part of this pthreads function pointer table we definitely know which function is being manual which which which function plan is being manly and if we have a loosely based leak then we know where that is in memory so we can reveal the secret so that's what we need we need an infant link to get the loop C base and then we simply say well we'll just take the address of this piece and absolute destroyed function and we can recover

the secret from point agon so that reveals the secret because we have a fixed we only have a function pointer that we know about and we know the action will address it that's not random it's a well known addresses it's almost like 20 texts yeah if we can make this attack a bit more interesting in fact let's wonder let's let's have a question now are there any cases in G Lipsy where it tries to mangle a non pointer or another constant like negative 1 okay so is there a fixed constant that's getting mangled by pointing on and it turns out as part of that piece right initialization code the first item all the second item in this array there's a

null pointer and that gets mangled so this is some known plaintext this is a constant that has been mangled and from that we can simply rotate our sort of mangled pointer and recover this secret and we can we can defeat when I dive like that if we have the ability to get an arbiter read and then so we need it in firmly but you know that's okay we're talking about memory corruption attacks and all of these mitigations assume that an attacker is able to corrupt memory and do something nefarious things in memory and it's trying to mitigate big sin on what they can do don't this type of defeat is known as a sort of a known plaintext

attack there's point in mangling of a non point out and we can recover the secret it's almost in plane tickets to begin with so that's point ago that's an attack on point agon and really you shouldn't be mangling these constants you know it sort of you know pretty easy these for a couple of the secret if it is the next thing I look at is Linux kernel seep a locator the default elevator known as the slug allocator and the slob elevator uses what so is free lists and friend lists are chunks of memory that are free that a part of weakness part of these free list so that they can later be recycled by the

elevator request memories Jesus what free list exists so the elevator can recycle the free chunk of memory without asking system memory for something so there's a well known heap corruption technique known as free was poisoning and it basically says you've got this free list me but these linked lists and these pointers in this linked list if you drop one of these one doesn't make a point to an arbitrary address well when the allocator recycles these chunks it'll return to you of mela and allocated no offer with the arbitrary address that a poison or corrupted the pointer in that free list length list so that's that's called free list was do it now you can actually turn this into an

arbitrary right committed from an it from an attacker point of view if you have application logic that what's attacker controlled data to an allocated buffer and you make that allocated buffer point to an arbitral location that's basically the same as of white what we are in the commentary black for minute so it's a very powerful limited and many heap exploitation techniques work around that principle member historically you could actually be do freelee's poisoning sort of trivially in in the linux penalty panna cotta but some years ago 2017 over lose i'm not that many years ago they introduced a configuration option to make free list hardening as a mitigation and so they've got this cloak here and there's actually a patch

that mitigates against one of this high seat naive friend is poison attack will simply overwrite one of these pointers with an arbitrary Atticus that will be returned by the Colonel jalapeno and the the key the scrambling function that they use they have sort of the sort of the same thing it's point and manually or deem Englund they use a scrambling function which takes the pointer excells that against a secret and then axles that against the address of the pointer and our attack we want to reveal the secret this is what we want to get we want to reveal that secret so that we can hopefully craft our own thang corrupt pointers and make the kernel

memory allocator return an arbitrary address now the inside of this attack is that in the Linux kernel pointer and pointer address pretty much belong to the same region of memory so they're almost bitwise identical and because you have that extra identity we XOR something with itself equals zero you basically come to the situation where you have one an excellent with almost itself which comes to zero excellent with the secret thus revealing the secret so in fact this stolen pointer in the free list if these frameless pointers is actually the secret stone is plaintext and if we look at the kernel memory allocator and this was actually done by K school and then Alice's are currently the blog post on

it only sort of waiting to patch this this particular problem if we look at the stored value that sword in that free list pointer it's almost identical to the secret value that is not meant to be known you know two-man attacker or all be plant accessing memory so hooligans kernel team acknowledge this as a weakness a main rotor pack to improve the security but okay she's not my blog post one external commit when they when they talk about this and now they use sort of the variation on that scrambling technique is why not application technique they take the point out they accelerate with the secret and then they XOR it with a Indian swap of the pointer

so they simply added that Indiana swap that's 164 and this is actually much stronger it's actually a much stronger as much stronger mitigation and much harder to to corrupt that pointer and make it you know do what you wanted to do so that's the attack on an external peep the next allocated on a look at is called bicep outlook and I say L Bach is a hardened elevator with many security medications ugly a very good Allatoona now they actually use a similar strategy for the Linux kernel slot elevator in fact they take the pointer they accelerate again it's a secret and they XOR it against the pointers address and I'd be told and I sort of can't verify

this that this sort of pattern actually came from gr security where apparently this bug at least exhibit this weakness existed certainly at least until a blog article about it let's look at the clue in I so color and we can actually see that there's this canary value which takes is be point of excellent against this address and then X was it against a secret and in fact when we print the value of the stored value and the secret all the highlights are the same so this is actually an identical class of bunk that we saw in a Linux kernel people look exactly the same but it's taking even a pointer X or neol with a plant

address bitwise identical they become 0 thus revealing the secret in memory so very interesting that we saw multiple elevators that have been hardened against one frameless poisoning at this same class of one or the same class of weakness so the IP male but water and why cell can eat all it took was the weakness and I recommended to do the same thing that moves from touch to simply use that Indian swap with that black water swap and I say I like implemented that change in less than a week after the initial report currently it's it is patched much like the Linux kernel patch and I talked about earlier so is that the end of attacking the Linux kernel if a locator

and a lock is there anything we can do that you know that we haven't talked about you know there any other attacks you know is real is poisoning dead now this is sort of a theoretical attack so it gets a bit out there I think it's a bit sort of it's a it certainly more and more exotic attack than the earlier attacks now equipped ography there's a set of attacks known as be flippin attacks any Lukla attack see basically takes some ciphertext which you know the plane takes off and then you flip some bits in this life to text so that it decrypt to whatever you want and you can actually do that you can want to find

the ciphertext even maybe you know the plaintext and when you know the victim D creeps the data it decrypts tilapias happen once that's called a flip and it turns out that in theory we can perform a similar attack on the Linux kernel deep allocator so there's actually some code in the Linux kernel it's unusual code and it basically says and you certainly need you need some recessions in the kernel to do this you need some point or restrict permissions to really on by default but it is there in the kernel there's some Linux kernel code that says when it tries to look at this friend list point up it checks to see if it's a valid pointer and if it isn't

then it warns you tis an error and says the free pointer this friendlist point is corrupt and then it also prints what it decoded to will be mangled - okay so it's appointed the manual Oracle we can basically pass arbitrary corrupt pointers to our friend lists and that D manual operation with our pointer D on the station operation we can actually see what it comes to so this is the attack that we're going to do all the least in theory it's a sort of a theoretical attack with some sort of verification it's theoretical really they'll take a free list point up and we've got memory options we're gonna clear up that free list point up with

the value of our choosing okay then we going to get the allocator 2d naval using ante mangling Oracle and we're going to note the result given only that that we've got a demon world point up from a point of that where you sort of corrupted we can do a bit flipping attack and using that we can corrupt the free list planner again making it to the mangle to an arbitrary address of our choosing so that's a big flippin attack applied to the Linux kernel heap allocator and to do this what we're going to do is we're going to corrupt the free list pointer with the value and we're just going to corrupt it with the value 1 and

we choose 1 not 0 because 0 has a very special meaning it's a null pointer so might sort of be sort of not work well why terminate whistles so forth but one is probably a safe thing ok so we're going to corrupt this free list pointer with 1 and then we're going to use that be mainly Oracle to tell us what it D mangled to now we're going to call that point 2 1 now I've got another chance at corrupting the same trailers pointer and we're going to take our target address exel that with one and XOR that with what adding mangling Oracle's Damus and this is our op the sanded pointer to we're going to corrupt the frameless

under with that and guess what when the kernel tries to D mangle that point it actually gives you the target address so it's a big flippin attack and I've got them like a small proof here showing the the sequence of next to operations so that you get your target address out of it but basically we need to corrupt the free list point on what's the value about choosing use that the mainly Oracle and then re corrupt the pointer and we can make it to mangle to any target address that we want so to put the attack it's a theoretical attack certainly in sort of with test data of works but it's interesting that such an

attack might be possible you know learning cryptography might actually be useful even to people to be memory crusher the final attack that I'm going to look at is the pseudo elevator and sciutto is a Highland alligator written and maintained by Google okay it's used in the Android easel and on mobile devices it's very easy to use to compiling you just use si lang and you pass that sanitizer word sudo and it uses a suite of free public beta now sudo does is the secure alligator tries to mitigate against mera question and one of the considered does to mitigate against memory corruption is that it puts checksums into mela chunk headers in an attempt to prevent an attacker

from forging their own fate chance we can't pass to free a faint chunk because there's a checksum on the header that uses an internal secret and a crc32 checksum algorithm to calculate that checksum so there's a secret that a cookie or 32-bits cookie that we don't know about as an attacker that prevents us from arbitrarily cranial on checksums only the allocator knows this this cookie and it uses a crc32 algorithm sort of a common checksum algorithm involving that secret involving the original chunk header you know sort of in a pseudo header and then it writes that new checks on to the chunkier so what we want to do ultimately we want to fake checksums ok we want to create fake

checksums and we also want their secret cookie and what we're going to do is represent this secure checksum algorithm including that secret value as a set of SMT equations so a set of constraints and we're going to assume that we have an info link but we're able to read one chunk header of a valid chunk okay so we have a neat phone link we're able to read a chunk here we're gonna represent the checksum algorithm involving a secret cookie as a set of SN T equations and then when you cast a solver to see if it can compute a solution for the secret cooking and if it does actually do this well we can crash correct Chuck's checksums on

fake errors using this secret cookie and this is a set of SMT equations represented in Python as entry and that's enough to represent the checksum algorithm it only does a crc32 checksum only on a few bytes for the it's not an arbitrary length amount of data so it's actually possible to represent this by effectively as a set of equations now we can ask SMT solver can we solve a solution to give us that cookie value that secret cookie value in fact we do get a solution in you know very quickly in less than a second and it's one of many solutions that it gives us and the solution that we get it's not actually going to be the real cookie okay there's

many solutions that it sort of can solve that make that check something valid but it's not you know the real hook effects used by the system but it turns out it doesn't matter doesn't matter that it's not a real cookie because they're a secret cookie collisions and in fact the secret cookies that we determine or compute are good enough to build correct check sums for arbitrary fake chunks so you know what does a feint chunkiness you know why we trying to forward chunks or build fake chunks well in many allocators if you corrupt the slice more than a chunk it up you can free that chunk and it goes into the wrong size free list or bin and you can

make the allocator believe that that chunk well that chunk header represent is much larger than what it is that chunk that it will also is much larger so a future allocation are quite large uses that even though it's much smaller and in fact that allocation overlaps because it's thinking that it's much bigger than it is it overlaps that adjacent chunk to the original chunk and an attacker can corrupt critical data structures overwrite function pointers or pointers themselves and do other things as well future work is the seat of such a text of possible on sciutto using these fake chunk but it's pretty good you can craft your own fake chunks given only one infant like 30 so i presented a number of

attacks against hardened elevators the mitigations in these elevators all the steam and attack earth is able to corrupt memory so on one so this is the basis you know you can corrupt memory you know you've got some primitives what can you do with the allocator and can you bypass some of the mitigations and defenses that they implement to prevent or mitigate against exploitation and it turns out we can actually do a number of attacks against a number of hotend elevators and bypass a bunch of litigations so that's pretty much my twitter name is there i also do training eating face sick that's sort of my full-time job i do courses on code review and beep exploitation

check out the website or ask me some questions in the slack them awesome that's great can you play the clapping Sylvie's great great so there are a few comments on slack sniff wanted you to know that we can hear you up the back

and then we had one question was about when you were talking about scrambling is that the same as encryption yes so it is an attack - sort of - it is like the encryption it's like quickly cryptographically secure scrambler and i use the words family and city encryption because in these particular cases you know the goal is to learn these alligators to be very fast and they really just want to scramble in operation they're not really cryptographically secure operations and that's why I'm using the word scrambling instead of encryption but you know in one sense you know it is trying to sort of in encryption or a house or something you know it's trying to be you know a little element

of you know how having a secret and not revealing it but they're not really encryption they're really more swim photography caitlin also observed that you did list your twitter handle before your actual full-time job so it was interesting to see the importance you placed on twitter versus your job it was quite funny that's great I mean you come come on to the seaside Channel afterwards I'm sure people have have questions it's always very caring that your research into that you into the heat alligator and other things so I guess this but that ends out our two presentations for tonight we did promise or do some great