Firmware is the New Black - Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities

okay so starting with a disclaimer I just want to put out here that any opinions that we share are our own we're not speaking for our company so in the agenda we're going to cover BIOS UEFI background talk a little bit about the ecosystem and some of the business problems that that gives us we're going to talk about Yui UEFI and biosecurity technologies our data set and methodology bug classes a proposal for UEFI and when we look at the three years of verne abilities we're going to talk about how those are distributed by boat classes and then we're going to talk about platform firmware threat modeling and finally what we expect to happen in the future so a little bit of background on UEFI UEFI is short for unified extensible firmware interface and old-school terms you're thinking BIOS it's the first up route of trust of the system and it hands over control to the operating system once it's done getting the platform ready for operations and then the rest of the magic happens UEFI membership does expand the complete compute spectrum I mean you could check out the UEFI members at that link right there so bottom line UEFI sets up the platform to run so where is UEFI firmware as you can see it's all over we have BIOS and OS VMM share and access but not trust you have UEFI pis mmm you have the hypervisor that can grant VM DirectX Hardware access and a specific peripheral may have its own processor in its own firmware which is undetectable by the host CPU OS and then a personal favor you know a favorite DMA or you know direct memory access so UEFI firmware has to deal with all of these scenarios so what's in UEFI it's mostly written in C emphasis on specifications and standards compliance if you look at UEFI org it is a standard it is it set a better platform scaling eg removes shadow ROM and limits it sets up storage such as removes the 2.2 terabyte limit CPU architecture independent platform design flexibility that's why it spans the computer spectrum secure boot solves trust related integrative of integration challenges and also has pre-boot networking ipv4 ipv6 PXE VLAN and all your drive interfaces and finally the UEFI shell improves pre-boot testing and diagnostics experience so once again this is the root of trust for your platform it's what's setting up everything to run so in terms of the ufi ecosystem it's an onion you're talking layers within layers a top of the onion you have Tiano core which is the open source implementation of edk 2 after that you have your ib vs your independent bios vendors those are the ones that are actually selling BIOS to the OEMs that are producing systems and then you have ODMs original design manufacturers these also build systems that you can purchase and finally in consumers the people that are actually running the computers and the last link in the chain that actually need to pull down and install BIOS updates so if there's a ver nobility mitigation that comes out for the UEFI ecosystem it has to navigate every layer of that onion and as mentioned there's also not update lag even if the IB vs the OEMs the ODMs I'll make BIOS updates available the end-user still has to take them and apply them and there's a tenancy in the world where end-users are very hesitant to update their firmware we all need to get over that so here's a little bit graphical in from a designation of what I just talked about as you can see Tiano cores on top of the pile and Tiano core is slowly built and maintained by Intel it's open source from there it goes down to the IB V's like we talked about before you also have a reference tree and then it goes to the you've heard me talk about the ODMs but then it gets you as you can see the complexities are there and then you have to ask yourself and there's later presentation there's been other firmware talks here are the ODMs applying updates are the OEMs applying updates and finally are the end-users applying updates it's got to go through every link of that chain so history UEFI dot-org is a standards body as I've already mentioned it's a specification about two years ago the UEFI stood up a team called the USR T which is short for unified Security Response Team and this is a sea-change UEFI for years and UEFI org has always said we're a standards body we're not going to take a position on implementations they've stood up their own response team and they are now taking a stance on implementations this is a big change and this is something that's happened in the last two years so a little bit of background on the u.s. RT this is composed by firmware engineers from member companies of the UEFI org to report a security issue you can send it to security at UEFI org their PGP public key is publicly available and this is a direct copy from their website you know it provide as much information as possible what are the products and versions that are impacted what is the description of the vulnerabilities what do we need to actually do to demonstrate the vertebra leti produced reproduce the exploit configuration for referrals etc and what's the potential impact of it once it is exploited and any information that you may have on known exploits so as mentioned Tiano core is Intel's implementation of edk 2 it is eligible for the Intel bug bounty so you can send a burnable report to secure dental comm we have a PG public key this linked here the bug bounty program is we only launched this in march out of CANSEC west it's a private invite-only bug bounty but if you find a good bug and you send it in secure that in telecom we will send you an invite you know you do need to be invited to be eligible you can find more information on the intel bug bounty online and a full participation guidelines at this URL right here so to recap the bug bounty program is private invite-only it's a security vulnerability is an open-source implementation of Tiano core that is slowly maintained by Intel we will pay for that bug and that falls in the middle layer of this chart here and you see oh it's up to $10,000 you must be invited by the hacker one platform we primarily leverage the hacker one platform due to their pace system it's really a for lack of a better word a PITA for us to pay an individual who that might happen to be in a foreign country to intel's finance systems so with that I'm going to turn it over to Vincent hey thanks Bruce so yeah Bruce talked about there's the UEFI standard there's tno core open-source implementation and then on T&O core we have a project called the efi developer kit to edk to is maybe ten year old software technology all through the life of efi i'm starting in 98 we had the efi reference then we had the original efi developer kit and then for the last decade or so we've had on the efi developer kit - and the two most important locations on Tiano core are the core features the github piano core edk - which you'll see on there and you'll find a bunch of packages like the MD module package which will have the Dixie EPI core that implements the UEFI MPI specs which is a set of very generic code we also have our security package the networking code the shell Bruce mentioned on that location in addition a new air that we've opened up on Tiano core is the platform's so for both in the the point of edk two platforms is to have instances of the rest of the firmware you know in the past some community said tno core was a sham open-source project because you could grab a BIOS core but you couldn't build a full product and one of the things we'll talk about in a little bit is with this platform code and some other elements you can snap this core into a platform and build a whole solution so but we have the core but you know what if you do find a security bug you can report issues to us RT go to the Intel bug bounty but also we coordinate or track our bugs through a secure bugzilla so there's an open bugzilla with feature request generic capabilities and then we have a secure bugzilla so HTTP you can create your bug entry so this is where we track bugs we keep them embargo people on the we call our InfoSec list can view and help grade some of the bugs on the secure bugzilla and then once the embargo pier is expired and we post the patch we journal all the changes in the tno advisory document which we've just put on get books so there's us Artie there's bug bounties and now the edk community community which is the implements implementation of the efi specs has a Bugzilla so that's what that's sort of the ecosystem how we track bugs but what are some of the features so in the 80k to world we have a collection of defenses the UEFI spec defined certain capabilities needy k2 was our code and sort of the gross taxonomy we use for the next couple pages here is what features did we do for protection which did we do for detection and which the viewer for recovery so this is sort of how we'll bucket the next few pages of capabilities we have with edk - so the first thing you'll find in ATK - and is the implementation of a fully verified boot so a lot of people say UEFI secure boot and I'm done you know I have security that's really not the case for a sort of a static verified boot you need to have a you need to have a root of trust and then maintain the verification up to the OS loader so in the world of standards open-source and hardware this describes sort of the amalgam of the capabilities you need on an Intel Architecture starting on the Left you have something like Intel boot guard where the hardware can verify the first hosts firmware element in our world it would be something like a PI based firmware volume so boot guard is on the left you know hardware you know SOC specific embodiment of the policies and that first block of code when you're now running your UEFI firmware needs to maintain the chain of trust going forward and so in our PI spec we have examples of how to do the crypto verification in the DX e phase DX e is our preferred efi core implementation described by the PI spec and at that point you do the quote UEFI secure boot so the whole point of UEFI is interoperability between shrink-wrap os's and platforms the person who built your platform is in not the party that build your OS you want to have the ability to multi-bit many OSS and so UEFI secure boot is there to provide that sort of interoperability between different OS vendors pre OS at vendors and different board manufacturers so the right-hand side of the flow is worth efi buys you but from an assurance perspective if you don't make sure your efi core and implementation is correct you could subvert a lot of these protections by attacking the underlying implementation and as Rodrigo will show later a lot of attacks aren't we broke UEFI secure boot they bypass some a lot of these protections through other there were other attacks so secure boot is one that's how we can ensure the right operating system is loaded but it works in tandem with trusted boot so we work with other standards bodies like the trusted computing group to define interfaces such that we abstract in the efi phase how to access stood platform module and throw so through that whole verified boot process we showed earlier we record all the code that's executed and then the PC RS so secure boot stops and goes into remediation if it detects Aran code trusted boot measures or audits all of the flow and so these are really two complementary features and a lot of the upstream windows upstream linux kernel's a lot of the OS is now have support for both of these both of these capabilities so secure boot and trusted we are sort of the high level features but really you know how do you build them and so this is you know what we wanted to do here was really show how you know the standards are great but if you don't reduce the standards to practice correctly you can't get the value out of them so our view of a lot of these features is to have an upstream open source you know product ready implementation that people can just grab and then also not people not only parties building system boards but you know working with the security community right we want we want to you know the only thing that should be secret is your private signing key off and some bunker somewhere the mechanism the code flows we believe should all be open transparent such that we can get peer review and see if we're doing a good job and so to that end the secure boot measured boot features talked about in the last couple pages we have a full implementation on Tiano core I mentioned the different packages we have so we have one package dedicated to a lot of our security technologies so you can grab that and get your measured in secure boot and we've also documented sort of the design rationale behind it so secure boots great trusted boots great but if you can subvert again the underlying implementation game over so updates is you know one of the big challenges we have at the industry bruce showed that you know tortured supply chain of how difficult it is through the different vendors to get updates to end users you know you can't ameliorate all that through writing a few pages in a spec and some code but one of the things you can do is remove some of the barriers to having robust implementation so the government you know with NIST 801 47 provides guidance on how you should do updates and one of the things we added the last year was in the past a lot of the ecosystem had their own Update technologies but we realized you know there wasn't sort of a least common denominator one people could just snap in and build a product and so we've open-sourced a full you know crypto verified rollback protected capsule update in addition to recovery so the way capsules work is the operating system UEFI exposes a runtime api with a well-defined envelope called a capsule that you can send an update to the platform and the past a lot of vendors had proprietary tools to do updates because they had different formats but now through windows update and then linux the fw UPD service you can take these capsules where the envelope is well defined by the UEFI spec each vendor puts their own grids and you can pass device and system firmware up through on this capsule mechanism and if you're building a board or a device and want to provide this capability in addition to the OS support we actually provide now an implementation you could grab off the web it's permissively licensed and have that and add this capability to your device so a secure boot measured boot and updates those are the sort of the macro feature to you know protect the platform manage the integrity but in addition you know when we did efi in 98 you know really wasn't much concern about security you know the world of biiss you know you jump to your MBR and efi you jump to your peak off as the years progressed the security became more of a more of a concern and so a lot of the capabilities that you know operating system software has been employing we've sort of we've been embracing an EFI you know the trend now is as operating systems and hypervisors becomes successively more hardened as you saw yesterday and you'll hear later today a lot of attacks are moving to the firmware so we've been employing a lot of more defense-in-depth know execute some simpler variant of a SLR stack Canaries because when you boot have to boot and mostly look the same and we also run one-to-one virtual to physical you don't get a lot of entropy but we do some randomization so we're employing some now defense-in-depth technologies in the core and then in addition SMM this has been a sort of a lightning-rod of a lot of attacks and so we've employed defense in depth they asked the Laura the NX on our upstream des mm infrastructure if you saw URIs talk yesterday he sort of cut off at the end talking about confused deputies attacking Windows 10 his last foil said W SMT the windows s security mitigation table is an a CPI table that says you've built your SMM with a fixed comm buffer to essentially to help mitigate those attacks we worked with the industry and on and have an open-source implementation of that hardening so the takeaway here is you know as the as the threats against sm is increased we've increased a lot of Defense's both in the implementation and working with the industry on explicating some of these some of these defenses and then a couple other things also you'll find on the on the web and I sort of just got tired of a you guys can can surf through your web browser and find this stuff but I wanted to let you know you know we have user identity password api's for random number generation and again capabilities that when you want to build your platform we don't want people for basic defenses to have to invent something on the fly we want to provide an instance of something like the lockbox interface this is a way that you can hide the boot script for s3 which is one of the attacks that a lot of vendors have exploited we have an example of that implementation on the web in addition to how to lock variables and then finally you know efi is a very modular component based architecture you pull pieces together it can be a little a daunting so we've tried to aggregate a lot of best known methods on how to use ET k2 and we've published publish that on the on the website so i talked about SMM you know SMM is really not part of UEFI if you read the UEFI spec it's a pure interface spec for consoles and block devices for boot loaders SMM is a facet of AMD and intel architecture this transparent execution mode but it's very often used as as a platform implementation and it has been getting a lot of attention from attackers because of its godlike privilege so we've really been trying to work with the community over the last few years in addition the defense-in-depth the fixed comm buffer the other things i mentioned on the last page on some what-ifs on some other classes of protections like the peer monitor the SMI transfer monitor this is something that can use the virtualization controls on intel's sm m2d privilege the SMM code this is something that in 2009 a lot of I think there was a black hat talk joanna rutkowska said I wish there was a reference SM STM well we put one out there so again we were trying to do through the open-source is put the specs but the code you know let the technology you know create a dialogue in an environment where you can then make some business decisions as distinct from saying you should do this and having that supply chain workflow of closed-source happening we're trying to be a lot more open and and then is it the right approach you know embrace the security community and get feedback and we've got a lot of good feedback on in 2015 when we when we needed the upstreaming the other technology that's not as well known because publicly well-known but something we've disclosed as part of them as part of our with a lot of the manufacturers is something called BIOS guard it's another way to deep privilege the SMM specifically access to the flash so you can have a guard effectively more more like a Hardware guard to immediate flash access that's another technology we put out there again in response to concerns about SMM and then finally as you'll notice in that bkm document we have a lot of guidance around the class of SMM attacks we've we've we've been observing whether it's setting the range registers locking sm ram at the ready to lock event which is when the you've you're about to run third party code and then some of the mitigations around the calm buffer for the confused deputy reborrowing attack make sure that you don't you know statically decide which M mio to use such that if attacker changed it these are guidances we've put out there and we demonstrate and send some of the other things Bruce mentioned DMA as a concern in some areas then exploring DMA protected boot using things like bus master and able to provide lease privilege and then exploring using the iommu to see if we can weaken harden the boot path but these are a lot of things it's daunting degree to be km document you'll say man that's a lot of stuff to keep up with and so really the thing we're trying to do and this is the progress we've made so far and we're we're we're trying to provide more is you know could you build the whole solution can we demonstrate this grab a board grab a tree build the whole stack and to that end for both Adam and core based platforms in that edk to platform repository you can essentially build an instance of a platform take the platform code from that directory go to the edk to repo to grab the core some things we're not able to open-source yet so we have a well-defined binary blob called the intel FSB but that's publicly available no NDA's so grab some code and binaries off get build build the firmware and then hopefully through that we're demonstrating this is how you should put the pieces together correctly beyond building the platform there's some really good training on on github from the ATR team this talks about chip sec which is a tool that you can run a posterior area on your platform to see if all the locks are configured correctly so again open source core some platforms guidance and then even tools you can run the C if you quote did the platform correctly with that you know assume an ideal world where we did everything correctly what have we observed in the industry sorry go is going to talk about some of the issues found in the industry thanks and can everybody hear me yeah okay oh so yeah like we trying to put the fences out there right but we see like a researchers keep publishing bugs bug after bug right in different components different like products are dews against a state of the art of Defense's that's a question that we want you to give to the audience right so help us to actually test the state of the art help us making the state of the art Oh No so when anyone fails point out the failure but also point out the state of the art one of the things that we intend to do now in this part of the presentation is try to show a little bit of the data side that we have all the bugs that were seeing for the past three years and basically share a bit of like what are the findings like and how they classify hopefully this will help everyone to actually get more familiar with like a BIOS related vulnerability and maybe like start also helping out eating and and understand that this is not magic even though there's a lot of things that are like platform-specific most of the bugs are is still like traditional normal code bugs that anyone that has like code understanding and code editing abilities would easily be able to help and contribute as well so before I even start showing the data I really want to point out to a presentation by Mitra guys and OSF actually to happen in like a 2013 where they talk about like bias in data set right they basically explain how why it is so difficult to really account vulnerability and how to compare vulnerability and how the different databases look into vulnerabilities in different ways so I want to make clear that everybody understand the limitations of the data that we are presenting here so the very first thing is like this data is coming from Intel research database that means if something was not reported to Intel or was not known to Intel it's just not there right for the past three years there was a hundred twenty four issues that were actually somehow generating a case so just to be a little bit clear like every issue that generates a case might end up being a known issue right so this ones that were no issues we ignore it from the data sets also there are a lot of of cases that are actually opened by internal teams the huge majority of a uf5 relative and abilities are being found by internal teams so those are also part of piece search if they do affect a product that is released if we find it before the project is released it doesn't affect any platform that is on the market it's not gonna be there obviously internal teams they are not perfect so multiple times they might find a bug in in a new platform but they don't even realize it affects an older platform or a release at platform so that will not actually be part of that this data set I want to say a little bit like some researchers also like to report bugs to us even though they know the bug does not affect I specifically Intel set right so the bug is a specific one OEM but the researcher do report to us do's also get into a case into IP search case and we really appreciate researchers doing that and often times more often than not we actually help the researchers to coordinate that issue to even have the discussion with the OEMs and we sometimes even provide like sentences on hey why this is indeed an issue and help that so keep keeping voting as it is actually really good and at the same time we hope we can help back as well right given all these limitations another another thing that happens in the P search data set is if we find an issue and that issue affects multiple platforms we tend to group that in one piece search but that don't necessarily happen in the past three years so there were cases where there were multiple different like spin-off of research issues and we try to cleanly to clean that manually but that happens also because the internal researchers tend to basically bundle together a bunch of reports and send us one it's very common that a lot of vulnerabilities are reported as one case for P search so when it was very obvious for us we split that but when it was not obvious we just actually kept the banner together so with that said in the end like really real issues that were reported in the past three three years and were fixed that we're like 77 issues I say past three years but we started counting generally 2015 and stopped counting like a week ago right so you have like two years and a half actually so given that there is so many problems in the data set I think like everybody we've asked hey so is that even a useful information right so we think it is but not to really compare one platform to the other because as I mentioned like this bundling together and as Bruce and Vincent demonstrated the way that the ecosystem works if we do fix something in core it ends up fixing everywhere so we might not have counted that as and as a given platform but maybe it actually affected that given platform we also believe there is value actually to define a taxonomy right so we try to provide a classification for bias bugs to help like a bit into the discussion on what is a bias bugs what are the kind of issues that we see in bias we also believe that help defining next steps and future strategies right so we also doing that so we'll propose some future changes and like some engagements that security community can help what customers and end users can also help right and how we can try to make the entire ecosystem evolve maybe it is it is good data to actually show trends so you can you can see that there is hey there is some more researchers are looking to it so but don't don't count that as a there are more bugs now than they were in the past because that's just not going to be true right it's just the fact that more people are looking into it now right also like we don't think that this data set can be used for that purpose of like comparing the number of bugs that we have now versus the past but it does show the trend of more researchers focusing on it and also more attention by Intel so before I explain a little bit about like a proposal for the bug classes let me just say that there are like Hardware bugs that do affect the promises that are the expectations you have from the bias on the platform right so there are like someone's some of those bugs became classic right so the memory sinkhole work presented actually in blackhat two years ago that became a classic bug so that was a hardware bug but it did affect somehow the way that ufi was actually providing in security so we did define a class for dues bugs but they are not on this 77 okay in that 77 when we showing the numbers we did not count to dues but we define it a class for Hardware bugs because they also affect of course you Fi and biosecurity the only matter is like there is not much that end-users and researchers can do on those ones we need to be able to patch and be able to deliver the patches to the platforms so I gave some examples of like ones that became my kind of famous right so there was the famous one exploited by Joanna and Rafal where it was like when you enter into SMI when they're actually handling an SMI the caches are synced back and you overwrite the memory that supposedly protected and the diffuse one that was presented in zero nights past year we're basically boot guard was badly configured so we also do not try to do like a bug classification that is super comprehensive this is not an academic exercise on taxonomy for frame or issues maybe someone should do that academic exercise what we try to do is really a very simple list that for all the issues that we've saw like and for for defining the bug classes we use it the issues from since 2007 even though for the numbers that we counted we counted only issues from 2015 but we wanted to make sure that they because they did buy classes that we're presenting indeed go over all the issues that we found are we encountered in BIOS so we hope they're like a it is kind of good but it's not an academic exercise you will see that some of those classes we put like a lots of software normal software vulnerabilities in one big class they're like a it's not validating trusted input is the name of that class and of course that can be exploded a little bit more in details but we didn't care much about that because there is like to be something very specific to to bias and to be able to generate this discussion with the community so the my classes like so we divided in seven different word classes I know it's a bit small for people on the back to say don't worry above that I will give examples for each of the class here is just the list so we can like every everybody can have their expectations set so we define alike inconsistent power transition States so essentially there is a it's very common and one of them was the Esther eboot script but there are many other bugs that like innocence is your machine when it's actually doing like a warm boot behaves different then when it's actually doing a code boot so either because some states are lost some locks are not set it's a different path that is taken this is actually very hard to define and to compare and to validate that like different like cold paths are actually performing correctly so we classify that as one specific issue and the s3 boot script we define it as one of like the main topics inside that by class so race conditions are another one even though race conditions are like very common software bug here because you do have like harder that is initialized as well when the platform is booting and you might want for example to have DMA protections as we said was pointing out and some harder might have actually already loaded so this is a class of issue Percy and we we defined that separately the bit basically input that should be validated and it's just not there is something that affects a lot like more like lots of the SMM related bugs are related to that so you receive an input and you are not properly validating it as this and discuss are we adding more and more mitigation should try to make the general classes a little bit harder to exploit but they are sue one class make measurement failures so this is when secure boot somehow fails you right they were like the most classical issues they're like I will like when we get into that specific one I will show like three interesting examples that are really bad failures from our sides and they're like I think it serves as a good example on how do you know like sometimes secure boot might fire you and what you can do to look for bugs there we have like the platform capabilities not properly configured that is like a huge right we like unfortunately a lot of the current guidance that Intel gives in terms of like what is the security of the platform is under MDAs and it's only given to OEMs and then the OEM can of course make their own business decisions if like they should follow that guideline or not and sometimes it's even harder to find the guideline sometimes what we write is not and super well-written and people interpret it in different ways and in depths being bugs we do have like some some meals here soon intel will be releasing that guideline to to the bigger audience to the bigger public is specifically the security part of the bios writers guide so more researchers will be able to help developing test scripts testing code and of course finding more and more bugs right and well that's all Brewster's problem anyway since is the P search guys of say to him then of course like a another big class that we've been seeing and it's it's growing lately is the the security of meaningful assets are exposed to entrust identities so imagine here a scenario where for example you have a new fi variable that controls if secure boot is enabled or not but that variable is exposed to anyone so that's the same as not having secure boot on that platform so this is the kind of bugs where like you exposing multiple ways of doing certain configurations and then the configuration itself is not as well protected as the feature percy and then of course as i mentioned the hardware misbehaving this is something that we did not count in the bugs but it is a class percy so to actually give examples for each of the cases right so I think the s reboot script when a billet was very well stressed out so there is like public exploit for it it is a very interesting one if you want to start playing with like running your own code in SMM and if you want to start actually playing with platform this is one that I I think it's really good and it also helps you validate or trader or other trade models right if you want to try to do attacks from SMM to something else or if you want to see when the platform fails what is breaking in your assumptions so I think that's a good one for for for looking to that there is like many many order like a bugs that that happen in in there so when one better we recently actually fix it was basically at like related like super transition as well so imagine that when your platform was actually booting from like code boot like the platform like initialized some data structures and the code was getting those data structure put into protected memory and then parsing that those data structures so when the platform was actually coming back from his leap the was actually generating the data structure in a different way for the culture parse and the code never actually copied it to trusted areas before actually you start doing the check so it checks but it is in an area where the OS can actually go and multiply so this is this is a bad thing right so and that that was another one that like it was inconsistent between like two different power transitions so going for the race conditions right and and a one thing that I forgot to say when I when I mention about the bike classes you see that sandbar class is there of course like the same bag would fit into different classes we try to actually good into the into the root of the class to put that bug so the example was this one that I just gave on the power transition in the end it there is a race condition right because you accessing the data and the data can be modified after your check but the root cause is because there is two different like states that are doing things in a different way and one of them is is failing right for the race condition good example is like for example there was a another bug that we were loading an optional run from a third party before the end of Dixie so before actually the logs were set and the platform was protected so the this is a very bad thing and that actually leads to bypassing of your secure boot and other things actually in your platform a good example of race conditions are like all dues that are like for example like an SMI handler is looking to something that is outside an SME memory it parses outside therefore it's a memory that is not protected and then all the checks are bypassed so those are like getting more and more common so we doing some experiments on trying to actually tackle those automatically so guru from Google project zero released a very nice work like a few years back box pound and actually in this black hat represented like a real loaded version of it and we what we did was like we got his his work and we implemented that in say makes this simulator and we're trying to automate that to actually find the same cases but now for SMI handlers so a part of that work they simulate the same exploiting that we wrote and everything is open source and it's available in the latest package ETF or the party area 4:15 so same thing here like trusting input this is like the more traditional bug like what classes like that everybody should be aware so researchers should have no problem in fighting dues we did present like actually in zero nights past year some some advances in that area as well it's a project called excite where we're trying to do symbolic execution of BIOS there is also a good paper that was presented even before the zero might work and and it's another one that we're trying to to automate more and more finding those those kind of bugs in on top of the mitigations that vincent already mentioned so for the mayor for the measurement failures there is like a two ways that we included here as really interesting examples because this is the kind of thing that sometimes people just take for granted and of course we when we look in we also have our own limitations right so for example like a client and server platforms we're sharing the same key so you would be able to get like a BIOS that supposedly loads in your your server parts and you load it in your client part but now the client part breaks because basically it's not the correct buyers it can't initialize the system and your platform doesn't boot but because it's all signed it's all good you can use all the update make an issue actually load that that buyers right that is a big failure and of course then like we hope that we can find more of those and fix another one was like there is a thirst executables that are supported by secure boot and basically like when it was loading it it loads it sends to the TPM for actually doing the verification when TPM goes for extending the PCRs it did not support this kind of executable so it's basically returned an error but secure boot ignore that error and just continued as if it was actually checked therefore you could load those without actually any signature checks so the the other class of blog is like platform property is not not properly configured so this one was like it is really big right so we like release chip sack like a few years back and keep working on improving that like to make sure that in like a disguise of this this kind of bugs are based caught there will be a talk like at 5 p.m. by mattress that basically show another one of those cases that like like om spelling like to actually follow like this stuff and he did an amazing work actually exploiting it and demonstrating like what you can do when some something like that fails and what is the impact in the platform so then we were like the security of meaningful assets I already gave the example is essentially if you have something that controls something else they control itself is exposed to and trusted entities while the control works someone president can just change the configuration of it and finally the hardware misbehavior is the classical classes that we already discussed that write like the memory sinkhole being a great presentation as an example of like hey I was yesterday and a dinner someone asked me hate how hardware can fail and affect security right I think the memory sinkhole talk is a good example that like has a lot of details if anyone is interested in say that and of course you can see Intel aratus I hope we do a good job like making the aratus available making the patches available as well but like I you can always look at their and try to learn things from there so this is the bug distribution right just like to show I know it's a little bit hard probably for people who are in the back to see but they the big the big area here is the untrusted input so basically it's classical software who nabila's like buffer overflows integer overflows leading to buffer overflows things like that or it straight getting a pointer from some some entity that is untrusted that is the huge majority of bios issues so any researcher that is interested in doing it can start contributor immediately just get a Tiano core and start like looking for bugs that's the make the biggest class and the second biggest class actually of issues is really miss configuration so we hope when we provide like when we open like these guidelines there is more people looking to all these different platforms that are available and finding these miss configurations we hope researchers help us like a running ship psyche and all kinds of platforms available and all to actually start finding more and more of those right those are the huge majorities if you look like for power transitions we have like us a big pick but that's essentially because when the the first history boot script or ik was found then of course more people started looking to this kind of bug and we start finding more issues if we look into the distribution a per ear you will see that so just choose for people who can if you can see on the back the yellow is 2017 then we have like the grace 2016 then this collar that I have no idea what is this College 2015 and the blue is the total it's just to give an idea of the proportion of how the issues are changing so you will see that there like a we have like some pics from time to time and that actually also shows that well intel does care right if you do find something and if it is like a mute range there will be a lot of eyes that we will start to look into that as well to try to find it to find other cases and and patch so yes please keep working with us so let's say they're like what is the rationale for developing a threat modeling when there is so so many classes of bugs right thanks Rodrigo so yeah so the challenge you've seen with the supply chain you know code bases different platforms the spec a lot of the modular code elements you put together how do you decide what to test where should you add new defenses and that's where you really need a threat model and so really it just defines the the goals of your security solution and so one of the things we want to engage more with the community as having a more public threat model both on the assets the threats and the mitigations this is a very schematic one very high-level our threat model has been evolving over time you'll see SMM was to defend itself you know back you know five years ago now it's make sure the SMM doesn't attack the hypervisor that shows you need a threat model and then a way to discuss with the community a way to evolve the threat model so threat modeling is something again as just as we put more code out there more platforms we want to have more public but want to give a couple minutes for questions so maybe let Rodrigo take us home here with the with the future so yeah I think like this is a call for actions right we're publishing a lot of codes we're publishing a lot of materials the presentation is available there is references to everything that is being done help us to make sure that everybody understands it like the state-of-the-art helped us reviewing it and now ask questions please oh so the question was where does AMT fit into this so Bruce showed earlier that EFI is the host firmware and then he talked about also device firmware so AMT would be a class of device firmware that runs on a microcontroller and the chipset it's complimentary to the host firmer like EFI such that they talk to each other but AMT is a wholly separable execution domain that's a good question there will be a talk on AMT in one hour 30 minutes 30 minutes oh so so for the prot so the question was what's the process for releasing patches and how will you provide patches so that there's a many answers to that so a lot of the system board manufacturers will curate the patches themselves perhaps did today they put it on their website in the future we're hoping it's distributed through Windows Update and FW UPD source code patches like when we find bugs in the open source they're on a commit list and we also backport them to supported branches and journal them in the Advisory log that's kind of where we get into the onion part that I talked about earlier you know we'll roll out patches that didn't have to go to the IBV s like am i phoenix inside etc from there it has to go to the OEMs and from there you know it goes out finally to the end consumers so there's multiple levels there in the ecosystem that it has to go through I'm sorry oh the limitation so the question was prob about the limitations of SMP it's a symmetric STM as oh yes the end I feel yeah yeah sorry no you have a backronym overload yeah yeah um so yes so the STM is a hypervisor that runs in SMM I think the limitations it's you know the ultimate the Anderson report for 72 the ultimate security is a reference monitor right it's a hypervisor but I guess the limitations are as much business as technical meaning a lot of even though we have an open source STM a lot of vendors don't include it into their their product BIOS so most SMM implementations today run in ring 0 and SMM not underneath they an STM also I think like of course complexity right if you have like a bloated hypervisor there then we'll have bugs as well so the question is there will be more bugs on that hypervisor and their regional SMI like handler that is being exploited and the privilege is there so it's it's always a challenge question right so but I think that those were like the biggest two limitations yeah booooo booooo working together [Music] well so it's a good question so I could talk about tea but--and secure boot working together so what I described today was a trusted boot and secure boot which are both BIOS features but there is an open-source project called T boot which is used for Intel trusted execution technology the T boot project historically was using multi boot grub on a PC a T BIOS boot that's moving to UEFI boot and we're working with the maintainer such that you should be able to compose UEFI secure boot T boot but there are still some some opens there but yeah we would like to have a point where all these hardware and firmware protections and ingredients can work together but there is some work on T boot to be compatible with UEFI secure boot so that's work in progress it's a good question Holmes good question so is there a place for us GX in something like firmware so SGX runs in ring three UEFI runs in ring zero but perhaps you could do a reverse trampoline and use some SGX in the pre OS maybe for pre-boot authentication because you know doing passwords and other things where we have to protect content we invariably push those flows in the SMM msg x may be an option to factor some of our pre OS applications sure yeah and we're out of time so if you have any additional questions you can follow us over to the room thank you very much thank you

Channel: Black Hat

Views: 908

Rating: 5 out of 5

Keywords: Black Hat, Black Hat USA, Information Security, Black Hat 2017, BHUSA, InfoSec, Black Hat USA 2017

Id: MONgHW2rpY8

Length: 51min 48sec (3108 seconds)

Published: Wed Jan 08 2020