Tomer Fichman - (In)secure Boot finding and exploiting vulnerabilities

now next talk we're going to have is from a car hacker who doesn't drive a car so he rode a bicycle to get here and he's going to talk to us all about car hacking now the reason I'm really excited about the next speaker his name is Thomas started off as a b-sides Tel Aviv attendee he was at besides Tel Aviv 2019 give it up to him yeah that's coming right here and now he's a speaker so you too can join us up on this stage next year if you want to so Thomas started as a participant now he's here on stage and Tommy is let's talk let's give a good smile for the camera

that's nice thank you slavi so Thomas here is going to take us through car hacking and insecure boots now there's all kinds of boots there's boots like this there's the trunk of your car and there's the boot that loads up your operating system which one are you going to talk about the insecure one the insecure one that's perfect stage is your summer take it away it's a deep dive into car hacking so hello besides uh I'm very excited to be here as Karen fed I'm a long time snd and it's very exciting to be here on the other side of the stage so welcome to my talk insecure boot finding and exploiting vulnerabilities in Renaissance pure boot implementation in

this talk I'm gonna talk about vulnerabilities affecting millions of cars and other devices these vulnerabilities will allow us to fully bypass secure Boot and run malicious code on the target so next

some technical issues okay thanks so who am I my name is Thomas Richmond and I'm fq with researcher at summative Technologies which is a company that does the cyber security for smart Mobility which is a very friendly way of saying car hacking I work in the embedded PT team which basically means hacking away at the correlated if you use by way of code review or reverse engineering and in my experience I've done vulnerability research reverse engineering and malware analysis okay my mistake I was moving backwards anyway uh the agenda for today so today we're gonna talk about the background and motivation for This research and of the pure boot we're going to talk about how Renaissance implemented their own

secure boot mechanism we're gonna go over the vulnerabilities I found there and how to exploit them and more specifically we're going to go over four vulnerabilities and exploit one of them fully to buy per secure Boot and run malicious execute malicious code and then we'll go over the fixes issued by Renaissance themselves and next step for research so it all started on a code review project abroad for a client our Target was an infotainment unit which is the little screen thingy over there where you play music on your car and the topics for the project included redacted due to NDA is actually due to NDA and secure boot which I got cool except that what is the cure boot

because at the time of the research I had near zero experience in that area I never researched it before which is a good time to mention that I'm by no means an expert on the subject I just did one knife research words about it and I will share it with you today so with that what is secure boot well basically it's a mechanism made its goal is to make sure that the platform will only execute trusted code it does it it does this by uh establishing a chain of trust uh where each image will verify the next image in turn for each image a signed certificate will be manufactured containing the hash of the content of the image and the

destination and length of the image to be loaded into memory and each bootloader stage will load the one after it verify everything and will only pass execution if all the checks are will pass so let's go back to our Target infotainment unit it was running on an rcar automotive system on chips made by Renaissance which is a leading automotive SOC manufacturer based in Japan uh now uh because the target was using that SOC it was using also their fq boot implementation which is open source and made by Renaissance and that one in turn was based on the arm TFA Armstrong film one uh which is a few World software reference implementation made by arm which is a whole other thing by itself

but basically its goal is to have a system running where you where we have our non-trusted world which is running a ritual if like Linux and a trusted World which is uh where we keep our sensitive information that we don't want to get compromised even if the rich OS itself is compromised their equivalent of the key or boot is called trusted board Boot and it's used by many reputable manufacturers such as nxp that have implements St and more and of course Renaissance which we will talk about today so especially the part we will talk about today is the BL2 the second stage bootloader which will load uh three images bl3132 which are the few world images

and bl33 which is the Linux non-trusted one we will be focusing at the Renaissance code and not the arm trusted firmware one and what BL2 basically does as you can see here is Loop over a list of image IDs to load load and verify them uh allow them to remember and verify them and then press Ctrl to the next image in the boot flow we will also specifically look at the attack surface that happens before the verification itself because that would require us either to attack the crypto mechanism itself or have a signed certificate for an image which greatly reduces our ability to attack that anyway so before any loading will happen we have some pretty image load checks

