Playing Boot Battleship Game

arya yes okay i'd like to invite arya henner to the stage and arya is a fantastic security professional researcher at intel that's right by the way my sister also works at intel but that's not what i am why arya is here arya has been speaking and contributing to b-sides and other events a lot of the time i think last time i hung out with you it was the blue hat conference maybe two years ago so thank you so much for coming to the b-side tel aviv stage and arya is not alone he actually has a co-speaker so this is julienne bonjour julian bravo merci thank you so much for joining us and julian is also a researcher with

intel he's with intel ipass did i get that right intel ipass and i enter ipas is intel product security team intel has been a long time sponsor of v6 so thank you but this is a talk that stands on its own and thank you we also have a clicker for arya i just want to tell you one more fact about julienne maybe you can guess it from his background he likes wine tasting ooh very fancy here in tel aviv we can offer you gin vodka beer whiskey we don't have what whatever he said and malbec okay and now let's give a nice warm giggly afternoon humoristic welcome to arya and julianne thank you so much uh you went to the

last slide you have to go back the red one okay you're good very interesting our slides are reverse engineering themselves it's very interesting phenomena okay euler alert f5 please thank you

hi julia hi so let's start well let's start it i like this little computer yes this badge is run by a microcontroller it's a small computer with a processor core memory timers i o flash well even a display what's happening when i turn it on how is it different from more evolved embedded systems how and where this understanding is essential for us for you to assure the security of such systems that's actually what we are going to discuss today but first let's present ourselves so my name is arianel i'm a principal engineer at intel and i'm leading an amazing offensive security research team i have little more than 23 years of professional experience in software and

security engineering and on my free time i'm a lecturer at the jerusalem college of technology hi guys

and hello i'm julian noir i'm also a security researcher at intel i have more than 10 years of experience in vulnerability research i do purchasing reverse engineering exploitation and all these kind of uh funny things and uh talking about funny things are you shall we play a game today yes of course julia yeah during our coffee breaks we sometimes play ctf's thank you hi jc jctf but the ctf is finished so we need a new game so for today julia i propose that we play a battleship war and we know that there's no better way to learn than playing a game so the agenda for today we'll discuss first boot sequences from the most basic to more evolved ones

then we'll present you boot the hub bootloader and finally we present some new original attacks so back to our badge how does it start well at the beginning of the interrupt vector of the table is found the reset vector well it's a fancy name for just an address which will point to the first instruction to fetch and from there the processor will actually execute some code in the case of our little badge this will point to the beginning of the spy flash memory for our battleship game well i would say it's a raft there's no security there's nothing interesting to sing here so it's a really rudimentary game a good sequence but it's very very

effective there absolutely no delay from the moment we start it well it runs this application but of course it has some limitations for example it can be difficult or sometimes even almost impossible to update the image and that brings us to our second model so here is our patrol boat now we added a stage in the boot sequence there is a bootloader that is running at the beginning of the execution flow it is used for example in the case of the arduino-like platform all the families or others like the tiva launchpad here on the slide update the main image easily so serial or usb in the case of in this case the bootloader is just a spill a small piece of

software which resides in a part of the flash usually at the beginning but doesn't have to and the flash of the microcontroller it can write the application the rest of the application directly without using any other device like debugger programmer and this is really convenient since changing directly the flash memory would require extra interface and extra wiring but of course this says some bad influence on our boot time since we have some more code that is running before the main application sometimes it can be even a long time some device takes a few seconds to load and we still lack any kind of security because we want to assure that the code that is running

in our platform is trusted but since we can't make sure that the content of the flash is the one that we put including our bootloader itself well we have a challenge here yeah and before we move to the next model the destroyer let's discuss the properties we would like to add so the most urgent one is some level of resilience yeah indeed the the fact that all the functional code is in the flash is a weak point because it can it can get corrupted or change on purpose we know we may also need for more complex systems that nicely preview to the nicely integrated microcontroller that aria showed you previous previously for example the boot sequence should

handle some configurations of the sock or it may also be used to initialize peripherals that couldn't run the directly output without this this setup for example some i o clocks watch dogs sd card usb or even crypto accelerators and as i said of course we are here to speak about security in order to achieve these goals we need to add an element to our system the most common solution is to use a rom as an immutable first boot support it will provide us the root element to achieve our goals in this model the first piece of code is stored in and run from the rom its main role is to load the next edge you see on the on the

on the scheme found in the flash the bootloader it can also be used to recover in case of flash corruption and in some cases it may include the minimal set of configuration needed for example if you want to boot from a peripheral and of course adding another component to our systems comes with the price in the total cost complexity and the performance but this should be worth it now let's see how we will use this scheme to create a validated boot sequence today boot systems are more features like recovery possibilities network capabilities and many other goodies some as i said are even more complicated that we you are seeing now on the screen we have moved for from a very simple

