It looks like you're having connection troubles. Reconnect now.
03/09/2020 21:02:34
36c3-talk-10706 Latest text of pad 36c3-talk-10706 Saved March 9, 2020 |
* 36C3 Prespan music *
Herald: OK. Please, welcome our speakers. Joseph and Ilya, who will be talking about how boot loaders are broken and how to sort of look into them. Please give them a warm round of applause.
*Applause*
Joseph: Does it sound OK? Yeah. So welcome to boot to root auditing boot loaders by example. Joseph Tartaro, I hack things for IO active and this is my second time at Congress, so I'm really excited to be back here.
Ilja: Hi, I'm Ilja. This is my 18 or 19 time Congress. Happy to be back here too. I spoke with you I think several times before and I'm very excited to speak here together with Joe. We've been working together on boot loaders last year and change. This is minus the NDA coverage stuff. This is some of the things we've observed and seen, some very excited to do this.
Joseph: Yeah. So the expected audience for this talk would be embedded systems engineers, security people who are interested in embedded systems and just curious security people. Just a caveat. We're gonna be quickly going through about like 70 slides or so. And a lot of it's just like examples of sea source code. So if you did not realize you were signing up for an hour of that. Feel free to walk out. We're not going to be offended. And another caveat would be this isn't really trying to to flex and show. Look at all the bugs we found. The purpose of this was to kind of show people, hey, if you have not looked at blue letters before, this is our recommended, you know, areas of attack surface that are interesting. This is probably where you should get started and some examples of nobody's really looking at them and they should start. So that's pretty much what's going to go on there now. So quickly, here's the agenda. We'll discuss, quote unquote with looters why they're important. Some of the common ones we looked at attack surface and our conclusions. So there's gonna be a wide interpretation of bootloader. So basically what we mean by that is anything that's in your secure boot chain. And if you don't have experien
ce with the
se or you haven't looked at them much, you can kind of think of it like from an operating system standpoint of user land calling into kernel space. You'll you'll have like kind of normal world coming into a secure world and stuff. And that's kind of what you're looking for is the those pivots and when they're processing, you know, attacker user controlled data. So why? Because they're, you know, critical for security. It's a key component of your chain of trust. And it's very obvious that a lot of device designers are a poor hardening and limiting attack surface. And what we mean by that is a lot of the devices we've looked at over the last year or so, you'll find devices that have like full network stacks, even though they don't need a network stack. You'll have a bunch of code loaded up to the handles file systems that are never expected. So it just doesn't really make sense why they're not limiting all that attack surface. There's also a huge under estimate of reverse engineering people just kind of assuming that there's no bad actors and nobody's really going to look at this thing. And and it's this hidden black box that we should ignore. And a little story behind the presentation is we're actually on a train, go into a baseball game. I was trying to introduce Ilja to the lovely game of baseball and we were talking about you, Boot and I pulled out my phone and we went to the UbuGetHub??? and in about, I don't know, 10 minutes, 15 minutes, we ran into like 10 bugs and we went, yeah, we should probably audit some of this stuff.
And kind of inspiration from a previous talk that was given at Congress where he audited a bunch of different BSDs. I said, why don't we look at a bunch of different bootlloaders? And so just to give credit where credit's due, we are not the first to look at any of this stuff. So this is a list of people that kind of inspired us. I've done really interesting work and we recommend if you're interested in any of this and you enjoyed it, you s
hould go, you know, check these people out and see see things that they have, you know, released and papers and stuff like that. So where are they? Bootloaders are pretty much in everything you have your workstations, phones, game consoles, your TV, you know, everything. And generally the security basically depends on this. So it obviously really, really, really matters. And so with that said, we basically started looking at these common open source bootloaders . So, you know, Ubu, Coreboot , Grubb C BIOS Cafe, which is Broadcom, IPixie and Channel 4. And we're just looking at what's on GitHub, what we will be downloaded. Obviously, in your real world scenarios, the devices that you have at home or go by and start looking at, they're going to be heavily modified. They're going to have weird custom drivers that aren't available. Things like that. So, you know, we're not we're not here to argue the likelihood of some of the bugs we found. We're not going to argue, exploitability. Have them. We don't we don't know if they're expendable. We don't. We'll for one rule. For one, we don't. That's not really the point of it. The point is to kind of show people and show designers what they should be concerned with and show interesting researchers that might be interested what what they should look at. So you boot is extremely common. It's in a ton of devices. There's a huge, very customizable config for all different sorts of boards and stuff. There's concerns for environment variable stuff. There's a super powerful shell. So sometimes he even shell injection concerns based on environment variables. It's it's pretty funky and there's lots of lots of drivers or tons of devices. So it's kind of a great first step of looking at something that kind of covers a huge breadth of things. And so the features of you boot that are interesting would be, you know, networks factored different protocol passing file systems. And they also will load their next stage images from like all sorts of wei
rd, like archaic things that nobody uses anymore. And it's just used by tons of devices.
And then Coreboot and I apologize, this is a little dry right now. Will eventually get to stuff. But coreboot, you know, it's more targeted towards a modern operating systems there. There aren't like legacy bios support it, actually. They took a methodology that other products don't, which is they're not going to implement features that they don't want to do. So if you're trying to do network building or something, you use coreboot to boot into guy picks a year or something. They're not going to implement that feature. These are used in chromebooks and obviously some of the interesting parts are come from Google. And one main interesting area is I sent them. And grub. Obviously, you guys are all familiar with this. The primary concern here is multi boot spec and they support just a ton of file systems. So that's obviously the attack surface to be concerned with. But the interesting part here is that there are UFC signed versions of grub. So that's kind of like a secure boot breaker right there. If you find a vulnerability that's in the signed version, you can now load that into your you feed in and exploit that vulnerability and and you're good to go.
--- transkritpion till 8:22
And then see bias as the default bios for key giving. This supports legacy BIOS stuff. So you'll see that this gets booted into from things like coreboot . This supports the TPM communication. So that's kind of interesting. And it's the compatibility support module for UFC and over IMF and then Broadcom Cafe. So this is used in a ton of different like network devices and TV shows and stuff like that. And the obvious attack surface, there would be network protocols, the network stack. That's what you'd want to look at, Pixy. This would be more or more network based stuff. Various passing and similar to GRAB, there's UFC signed versions. So that's a great potential pivot for secure boot stuff. And then finally, Tim, on a core, ther
e's really no introduction needed here. There's been a ton of great presentations over the last like 15 years. People will just, you know, doing doing everything to this thing. And due to that, since it's pretty much the most scrutinized one out there, it's really mature compared to everything else. So when you bash Tiana Core, realize that it's way better than everything else. So there's a lot of like implementations built on top of it, like platform specific stuff, Qualcomm's APL on XP, all things like that. So you'll have all these you have the base based on a to get to and then you have all the calls himself built on top. And then related to boot loaders, we have things like trusses on. And that's kind of where I mentioned you have like normal world and secure worlds. You'll have these interesting pieces of code that are running into those those secure areas that you're going to want to look for, you know, pivots into there so you can get access to secrets. And then and obviously from the host operating system, the the attack surface, there would be you can modify things like envy room so you can set variables that one the next time you reboot the bullet is going to processes variables. So and the slides more for reference later. You can get the slides or take a picture or something. These are just links to some instructions for building and whatnot. So if you wanted to start looking at these, you can quickly build a little environment and poke around. So just really quickly to go through, you know, the concept of secure boot, you kind of have your your chain of trust, you'll have the boot rom that will then verify and load various other starters loaders then verify and load the next thing and you'll sometimes have a TPM involvement. You'll have some trust on involvement and an OS interaction, stuff like the OS basically setting things like V Ram, which will set, you know, boot boot configuration software not so the boot rom itself is something you've probably s
een the talk by Cordy or you think earlier it was it's really important because it can't be patched. It's a hardware revision would be required if if vulnerability is found and and it's so early in the stage and you would basically compromise everything after it. That is where you'd want to go. It's extremely bare minimum. It does some initialization of hardware and memory stuff and then you'll find things like maybe implementations of fast food. So you have a USP stack. So that's obvious attack surface she'd be interested in. And then it will, you know, verify the signature of the next stage and then do that and then you move on to the to the next stages. And that's where they start. Realizing the rest of what's necessary in network stocks that some handlers and whatnot, and they'll basically just keep keep handing off. And then you run into things like trust boot in measure boot. Which is, you know, verification and then measuring, which is kind of more for for logging and whatnot, doesn't actually mitigate anything. It just kind of alert to stuff. So some some harder environments are a little different, like the secure world stuff. You'll have armor trust on Windows as retailers are a retail one, hypervisor stuff. And then, yeah, I'm basically repeating myself. And then eventually the the operating system that's going to get the kernel going to be loaded, it's going to be verified. And then eventually you start running and then you can have fun. So early observations is everything we've pretty much looked at. That's open source. There's no privilege separation. So if you were to compromise a piece of component, you pretty much rule everything. And what's interesting is there are some proprietary bootloader that you're starting to see, like Apple, for example. They're doing some some aspect of privilege separation. So if you were to to exploit a portion, you didn't necessarily control the world. And so right now, at least all the other stuff we looked at did not h
ave anything like that. But maybe in the future we'll see that. So this is the list of the attack surface that we think people should be interested in and focusing on. You have envy RAM file systems and files, all network stack protocol stuff, all various buses, you know, some MDMA and hardware stuff. The interesting thing about buses that we've noticed is that better designers seem to inherently trust anything that end users should never interact with. So they go OK and end user uses USP. So we should verify some of that. But they do a bad job. But an end user doesn't play with spy flash. So I just inherently trust an end user isn't to the TPM. So just if the TPM site is something, run with it and they mess it up a lot. So I envy your ram. These are the various environment and environment variables that can be configured, you know, for the next boot cycle. And like I said, it's basically processing of user controlled data. So if you start looking at some of these big letters, here's the interesting functions you'd want to look at, for example, and you you just kind of call for environment get and grep through and you see them grabbing enviroment variable and see what they do with it. If they're not doing this sort of validation, you're gonna hit a bug. And an example of that would be right here. You see there's an environment get for boot PCI. It checks if it existed. It will then do a stair length. And then just copy it directly into a buffer without validating that it can fit the buffer. And there's actually kind of funny. Earlier today we were like, hey, we should try to exploit one of these just to show it. So we we toyed with this one and, you know, just do a bunch of bites and it starts just kind of sending these weird packets over the wire and a bunch a bunch of BP stuff you'll see later on. You just have four packets of whatever payload we signed. But it wasn't very realistic. It kind of when I started getting into like the key MOU like network implementati
on stuff. So we. So we kind of avoided and moved on to a different bug. But as you can see, it's it's very, very easy for you to start looking at this stuff and being interested in and quickly set up environment and and mess with exploitation and and we'll get into it. But there's no mitigations. So as you see, there's a bit of a pattern here. Environment get hostname copy with star length such acts as 120 by buffer environment get a bit of stir, copy it faster. You know, it just keeps happening. This is kind of what we're were talking about. Just the quality code is is not not very great. This is what's funny is when we're messing with that boot PCI stuff. Earlier this morning, we went out, it's gonna be more involved. So it was like, well, let me just go find a different bug. You know, 10 months later, it's like I found a different stack smash. Okay, let's work on that one. It's just like this is a perfect example, the environment, the the variable, and then they'll grab the very first element of that variable as a length and use that as length and. And it keeps happening. So just a quick example. See this? So the the attack scenario of this would be you have a device you have under your arm that you can physically modify your physical access and this is kind of an example of the default and B ram. So we just draw, you know, if I'm a variable with 600 bytes and you'll see towards the bottom there's four bytes where we read through a function in there and that's the address. So. Just this had to do with a g f f s to file system loading, so you didn't you just do F a slut and it's such a good being executed. So this is. Sorry, I can't see. So obviously, if you've never looked at this stuff, it's kind of fun to play around with and you should you should start poking at it because why not? Screenshot sweet. Cool. Cool. So that was a few an attack surface, which is usually the most fun to play with programing just by flash of that may take a little fiddling. But in ter
ms of attack, surface and fun things to play with, it's, you know, as Joe said, often overlooked. And so it's easy to toy with. And so you saw all those Esperance deaths in. Mm. Copies and stream copies. So there's a lot of fun there. But obviously there's not just envy Ram, there's more attacks office to sort of a trusted environment and obviously one of them is a file system. Right. Because this thing needs to boot and it needs to find images and they are stored somewhere in your file system sort of brings order to that chaos. And so basically you need to mount your file system and often facets or not signed or technically checked or not. All of it is because before you can do that, you need to be able to read something. Right. And so obviously an example of a common files would be fat file system. If, you know, if your boot environment supports loading your USP drive and for storage, it's probably gonna be fat depending on the flash itself may have its own proprietary format or it may use X x2 or something else. But clearly the files still parsers. I mean, that's private tax service closely related is obviously the files inside of your file system right now, depending on what you boot environment looks like. Some of these files are going to be integrity checked, but some of them might not be right. And so those file parsers are interesting tax refunds. And if you read are looking for bugs or you're building a products, I would highly recommend putting these. And it's like starting with AFL is probably a good starting point. But we'll show some examples of some bugs we saw in certain in a number of boot loaders. So we'll cover X 2, we'll cover a bitmap splash passing one. I think the elements are just sort of examples of where there could be bugs, but those two will cover. So this is this is grub and this is grub X to grab X to. You know, this is a similar code. So it looks to file system and it goes, oh, OK, this is a simple link. How do I pass a similar link? An
d so of sibling says, Hi, I'm assuming I'm a sibling, I'm this big. And what Grub does is, oh, great. I will add I'll allocate that which size, but I'll do one more for no bites. And of course that is a classic integer overflow and the grabbing allocator actually returns a valid pointer for a zero size. So it's a perfect primitive. So you get a pointer to something that is of zero size and then it actually reads to the similarly content from the file system. It's who is your size buffer. And obviously that's going to cause memory, corruption and a primitive. You can't see it here, but a primitives real nice because that particular read function actually if if there is if it's if there is no much not more on disk it stops reading. So. So even though you can save read for gigs, you can make the layout. So it only reads let's say a thousand bytes or a hundred bytes. And so you have this all near perfect primitive to cause memory corruption. This is wasn t on a core for example. This was the bitmap splash screen parser and I don't know, you know the ending about bitmap internals. It's a very simple format, but basically you can have a four bit bitmap and that gives you a palette of four by four, which is sixty bytes. And so the idea is if you have a four bit bitmap, then has a 16 by palette. And so it goes and reads that 60 by palette except you you tell it, you tell it how big the palette is and you can say, OK, I know you're expecting a sixteen byte palette, but I'm giving you a two hundred six byte palette and it'll read it into a sixteen byte buffer. So that was broken and then for 8 bit bit maps. Similarly, it was broken the same way. And these these are just just the tip of the iceberg. There are many, many, many more. Just does not this did not take long to find. But let's let's let's move on, obviously. OK. Now that we've looked at some local stuff, it's a physical stuff. What about what about remote? You know, how how do we what is there? Right. Obviously, if y
ou're talking remote in the modern world, you're talking DPP. Right. So you need a DWP stack and you need have some services that you need or expose or that you have client codes for that you go talk to you. And that's but be a DCP and DNS. And, you know, I scuzzy and NFF and pure corporate. If you're caught net, you probably won't have IP SEC and then HP and HP s and TFT Pete. Right. And sure enough, you know, most loaders have code for this. And then you start asking, OK, well, what's what's the attack surface for these VIP if you implement your own stack way, good luck because you're gonna screw it up. But secondly, it's like, OK, well, if you look at these things, you take a step back and say, OK, well, really, this is all mostly TV passing. And so you go and look into like what it is sort of the things that go wrong. You the GOP TV passing and, you know, it'll be out of bounds reads pretty much everywhere and you'll see endless loops in lots of places and things like that. If you look at the protocols top of that, like the HP and DNS, you know, you can you have sort of your standard sort of network attacks where you'll see like least stealing or cash poisoning or things like that if you don't protect your I.D.. So if you've a static I.D., you don't validate your I.D. or you generate predictable ideas. You know, you can have you can have these kind of poisoning, stealing man and middle attacks. Right. And then thirdly, obviously, you know, the thing we really like to see is memory, corruption, bugs. You know, you do in a day. You take that raw data and you pass it. And if you do it wrong, you may cause memory, corruption, bugs. So sometimes overlooked. Interesting bug. I think in we're doing that, we're fasting is when you have information leaks. So there's this often manifest itself. I mean, Heartbleed, of course, was one example. It was it was a perfect primitive. But generally it's it'll be this thing where, you know, you end up generating some kind of pack a
s a response to something. And, you know, you you'll have done the memory allocation, but for some reason not initialized something. And so you end up sending unrealized data over network. So that's sort of the common things you see network sex in general. So if you are looking for these kind of bugs in a good environment or if you are building a product that does this, I would highly recommend fuzzing them. There are numerous interesting that were truthers. If you're looking for networks sacrificing, I would recommend Issac. It's pretty old, but it's still incredibly, incredibly effective. It tends to it tends to break most networks tax. So with that said, let's show some examples. I was so you boot, for example, this is the Uber DNS code. And if you see that, that's the design, that's the DNS I.D. and it's basically they give it a they use a static DNS idea of one for all DNS packets that they send out. So doing DNS man, the middle a you brute environment is extremely trivial. You you guessed that the DNS I.D. by saying that it's one and you are correct 100 percent of the time. This is Broadcom coffee and this is the DSP parser. And it basically has the sort of junk stack buffer where just needs to read something out of a buffer. And it goes and says, OK, well, give me the length of that thing. And it's a U.N. date. So that means it can represent 0 up to 255 and then it read 0 up until 255 into that junk buffer. So that's a stack corruption right there. If you then look at the coffee at DSP parser, it's very similar where in this case it has a five and twelve by buffer and then it basically copies the entire R X buffer into it. And this is internet, so up to up to fifteen hundred bytes gets copied into this 512 byte buffer again causing memory corruption. Obviously we're not done with coffee yet because it has such a beautiful code. So this is the coffee I CFP ping handler and this has this really cute sort of use after free bugger double double free where it basi
cally it sends out a ping and then it sits there receiving that. You see that while loop there and it basically sits there receiving packets until it finds the right one. But it also because doesn't have an ounce loop, it has a time out. And there's this interesting condition where if the last thing it looked was the back you were looking for, but it also timed out at the exact same time. It frees that packet twice, which obviously can lead to memory corruption. Again, we're not done with coffee yet. All right. There we go. Now, another coffee yet. So this. This is the I'd be handling coffee. And if anybody has ever looked at an IP header, which I would assume most we have, you'll know it has an IP header linked and total length. And of course, coffee needs to know this because it needs to know where stuff is. But coffee validates neither the IP underlings or the total length. So once you start messing with those, coffee blows up really fast. So that was sort of a quick overview of all the trivial DP and DP related bugs that show up in your bootloader. So but let's say let's say you've got that covered and let's say, you know, OK, what's what's the next thing? What more sort of network stuff can we do? And then, of course, what comes to mind is Wi-Fi, you know, eight of that eleven. And a surprising number of lawyers don't have it if you have eleven. So I don't know if that's sort of a sort of on purpose or just sort of. We didn't we didn't get to having this feature yet, but we will at some point and obviously love bugs when we implement it. But we did find one that has it and I'll get that in seconds. One thing I did want to mention is that if you look at to 11 like frame passing, depending on which device you have in particularly which radio, your device is using it, that you leave radios that do a lot of passing on the radio, in which case the stack is kind of covered because it's at least you hope it is where the radio does a bunch of validation. But then there
's a whole bunch radios that sort of you know, they take package from the wire and they just don't do anything and just pass it on to us. That's the stuff that's interesting from from a tax service point of view. If you're looking to attack the bootloader and not dead firmware. So, yeah, we looked at pixy efficacy. And of course, you know, anytime you do any kind of Wi-Fi stopped. The first thing you do is you you're looking for an SSD. Right. That's what this thing does. And, you know, it sort of has this steady buffer, which is that he can be up to two bytes. So that is 32, 33 bytes going to search you 30 plus 1. And it has this loop where it sort of goes over. I use that it gets. And then when it finds the right does the I.E. for NASA's I.D., it says, OK, we'll take this ife and it will do. Are you linked? Now you like the U.N. date so it can be up to two fifty five and it copies the SS I.D. i.e. in two days that buffer, which is one to two bytes causing a memory corruption. So that's a pixie for you. OK. So the next one, if you're thinking networking would be Bluetooth. And Joe and I have actually we've looked at proprietary bootloader that have Bluetooth Bluetooth support. Unfortunately, we can't talk about those bugs because they're covered by dozens, of course, agreements. And we tried really, really hard to find a similar equivalent in any kind of open source bootloader and we couldn't find one. So unfortunately, we can't give examples of sort of Bluetooth bugs in open source boot loaders. But I do kind of in general terms, talk about what we have seen and where we suspect the bugs are going to be if somebody does do this in an officer's bootloader. So to me, it prevents a new bootloader. So I'd also like if you're going to do Bluetooth in a bootloader, it's usually for, you know, HIIT device registers for keyboard mouse. This usually ends up being for consumer devices. But in general, if you look at a Bluetooth stack and you're looking for any kind of, you
know, passing bugs, there's three sort of recurring themes. There's three sort of recurring themes that we saw when we looked at the Bluetooth sex that we have. And this is if you look at the low layers like L L 2p carpet, things like that. And this is usually related to sort of frames and frame lengths. So very, very large frame. So frame can be up to about sixty five thousand bytes because the length is a in 16. And so if you create really much range like right up to the edge that tends to blow up Bluetooth stacks, you don't want as if you create very, very, very short frames, you know less than what something is expecting. That tends to blow blow up your budget stack. And then lastly, because L L to cap can have fragmentation, so you can have individual fragments that you will add together and every fragment can be X amount of bytes, but the whole thing can be up to six five thousand bytes, about sixty five thousand number of bytes. So if you start playing around with the fragmentation, we've numerous Boutros SACs have blown up again. I wish I could have shown an actual bug here, but I was unable to find any in the open source orders. So moving on to you as B, this is this is a prime attack surface in bootloader. Obviously, if you haven't followed the news in the last couple of weeks and months, this has shown up in a number devices. This is at least until recently I think was sort of under underreported or so. People didn't quite care about it. But to media as we stack is like the that's the if I anytime I look at a year below at a bootloader, my from my first start is, you know, in VM and number two is you as B. Right. And usually is interesting because obviously a lot of bootloader support is B because they'll use it either for storage or, you know, things like Egypt uncles, but often for storage where, you know, either you expose certain files or you try to do some kind of recovery boot from you as B or something like that. Right. And so basically, if you sta
rt looking at you as B works at a slight lower level, it's not quite like it's not like like PCI, it's more packet based. And so what happens when when a device talks to host the device is asked for quote unquote descriptors. And these descriptors say certain things about your device. And based upon the number of descriptors that the host asks from you and all the answers you give them in descriptive responses. The host 10. Figure out, like what kind of device you are and like what class you are and what functionality exposures and all these kind of things. And so a lot of these descriptors end up being passed and being passed wrong. And so generally we often see either street up overflows or double fetches because the way descriptors work is so variable lengths content, but the headers or predefined in the way it works is you first ask for the header and then based on the length the header, you ask for the thing again. Except the user protocol doesn't allow you to just get to the payload. You have to reread the whole things. You have to reread the header that you already had. And so in most simple taste, what happens is you go get the header, you allocate a buffer and then you go get the header and payload again and you overwrite your original header. What meet? Which means that you get to override the original header lengths. And so you can have a talk town where your device gives you a header with a good length and then the second time gives you the scripture with a bad link. And if your host doesn't validate that boat lengths are the same. Bad things happen. And he sort of straight up over those happened to him because nobody ever expects you as B device, as an example in grub, for example, where it goes and gets a descriptor and descriptor says, oh, here's my coffee, can't have this number of configurations. Go and fetch Dawson the script as well. And there's a predefined array of number of configurations that grub has and it doesn't correlate that with the con
flict count. It just always assumes the coffee count is less to equal to the array. And so if you have a malicious device and you say, hey, I know your ace or two bytes to two elements, but I'm gonna give you 64 configurations, it'll happily write 64 configurations in a place I can only hold thirty two of them. And exactly the same thing for number of interfaces. Tiana Core had similar bugs where this was still a core way to go and get a descriptor. And then the script linked says, OK, now go fetch me the whole thing and use that descriptor links. Except the original hub descriptor was a very small struct and the descriptor linked is a U.N. aid so it can send up to 2 and 5 bytes. And so that would have smashed memory and caused that corruption. And so as you can see here, the fix here wasn't actually out of bounds check, but just to make the buffer bigger because, you know, the link is you 8. So if you just make the buffer two and a 56, then any link to any links you give, it will will fit within the buffer. 1. Yeah. This is an example. In the sea by us where this is the classic double fetch where it goes and gets the header, doesn't an outlook based on the header and then gets the header again with the contents and it doesn't verify that config w total length is a safety net. See if GW total linked. And because I've verifications in there, whoever calls listing can no longer trust w total length because it could be invalid. And so, as I said, USP to me is one of the prime tax serfs is to secure a boot. And so I want to sort of very, very briefly mention two recent real world cases where devices got broken into because of use to be passing into bootloader. So this was this is a case of dying. And then to switch to the Tegra. This was done by the AFL overflow people about a year or so ago that basically, you know, you give it a length that's now validated and then a mem copy and that causes memory, corruption and then the recent iPhone checkmate. This is slightly mor
e complicated because it wasn't a straight memory corruption, but it was you know, if you fiddle around enough with states, it sort of gets out of sync and it has all these pointers that it's still considered to be alive. But the memory has been freed. And so you end this ends up what you use after free, but it is because of a sequence of user feedback that are being sent. Right. So that's it for you is B? Obviously a bunch of buses or almost any bus on your device. If if if your book chain uses it as interesting attack surface and this is spy, I mean, a spy flash can be trusted. SAGAL Oh, I see LPC even even your TPM, right? Even your TPM response, you get back from TPM can't be trusted because somebody could dissolve your TPM and pretend to be your TPM. And if you don't now validate the daily TPM, you end up with memory corruption. So this is, for example, what happened. See BIOS, see BIOS has this talks with TPM and it goes and gets this structure and Senate less than what it expects. And then basically they subtract some side of a struct minus less than what they expect. And so that causes integer overflow, which ends up with a really big size. And then that size is given to Malak and Malik internally, hasn't it, to overflow. So that really big sized and becomes a very small size and then they copy into a net causes memory, corruption. And so this is a combination of two bugs. Right. Ones were decided the wrong. And then secondly is where the Matlock has an internal integer overflow. And this is the this is the Malick internals of C bios, which I don't want to dove into now because it's pretty convoluted and complex. I'll leave this as an exercise to the audience to figure out where the overflow is. And techniques on it overflow because it's a bunch of shifting being done, but it essentially comes down to an it overflow. There we go. Yep. OK. So those surface attack surface that is interesting, but often overlooked on devices, except for you, fee is systematic m
ode. And I mean, there have been over the last decade and a half numerous, numerous presentations about estimate, attack, surface and bring in some handlers for you fee because it's an X 86 thing and you see this in goofy stacks and it was the sort of cat and mouse game where for years, you know, somebody breaks something in and you fix it and then somebody breaks it again and you fix it again and somebody makes it again. Usually goes, OK, let's have been a case for this. And has it gone on for like 15, 16 years? And occasionally people still find bugs, but by a large, UFO does fairly well now regards to as mishandling. There's some third party stuff that still breaks occasionally. But in general, they've got a handle on this. Now, what if you're using X 86, but you reemployment your bootloader and you don't use your feet? Right. Well, that means you're going to run into all the same problems you've had and you're going to screw it up and all the same ways. And it'll take you another 15 years to get it right. But I guess I guess if you were to try the first time, this is what Corboy does. And to their credit, they say, oh, we get input, we should range check it and they arrange access to do. OK, so now I talked about a bunch of buses. The thing to me that sort of separates that from from other things is when you do DMA generally, for as long as Army has been around, the idea has been DMA came off. Right. If you get DMA, then you know, that's that. There's no trust boundary. Obviously, that's no longer true. Right. We have I am use. And if you use them and then if you have a device that has this available, then old son DMA can be stopped. It can be contained, it can be regulated. And so it's no longer a sort of came over and you can implement a trust boundary. A few things there. A, if you are an embedded device and you're using I mean, you you are way ahead of the curve because not not that many people doing this. Right. You should. But it takes some effort. There's
obviously many different I am use depends on your architecture and sort of the board you have in all sorts of things. So Intel's GTD AMAs at SMU, M.D. has like a device exclusion and it's got a few other ones as well. But basically, if you use one of these, you can sort of DMA is no longer the game over now. I mean, that doesn't mean that, you know, you're in the clear. Once you defined the amazing the tax service, you have to defend it. And that's where you get some difficulty because you'll end up using drivers that have been written before. It was a trust boundary. And I mean, no one has ever written a DMA handler and we're trust. But when a trust boundary mind. Because because he was stupid, there's no trust boundary. So now what's done? If you start using the EMU, you have to go back and all your drivers and look at, OK, where am I doing DMA? And now I can no longer trust what it was in when I get back from DMA and I got to go validate all this stuff. But even if you do all of that right, which by the way, is very hard and you probably won't do it right. But let's say you do. Secondly, because you may now, Transboundary, anytime you open up a memory window for a device, you can't just open it up. You have to clear to memory first, because otherwise now you're leaking memory to a device. Right. So all these sort of new things sort of show up if you take DMA is a trust boundary and let's say you do that, right. Well, now you still have a dependency on you because you are assuming you use perfect when it probably isn't. Right. I haven't I haven't really gotten to this part yet, but I. What do my plans for a futurist to go look at? I muse and see if I can, you know, attack. I will use and then find bugs there. I strongly suspect there will be side channels and logic bugs and maybe maybe even somewhat imposition bugs. So bug wise, this is where it sort of gets designed. Right. So this is this is this is what this is. You ft today indicate you platform code where it
has to portray him. You are ahead of the curve. But if you look at the spec, there is no good hand over protocol from from you feet to the next stage. And so you feel basically boots up and very early, configure the item you and make sure that devices can't you can't pick or put arbitrary fiscal memory. And then it does all of its stages and then it's about the handoff and it goes, well, I don't know if the next guy supports I you. So it under undoes all the program. It does turns a thing off, opens up everything and it hand it over to the next guy. So all the you did all this work for nothing. And this is this is a spec bug and it's being worked on. And people Intel is very much aware of this. People at Apple to fix this for their devices. This is going to get fixed in the future. But given that this is done, has to be done by spec, you know, it takes a while because you get to get people to agree to it and then you have numerous different applications to implement this. And this is we're heading back over to Joe. Yes, so hardware, it's pretty much out of scope for the presentation. We did not look at any of this, but we thought it would be naive to not at least mention it to people. And what we mean by that are like glitching side channel, so look and stuff. And so with glitching, you have fault injections. And a lot of times people go after things like that signature verification stuff. So they'll basically glitch that part and then they'll start running unsigned code. And a recent example of some glitching was done by fell overflow for the peace forces con and I forget the specifics. It's been a while. Really, really good blog post. You should check out. But I think it went to like an infinite loop, like go to debug mode or something and would say that's not enabled infinite loop. And then there was glitch out of it and then it's initialize as debug. And so stuff like that obviously should be concerned with. Then then clearly a side channel with timing discrepa
ncies, power discrepancies, things like spectrum up down, speculative execution in general. Now these are where people are leaking secrets, going after keys so they can start signing their own code, stuff like that. And then Chip's back. And this is somewhat interesting because it's obviously only relevant for a very sophisticated attacker. It's going to be somebody who has very expensive equipment. They do things like copying these fibs and Sams. They can do things like optical ram extraction and get the boot rom and then start out of doing that and then, you know, find a bug and exploit it and obviously totally out of scope for the presentation. But one thing that's interesting about this is kind of kind of presently it's it's still you know, not a lot of people have this expensive equipment. But I think very soon you have people like John MacMaster and stuff who who have like a in their garage. Right. And so you're gonna eventually start getting these regular hackers in their garage that will eventually get this equipment as the older equipment becomes more affordable. And maybe that opens us up to two more realistic instead of people just kind of ignoring it and they go. I'm not worried about somebody with, you know, a quarter of a million dollars worth of equipment. Now it's turning into somebody who dropped 10 K or 15 K. And then, you know, a quick note on the code integrity. It's it's something that people mess up a lot. It's kind of hard to do, right. You have people that do weak or crypto. You have blacklist problems. And an example that is, you know, there's finite space for their blacklist. It'll eventually get exhausted. So when you have stuff like where I mentioned you have a signed Grubb, there's a known bug and a signed Grubb of honor that was released by Kaspersky. And if if that's not on the blacklist of your UFC platform at home, you can just load that up and then exploit it. And you just broke secure boot. And it's not going to get fixed until tha
t platform has an up to date blacklist. And eventually, if all this crap gets blacklisted, eventually that list will be for them and they can't blacklist anymore. All right. So it's it's a there's a concern there. And then you'll have issues where they they'll only sign like certain portions now, not a full blob. So you can still modify certain parts or sometimes you'll see they'll just check for signature existing, but they don't validate it. And I really, really dumb, dumb stuff. So conclusions. Obviously, this is the tip of the iceberg. There's a lot of stuff we didn't look at. And if if it wasn't clear, we did not really audit these things. We we literally would like chat with each other every day and be like, hey, we need to see bios bug. OK. Give me an hour. OK, I got one. I'll go check the box and then let's move on to the next one. We were our goal was to have an example of a bug for each list of the attack surface, an example of a bug for each list of the thing we looked at, and that was it. So once we found one, we stopped. So you guys should go hunting and have fun. But if it wasn't obvious, there's a surprising amount of low quality code. So it's kind of crazy. And it's pretty clear that not a lot of people are looking at this stuff. And one thing that that kind of sucks is you get to NDA. Hell really, really, really quick if you want to look at any of this proprietary stuff. So if you're interested and Qualcomm stuff, for example, and you want to get some documentation or look at it, you pretty much have to sacrifice a first born to get access to that stuff. Like it's just not going to happen. And that's that's kind of silly. So, you know, kind of like our. And a call to action is, you know, people should be minimizing their their image, their boot environments, their host host environments. You know, turn off features you don't need if you don't need a network stack, why have it? You don't need USP. Why have it? All you're doing is enabling attack surf
ace for somebody to to leverage and something that we see a lot, which is insane. It's like these little embedded devices that are running Linux and they have literally more drivers than are our desktop at home. And that's just like what is going on here. It doesn't make sense. You should really, really, really work on limiting the attack surface and really quick mitigations. There aren't any in most environments. There just aren't any. As you can see from the example from before, that was you know, I'm just from this morning, just really quick, you know, smash and, you know, over at the store, P.C. and and that's like there's no SLR. There's no no anything like that. Code for integrity, what not. But there's a link to a GitHub. And that is an Intel employee that had this has gone and implemented a lot of these mitigations that are moving in to Tiana Core. So they are way, way, way ahead of the game of everyone else because they're actually getting a lot of these mitigations, which is quite impressive. And you should you should check it out because it's interesting code. So kind of a call to action. We really hope that this was inspirational, too, to a few of you. If you've never looked at this stuff and it was always this black box that you weren't weren't weren't sure about, you should just start poking around. Go, go find the slot where we showed where the the, you know, build instructions were and go build some of these things and mess around and and you're going to have fun. And like we said, with no mitigations, you can work on some some easier exploit dev stuff. And that's cool. Right. But it's clear that a lot of people need to be reviewing this because it's clearly not happening. People should start fuzzing interfaces. Everything we kind of showed should have been found with with basic fuzzing. We're kind of at a point where I decide I'm just going to take like a teensy or something and and have it just, you know, do that. That classic descriptor, double FS
B, because I think we've seen that and like every ESB sticking like it, just like you just make a device and just start plugging it into stuff and just watch it break. And then obviously periodic reviews and whatnot. But yeah, that's that's pretty much it. Yeah. Well, thank you. Now we have about 10 minutes for a Q and A. And we will start immediately with the Internet. Thank you. Has the grub issue been fixed yet and mostly code unique to grub are borrowed from, you know, elsewhere. I don't think it's been fixed yet. And this was the this was from whatever the official grub repository it was. All right. If you have a question in the room, please line up at the microphones so I can see you. And now microphone number two. So let's say you want to make a more secure laptop. So you came into it. Take Paul would take a sitting cutter so that everything is complied in. No, no, no modules. But what about the text? A text surfaces. Let's say somebody tries to interrupt a line of why. Why did just booting five somebody that you maybe some somehow get in to make a maybe deem X has because you do somehow it's up here before, let's say Broadcom network device that has some special phone vowed to optimize the traffic or something and that this thing gets boffo over floated above what we offload and make some problems on the bus or something. Are you talking about attack surface from devices? Yes, a slight sensor. Yeah. I tell you what, you want to make a good system. So I think the best you can do if you have a laptop that you take cobalt and you take a Linux, that you're completely compiled without budget support, everything you want to have is in the aesthetic code. And then just boots and decoders and the corporate and so on in the flesh. But you can get a problem. Bye bye bye. Let's say some devices that just spit until your memory because they can do them a Mustang. Yeah, that's a that's a that's definitely concern. And that's what it is. We were like, OK, well if if if if
you do use DMA as it has been forever than that, then it's game over. Luckily nowadays we have IOUs. So you depending if which is where you are in and what part where you have, you can configure your device to use the idea of, you know, if you're doing that, then even if a certain hardware device is compromised, you can still try to protect, you know, your CPA, you and your host from the device by having the IO review that. I think I hope it answer your question, but it's about as good an answer they can come up with. So, so, so so this is the maximum you can do against some attacks. I mean, from from a device, let's say I want to make an extreme hot laptop that you use an extreme hostile environment. So, again, you want to make a hotter laptop that you use in the holster to buy. Right. I mean, I think that's the best you can do, right? I mean, you can go and look at your host west and look at how it passes the stuff that comes from the bus, because it'll be they'll be bucks there, too. But I think that's the best I think about it. Yeah. I mean, you minimized the attack surface as much as you can. Right. And then once once you have minimized as possible, then you just kind of hope there's nothing there. You don't then you don't need to code signing because you have everything in your flash or you need some stuff. Oh, you mean the stuff Rosen host? Yeah, I mean, you have it. And that's if you have a copy of the Daily News in the Flesh. And so everything that I have, that's I. And you maybe take this discussion. After the talk, because we have more questions. Thank you. Thanks. And signal angel, please. What is your favorite disassembling that you use mine and reverse engineering the bootloader? We didn't really we just looked at source code. We in a few places. I mean, it is pretty pretty. It is, particularly in this particular case. Most of it was white box, so we didn't have much except pretty exploit. We don't have much need for a similar I guess a little bit of
GDP in general when we do do reverse engineering. I mean, I guess I just might go to I've been playing around with kids draw a little bit. It looks promising has on do, which is nice. But those are usually an area for doing little except stuff. GDP is nice when you're doing debugging, but generally a microphone number one place. I have two questions. What's your opinion on the trusted sector? I'm I have to work with this and I'm a little bit shocked. It's a little bit over complicated. And the second question is, should we also question the drums? Because what I've seen is a special project. It leads me to believe that the Boudreaux is also very broken. And then there's the question if it's really necessary to heart and the other stuff. Right. Yeah. That those are just really good questions, by the way. It sounds like you're working on this. So. Well, your first question was what again? What do you think about the arm thrust, right? Yes. I like you. I've touched upon it in a few engagements, unfortunately. Anybody could create stuff I can't really talk about because it was covered by Lance. Yes, I see it. Where does this problem. But I I I share your opinion that there are some things in there that are troubling with regards to the boot roms. You're spot on. So, I mean, what we tried to brings up in a lot of the slides is if there is a bug there, you can't fix. Hardware revisions do a way to fix it. So you kind of screwed up. There are some designs you can do to try to minimize it. So you could say, OK, well, you couldn't enter your boot room in your boot drum. You could have a feature that allows for quote unquote patching to boot right where you can have a piece of something or storage. It could overwrite with the Boudreaux was supposed to do, obviously up until that point, whatever's in the boot drum still you can't fix that. But you can you can minimize the amount of stuff in the boot run that's not patched, Bill, but you can't minimize all of it. I mean, there'
s got to be some of it that is locked, burned in hardware and can never be fixed for that device. I'd love to hear of a better solution. I don't know of any. No, I was just going to say this kind of touches on when we send people underestimating reverse engineering, the kind of just keep it super, super black box. And that's a secret thing. And then, you know, when somebody finds a way to to dump a boot from this, they're looking at it and they just see, you know, a bug and just be just be stuck. And then the switch goes down and the iPhone or whatever else. Right. So so, yes, from my perspective, I would say it would make more sense to do more open, open auditing and get more eyes, see it instead of hiding it in the corner and and pretending like, well, it's OK because nobody's looking. That's that's at least my perspective on I know why why people are super, super secretive about it. But you need more eyeballs. So maybe if you've got the right context. My wish would be to get blank chips so I could flash them. That's my own drum. So I have a method to improve things and keep the tech surface minimum. And then there's going to be two other armed eyes on there that are circumventing everything you that you just did. So do we have more Internet questions? Yes. Are you aware of any good and maybe even free bootloader, Husam? I'm not not not not in this whole I did I mentioned a few places. So. If you're doing any kind of file based stuff and you can isolate it, AFL is, you know, that's to go to these days for network stuff. There's a couple of interesting ones like SRK and there's a Wi-Fi phasers and and I think there's some DNS positive things like that. So that works. I would say the best way, in my opinion, would be to pull out the interesting components that are doing the passing and the stuff you're concerned about and write a harness for that. So you don't really need to to try to write a phaser for that environment. You just pull that feature out and harness it
up and let it, you know, run on a bunch. Of course. Yes. I think lip fuzzier might be very helpful there. All right. Number two, please read. Producing the comments of such arrows by using another programing language like that would feature more secure things that compile time or doing runtime like maybe rust would happen if this other alternative projects that use other languages other than sea. I'm not aware of. So I think you're right. I think we can reduce the amount of especially the memory corruption stuff. I mean, if you switch to something like rust, even though I think on occasion there's some rust quarter case that shows up or something doesn't get called by the verifier. Those are weird quarter cases in general. Yes. I think you're right. If we switch languages to memory cups, a lot of memory cups, stuff goes away, but not everything goes away. Older design stuff is still there. Right. So currently doing well. So there was actually there was a talk by Andre of our Sunny yesterday or the day before where he's doing a go runtime for and as a as a base for an arm device. So this is an avenue that is currently in the beginning of being research to be worked on. I think it's interesting. I think it's a direction, one that we could go into. I think there's something there at the present time. It still seems a bit too early. And the other thing is that while it does reduce the number of bugs that are going to be there in particular memory, corruption stuff it doesn't like, there will still be, you know, your logic bugs and your hardware bugs and things like that. So it's not a silver bullet, but it could definitely help. OK. And we out of time, please thank us, because again.