and here's the pseudo code of what will be done first we will read the image certificate into memory then we load the destination and length of that image form that memory and eventually we will check whether the memory area in which the image is below the phone certificate is and allowed this one in this case you can see the check for bl31 which will check it against the base and limit of it excuse me so yeah continue so the first thing that we said was reading the destination and length from the image we will get the certificate of the parameter and we need to populate the length and destination now we will take an offset into the

certificate read the side from it multiplied by four and save it in Len I guess it's a conversion from number of Duos to number of bytes anyway the problem here is that we take a 32-bit integer multiplied by 4 and save it other inside another is a little bit integer which will of course will result in an integer overflow which is our first vulnerability for today unfortunately this issue is not very useful as the Overflow is consistent across users of that Lan variable meaning we don't have any mismatch between the calculated length and the actual length and any buffer overflow that could happen as a result of that but it did motivate me to keep looking

deeper inside the code base and it could hint at other arithmetic issues hiding nearby so after we had loaded the destination and length now it's time to check it against the allowed one yeah it is important because if we will just allow any image to be loaded anywhere into memory before any verification on it is being done we could just override the stack for example and get configuration that way if it's important to verify before we do any kind of loading and now this check load area function will be called for every bootloader images except for bl33 the Linux one which is very curious and was surprising to me because I said it's not very safe to

just load anything anywhere but when I dug deeper inside the code loading the actual images I found disk here with check where if our counter reaches a BL 33 then we have a special check being performed so it's a very weird way to hide the check later on inside the boot flow but there is a check being performed over there okay let's have a closer look at it uh so as I said this function will receive the test and length variable and now it's important to note here that was in this Destin length variable will read from the certificate which is attacker controlled it is not being verified anyway it was read from external uh from

the external memory and assuming we have access to that memory we can maliciously affect the contents of the image and destination in length at this point so the first check is whether their destination which is the base of the image is before the Dirham starts before the start of the drum memory range a second check is whether the test is larger than dram minus length which is mathematically equivalent to test plus length over demand which basically means we will the image end after d memo range okay after that we check against some protected range we check whether we start after port starter before Port end meaning whether we start writing loading the image in the middle of the protected

area and after that we check whether we start before the protected area and end inside it override into it so basically we can see that these checks the goal of this check is to see that we will be loaded inside the digital memory area but not inside the protected one okay what's inside the protected one we will get to that later but interesting stuff to override but what if Len was larger than Port Stout well because it is being subtracted from it it would actually cause an integer underflow causing it to go to to be a very large value larger than this of course which would cause the fail to check and because the if expression to to be valid to false

and the entire path to check uh cool so we have our second vulnerability and it is the Overflow which will allow us to bypass this check and by prefect the check will allow us to start before Port start and override inside it and override interesting stuff there so let's better understand our primitive here okay first of all can land actually be larger than Port Stout can it actually underflow it well of course it could otherwise I wouldn't be talking to you about it but let's see how uh so land is a 32-bit integer as we've seen previously in the first vulnerability now what is Port starts well that depends on another variable called Legacy which is basically do we do does

this image operate inside a 32-bit address range those desk plus length is smaller or equal to ua32 Max if it doesn't operate in a little bit range well then pod start will also be a little bit value if it's larger than that it would be a value larger than 30 unitary to Max meaning we won't be able to underflow it so the first constraint on our primitive is that we need a test plus length to be smaller than 32-bit okay next if we are in legacy mode this will be our values for Port star theorem base and drum and so now let's see which destline values we need in order to pass all these checks