patrol bow to something as complicated as as a nuclear carrier and higher complexity means more code so higher probability of bugs in this example the attack surface increases as code size inflates both the boot rom and the bootloader now comprises protocol stacks such as usb tcp or even even http or tls yeah yeah we jumped so far too far i think software what which slide number are you i'm 10 you're 10 how's that possible did you have a did you have a cut something i'm on the first secure boot well i'd like to present to you for the the first secure boot scheme that we have oh my god my bad so the main idea here

is that for each stage we will cryptographically validate the next one before passing the control the flow will form what is called a chain of trust due to the immutability of the rom we will consider the bootrom as the root of trust of this chain if an attacker would want to disrupt this chain it would need to replace the rom which is a lot more difficulty difficult and costly than just refreshing the bootloader or the main image or there may be other ways like finding a vulnerability but more on that later so well if this is so secure what can an attacker do so one example is to intervene in the middle of the process without breaking

the verification due to the linearity of some flow of operations it is sometimes possible to achieve what is called a talk to attack talk to standing for time of check time of use the attacker is switching at the right moment the original and valid image and just after the validated as a validator has finished checking the signature it replaces the access to the next stage with the log image this is for example what was accomplished two years ago by two researchers on intel would guard mechanism well of course the boot sequence or the boot flow of a modern pc is much more complicated than what we have seen more complex that what we have here but this id is

actually valid everywhere in this case they show that an attacker with physical access to the spy flash could intercept the execution flow and actually achieve code execution after the boot guard validates the hash of the initial boot block by the way one of them is now working with us okay so my apologies for that so as i said before so that like like i said we have uh the the the boot sequences have have complexified a lot and like like what you are seeing now is that some some some have got now recovery possibilities network capabilities and many many other things and and as i said we have moved from a very simple boat the boat patrol to

the most complex one of our game which is the nuclear carrier and as i said once again higher complexity means more code and higher probability of bugs so what i was trying to to to to say here is that we have we have increases the code size the the the attack surface because we have added a lot of boutique of goodies and and a significant amount of code to handle complex protocols such as http usb or tls and this can be a real problem if vrlab vulnerabilities are found in those pieces of code inside the rom because this would lead to unfixable security issues and one famous example of this is the nintendo switch fusion vulnerability

which affects the built-in built-in usb stack of the rom used for recovery were a memory corruption allowed to execute unsigned code so we are displaying now a non-exhaustive list of boot attacks it's not for you to read them all it's just so you have in mind that there are many kinds more than we are discussing today well after this introduction tour of the possible secure boot design and weaknesses we are now moving to the result of our own vulnerability research we conducted within the team on youboot but what is yboot iii can you please tell us more about this with pleasure so you boot well uboot is a very popular open source bootloader used in a huge variety of devices from

chromebook to game consoles setter box to ereaders network equipment and tons of iot devices even the spacex dragon cargo spacecraft and the falcon 9 orbital launch vehicle actually use it in space it can be used it is used as a first stage consisting of basic needs for the system like configuring the memory controllers and sdr but it also can be used as a secondary stage for example it is necessary for the multiple steps required to learn the modern operating systems from a variety of devices that must be configured in advance and many more things so for a moment we will switch to a whole game now let's assume that you have chosen this very solid architecture yeah

you have a boot rom a bootloader and a main image you have extensively reviewed your boot rom so that it doesn't have any known bugs it is rock solid and uses crypto only approved by your crypto experts and well your security forks tell you all the time not to even the wheel so you decided to use a mainstream maintained and up-to-date third-party bootloader you boot well is it enough let's understand what is happening under the hood so you boot stores actually the images well most of the time it's on the flash into a so-called fit format which stands for flattened image tree remember the tree using this complex format we which we will describe into more

details in a moment ubuntu first functionalities uh like loading multiple images well and of course what interests us a image signature verification for verified boot writing a feed parser is quite a hard task both from design and implementation perspective well indeed the ubud code needs to handle the passing complexity before being actually able to check the image signature and let's pass the control so let's be very clear this parsing of unauthenticated code or an authenticated data sorry is a weak point of this boot flow and an excellent playground for security researchers and now julia will guide us inside the internals of the feed passing of course i will so the fit is composed of two kinds of basic elements the nodes

which are the containers and the properties of those nodes which contain data this is what we call the tree view on top of this tree view you would access the nodes properties the nodes and properties through a path built using the node hierarchies and property names property names just like an operating system would access directories and files making this analogy with a file system we call this the path view what you see here on the right is the minimal set of notes a fit must have to support verify output you will notice that the valid fit is fully contained within a root node which name must be empty it must also have a node called images

to store the images the loadable images and the node called configurations to store among other things the metadata used by the signature verification process talking about various signature verification let's let's see now how the first step a month among three works in this step you boot fetches the signature value from the configuration metadata of the fig tree it decrypts the signature using the rsa algorithm and the public key which is assumed to be stored in a trusted location and the output is what we call the original hash which will be used in the next step in your boot only a subset of a fit file is signed when verified boot is enabled this is a

design choice to allow for flexibility to add new images to an existing fit without breaking the signature so this means your boot has to first figure out which parts of the file are signed it does that by retrieving the list here in red of nodes to verify then it iterates all the nodes of the fit from the beginning to the end and whenever a node's path matches one in the list it is selected and as it is comparing node's path this step is working on the path view and once and and once all the nodes are selected their content is hashed to produce what we call the computed hash and finally this computed hash is

compared against the original hash generated in the previous step and if both are equal the signature is considered valid and we can move on to the to the next step the final step number three is the loading step you boot retrieves from the configuration metadata data which signature has which which gesture has previously been verified as i said the name of the image it has to load then using the tree view it locates and loads this image from within the images node of the fit

so before we move on let's take a break and remember a few key points about ubud's verified boot so we we've seen that the the you the the ubud signature verification process is composed of three steps the signature fetch and the logic image step number one and three which are using the tree view and the compute and compare step number two which is using the path view we've also seen that the fit format is flexible meaning any anyone can add images and configuration to an existing fit tree without altering the signature as long as the existing pieces of data are not altered and this is by design we've seen that youboot is working on different views or different

somehow abstraction layers meaning treeview versus past view and we'll see later that this induces discrepancies and i will now dive into this in more details because we all know that the devil is in the details and now we are happy to public present for the first time our evil boot attacks the first one is called permissive name equality so in order to execute the signature verification u-boot searches for image names and corresponding configurations it is combining the names of the nodes in the different places but not in a consistent way the path view uses a string comparison well in fact this is just a mam compel the tree view on the other hand is using

a model using the atsign commonly known in israel as strudel to support another model called a device 3 node unit address on the right you can see what happens when we use the treeview comparison function the interesting one is the last one if a node doesn't have the strudel sign it will be considered equal to the same name postfix with this with a string starting with a strudel this discrepancy between the two views is what lets us mount this attack so for this attack we add to the fit table an entry a node for a secondary image as julian explained earlier the format allows to add a new section so so far no damage down but our new image is

called using the same name as the original one but we just concatenated a string starting with a strudel like this at something or at fake let's see how the u-boot code will behave when checking the signature of the valid er the valid partition so on step one the signature blob is fetched from the configurations entry this uses the treeview method but well this is not important because we have only one entry there

sorry yes sorry on step two the hash of the image to be validated is calculated well this is done using the path view method which is strict and matching the valid image so of course the signature check will pass right but on step three the tree view method is used again and so our fake node using the same name with the channel add sign string at the end will be used in place of the valid one so what happened well we just bypass actually the secure code and u-boot will pass control to our arbitrary code he has a kernel one fake in this case and so we just hit pretty hard the u-boot submarine thank you

that will be enough right but well since we are already here and julia made all the way to here so we have another one to show yes sorry actually it's never enough so yeah here we are again taking advantage of one of the discrepancies between the signature verification steps so the fit format specification describes the fit as being contained contained in one big node the root node which name must be empty the tree view in step one and three assumes this to be true regardless and thus uses the first node of defeat as a root regardless of its name on the other hand the second step of the verified boot check this explicitly as it works on the path view

but what happens if we build a fit file as you see on the right with two root nodes instead of one well this is exactly the idea behind the fake hood node attack so here an attacker is altering a site signed firmware by inserting its own code in it the attacker is duplicating what we call the genuine root node meaning the node that contains the whole original firmware with valid signature but with slight modifications so the duplicated node we see here in orange and we call fake root is put in the fit file before the genuine root node here in grey the only differences between the two are the new the new node has a non-empty

name in this example fake root and the loadable image it contains is is replaced by an arbitrary attacker controller and let us see now what is the impact on the verified boot process so during step two are you okay are you yes so okay during step two u-boot iterates on every node of the file trying to match each notepad with one in the list list of the notes to verify because the fake root node has a non-empty name none of its node will match since their password begins with the word fakers in other words it is completely ignored by the compute and compare step on the other hand the genuine non-controlled content will match but this is okay

because its contents as it was left untouched so the computed signature is valid you would consider this natural as valid later step three okay later step three we will search for the image to load as it works on the tree view it fetches the image to load from the first node of the tree assumed to be the root node regardless of its name it loads the image from the fake root node thus loading attack or control data and our submarine is hit again and uh well now our submarine is hit and sunk indeed we showed two distinct ways of inserting arbitrary code to a signed image which gets executed even with verified boot enabled the impact can be significant you can