so if we want to pass this check we need this to start before approach starts and land to overflow Port starts so let's just take this to be for Less land to be four more and we should be able to pass the check cool next we want to check this passive check well if best is before Port start we will pass this check and lastly we still need to be inside the dealer memory area well it is large enough to uh to start before Port start and have a length larger than what start and we would this would be valid to false which is what we want to happen cool so remember I talked earlier about

overwriting the stack which would of course be like the go-to thing to do if you just have an arbitrary right so can we smash the stack well if we look at the values once again for drum base and drum end and compare it against Tech basically the stack base is after dram end meaning that if we want to actually write to them we would need to overflow the remained in order to pass the check but in order to over here to in order to underflow there and we would need to have a value larger than it and in order to still stay in legacy mode and have a validative underflowable that would need to be

this free fffe which is smaller than Dirham base so it would fail the other part of that expression meaning we cannot override the stack another reason we can do it is because drum area is from a hex 4 a bunch of zeros up to hex C the third and the system Ram area 863 basically where the stack is uh is not mapped all the way between there to there so we probably would have failed on trying to write two unmapped memory anyway so the the stack will remain unsmashed for today and let's go back to overwriting the protected area so I promised interesting stuff and here they are inside the protected area we have three

interesting stuff here is a simplified memory map of this area at the base we have our certificates the very one that will be used later on to verify the contents of our secure boot image uh after that them we will have Bill 31 bl32 which I said are there two other images to be loaded and they are the secure World part uh so basically we can override the certificate bl31 bill41 Bill 32 all of them together and have a lot of fun uh so if we overflow if we override the certificate uh will that actually help us to pass the checks later on being done in the skill boot well let's look at how the image will be verified later

on well first we have our load image which is what we looked at now where the underflow happens and the image will be loaded and over and override protected memory area and then we will call the function to verify the image now that function will achieve will receive the image ID the destination and the length of the image uh just now loaded but it will actually ignore the depth and length parameters when verifying the image and it will just read the certificate again for memory and call from secure boot API function to verify it so that's interesting uh in a few ways first of all it doesn't matter where we just loaded the image into and

what our certificate was the secure boot API will only will will load the email load the certificate again for memory and it will be the only thing that is best for verification uh meaning it will read the test and length from there again and verify it against the certificate uh also interesting in fact there's a keyword API is not part of the open source code but a function in boot Roman that Renaissance did not allow me to review or shared with me so it's something interesting to look at more in the future so uh let's recap a bit the attack here we will load the image which will use our Malaysia certificate and the destination

and length inside it we will overflow override that certificate by exporting the vulnerability we would then call auth mode verify image which will load the new overwritten image verify it and pass the check uh another question here is will the bl33 entry point be held from this uh I mean eventually the bootloader needs to hand off execution uh to the Linux image and uh if we tries to read the entry point uh by using the destination from the certificate it will read the wrong one because we over written overwritten it and it will fail so fortunately this value was read and saved at the start of the run and flashed as a parameter to the next stages so we will be fine from

that angle cool so let's put it all together uh the entire export for this issue first we will take the existing my Linux image and modify it in our own malicious way then we will read the current certificate because we will later use them for overwriting our own then we will spoof craft our own BL service certificate with a Ln larger than Port start and the destination of let's say Port start minus the size of the Linux image so that we will write entire Linux image and then right where it ends we will overwrite the certificates and after that uh we will put inside the image data I said the links image and the certificates

and that's it that the entire chain to fully exploit it and get codification uh on the devices running Renaissance we will not be having a demo and we will skip that part okay so after uh we have done we've gone over all of these uh this issue is well reported to Renaissance of course and they issued fixer for them so let's take a look at one such interesting fix okay remember the star they told you we will be looking at four vulnerabilities and exploiting one well we looked at two expected one and now we have the rest because in this one commit to fix the issue reported Renaissance has managed to introduce two new vulnerabilities in

the code base so let's start with uh what if commit even does so as highlighted over there the goal of this commit is to check if the next image invades I previously loaded one episode we had was overwriting bl32 for example so this check aims to see that we will not be able to overwrite any already loaded and verified image in memory which is like an logical thing to do so the first issue was the way they implemented the checks you can see they checked whether we start in the middle of an image with more context each desk and length will be saved inside an address loaded array and then looped over that array and we check our current distance length

against all the previous previously loaded ones so we will look over all the images and we'll check whether our current image base is inside that of another image or whether we start before in override inside another just like the previous check Fair we have seen but what if destination is equal to that of a previously loaded image well in that case the all these checks will pass and we would be able to override the image so that's the first issue they had here and after I found it I went to my colleague Eli who is here in the room shout out till I Folsom human rubber ducking as I usually often do and I told him what do you

think about this issue does it like look only to you and he said yeah let's look fine you know but there's another vulnerability here that you have missed and he was right there was actually another interesting thing here that they should have seen because if we look more closely at this part we can see that address loaded is an array of size check imagery account which is defined in the five here and uh initial X1 and before we actually do all these checks we check that our address loaded counter is not larger than 5 which is the size of the array and if it is we will have set the result of failure which would eventually cause the

entire would flow to be aborted but before the boot flow will be aborted we will still use this out of bound index to write inside inside address loaded the destination and length uh causing an out of two out of bind out of bound life and now even more interestingly more interestingly is the fact that after address loaded is the address loaded counter which makes it probable but depends on the compiler that they were compiled right one after another in memory which means that the first override of death would override the counter itself causing the first override of flan to actually be of any relative posit any relative positive relatively positive offset to other floated which is a very fun primitive to

have so we reported to Renaissance this vulnerabilities as well and they fixed them cool cool cool impacts so as I said in order to exploit these issues we would need to be able to actually change the images in memory uh which means either either need to have a high privilege in their ritual of Linux uh high enough to override the images in flesh or have a physical access to the memory where they are stored uh to change them there and what can we get with these Primitives and this vulnerability well we could break separation between trusted walls and non-trusted world because as I said we could have overwritten a bl3132 which are the secure world images containing sensitive

data and we could also have just used this as an initial access Vector into the device by exploiting it to write malicious Linux image as we have demonstrated cool impact okay so we seen what we can do let's see what we can do it on as whether the initial research was done on an infotainment unit inside the car and the alcohol SOC family is has seen here is used for anything from a cluster dashboard up to autonomous driving but the code base is shared also for the rvg family of Renaissance which is used for HMI analysis applications such as a point of sale systems electrical vehicle charging industrial gateways and many more stuff a cool so timeline for these issues

well the initial research was done in November 2022 where the certificate line overflow and check load area underflow were found in January 2024 the valve were reported to Renaissance and in March they they issued the first round of fixes shortly after that I found the address for insulation and Eli the address the address buffer overflow availability and we reported them to Rena 5 as well and in April they were also fixed and pushed to the Republic triple and hopefully somewhere around this year the CVS will be issued for the vulnerability and we are in the ongoing effort with a4g which is the CNA for automotive related security vulnerability vulnerabilities which means that they are responsible for issuing CVS for that

area and okay what's next well research-wise looking the for similar vulnerabilities in other secure boot implementations could be interesting also researching other driver code could be more prone to issues aside from the main entrusted firmware code and also researching the boot ROM code which is where we saw the actual cryptographic verification of the certificate and the image being done cool and personally for me what's next is I'll be traveling through Central and South America for six months so don't expect any new research for me and a blog post will go up in the same motive site uh thanks uh thanks to Eli for finding the uh for vulnerability and being my rubber ducky thanks to Matan and also Thomas and

Benny for feedback on the presentation and ah I went too far and to the Renaissance P series which is the product security incident response team for issuing quick fixes and being very cooperative and thank you for listening to me talk for 30 minutes about the few boots amazing thank you so much so much you did it amazing