imagine for example the game console for which the protection then would be broken an attacker would be able to run arbitrary code and run pirated games thus breaking van der's business model and that's that's just an example well uh yeah i'm afraid that our game is over now yes i think that we can say it's game over well let's draw some conclusions as we have seen security engineering well it's hard it is primordial to be safe on the first try on parts that can't be updated later like the bootrom and as any chain a chain of thrust is as strong as its weakest link and also we want to remove any energy attack surface well i didn't brought you for that

because you knew all that before but even when you did everything right on your code you have a strong architecture you reviewed your code thoroughly you fasted it sometimes you may find it's not enough because the weakest link is coming from third-party code for some psychological reasons we tend to give more credit to third-party libraries that some deserve we have seen that again and again recently and not especially on this really great bootloader also pay attention that the vulnerabilities we have discovered here were based on logic bugs that means that they the way to exploit them doesn't lead to any sort of code or memory corruption so they are not usually discovered by automatic methods like static analyses

or advanced fuzzing and furthermore they are not mitigated even by the most evolved mitigation techniques so there is good news here we will need you all of you to actually secure the world also um we would like to take this opportunity to thank the thanks team tom renee simon glass it was a pleasure to work with you guys on the disclosure and on the fixes [Applause] so well i have a quick legal note i think that it is related to karen's sister she's on legal at intel and the credits for the authors of the licensed picture that we have used in this presentation thank you all for your attention [Applause] thank you so much ariel thank you merci

julien so this was awesome i learned a lot of things i also learned that you get a lot of applause in the middle of your presentation when you do cool things and the people of these sites surely appreciate it so let's give them one more round of applause thank you arya thank you julianne and now i have to announce some questions q a okay we're going to do a couple minutes q a do we have questions for julian and aliye and julian we have here hey hey i see your face put your mask on mask on okay questions all right control control please give us the handheld microphone one two check check one two on the mic

i can do some wrapping in the meantime one two okay one two yes yeah i understand the logic bag of the three versus the past view but why did the past view choose the fake node and the fake argument with the strudel but not the not the other one first how did you make him choose the how did you make the review select the fake one instead of the real one okay so what is going on there is that if you have this format that is called the unit address like i said and it is using this total for example you have kernel strudel one now a kernel and care destroyer one actually the same

so on the project the first project that we have seen this issue they were using just kernel if they would have used kernel strudel something so this side would not have been possible but since they were just ignoring the strudel part so it was just let's say kernel so we could make this attack because the code was written in a way that if you don't have anything or you have something you should it will be the same if they would have called it kernel one then the attack wouldn't have worked let's answer the questions i'm sorry i can't hear you

yes yes so if you want just what happens on the second project that we have looked at is that we're using actually this kernel at one format so this attack didn't work but we said okay it's not possible that we can't find another one that will work everywhere so julian just dig a little more and found the second attack

did you check the all the versions of uber till now okay so understand so the question is that if we have checked everything so we haven't checked every version but according actually to the authors when we discovered that i think it was in november or december something like that yeah i think it was in december so we did no no no november but the official communication was was in december which is maintained so we were in contact with the dance team they said that yes for very very very long time we still went back to 2013 or 2015 and all the versions were actually vulnerable it has been fixed in a patch it's on where we publicly released it although i

publicly released it in april in march i think it was in march it was on the april yeah it was in march but the version is the release candidate two of april if i'm not wrong right something like that okay i i might have missed it but uh excuse me uh okay so what made it when you said that uh the code with a kernel strudel run and not the one without the strudel what in the code of the bootloader made it uh run the one with the strudel is it what is it select based i don't know how to explain uh julia you want to take this question i can i'm not sure i fully understand

the question but so the question is how makes this select this one so basically as we explained you can you can insert images okay or images images inside the images node without breaking the signature so if there is for example one is searching for kernel and then before this one you insert kernel add something as the comparison will match as the first one you will you will it will pick up the first one that matches basically okay first match okay yeah the first match does okay any other questions here on the first row so uh there is going to be some uh release or like some pocs that you are going to release or it's going to be staying

like it's going i can find some additional notes somewhere yeah so so yeah yeah we we uh yeah basically we we send to the to the developer everything even a poc to reproduce the issues and the poc have been pushed to their repositories as you know non-regression tests so if you want to play with this there's a python script on the youboot repositories and normally in the git commits you can grab grip with the cvs because we asked them to put the cvs in the commit so it's easier for security researchers to look to search for that so everything is public thank you all right all right all right thank you so much arya thank you julian