 Good afternoon everybody. My name is John Heesman. I work for NGS software in the UK. If you've seen any of my other presentations over the last year, you know I've been focusing on root kits, and specifically root kit persistence. Today I'm going to talk about EFI, which is Intel's replacement for the BIOS, currently available in Macbooks, and likely to be available on most operating systems. I like to support it within the next year. So this is what I want to get through today. To give you some background on EFI, I'm actually going to start by talking about a legacy BIOS. I've got quite a lot of slides to get through, so I'm going to move quickly through the early ones, where I'm going to talk about what the BIOS actually has to accomplish, how we can attack a traditional BIOS, the limitations, and basically the motivation for Intel developing EFI, and then we'll talk about some EFI specific attacks, and also the relevance of the attacks against legacy BIOSes. Then I want to talk about UEFI, which is the kind of successor to EFI. It's the next version that the consortium is working on. I'll summarise and draw some conclusions. Firstly, I want to make a few caveats here. As I said, I'm interested in talking about rootkit persistence. I'm not really interested in what the rootkit does. So essentially I want to persist a rootkit on some device in some firmware. I don't want the rootkit to be on disk. However, I do want it to be able to load automatically. My rootkits have no bootstrap component on disk. They persist in firmware and they're able to load themselves into the kernel, typically before the operating system has finished booting up. I'll show you a few ways of doing that. I'm not going to talk a great deal about trusted computing in this talk. When we talk about UEFI, I'll mention it, but the EFI spec certainly doesn't mandate that you have a TPM, for example. Many MacBooks, some do have a TPM, some don't. Some of these attacks require physical access depending on whether you're able to flash the firmware, for example whether you need to flip a jumper. All of the attacks are likely to require root access and or kernel access. The kind of threat I see for this is a blended attack whereby stage one is we compromise the user system. We then carry out some information gathering to work out exactly what chipset they have and then we actually go ahead and deploy our rootkit in firmware. I'd also say that parts of this work are definitely very much work in progress. Moving on, the role of the BIOS. The BIOS is probably one of the least understood parts of the system today. You guys know a great deal about how the bootloader works, how the operating system works, but the BIOS is a bit of a grey area. When you turn your system on, the CPU starts executing from a fixed address, and ultimately it knows pretty much nothing about the hardware in your system. It actually doesn't even know how to access RAM on your system. One of the first things it will do is start issuing read cycles for the reset vector, the firmware address, and those will go to the north bridge, which will basically direct it to the firmware device in your system, so for example the firmware hub. The first few instructions executed by the CPU will actually set up the north bridge so that we can then access memory. We'll then go ahead and set up the south bridge so that we can then start querying devices and see what hardware we have in the system. Another key part of the BIOS is to set up PCI devices. In this talk, when I mention PCI, I'm actually talking about PCI, AGP and PCI Express, because essentially the area I'm interested in, the expansion ROM mechanism is common to them all. The BIOS will scan the PCI bus and will attempt to locate option ROMs. Option ROMs are simply x86 code that needs to be executed during the power-on-self test in order to configure the device. The BIOS also provides the familiar setup screen so we can configure the boot device priority and we can persist those settings to non-volatile RAM. Finally, the BIOS will then hand off to the bootloader. Here are four ways we can attack a legacy BIOS. Here are four ways we can persist a root kit. Firstly, we can reflash the firmware device itself. We can just reflash the BIOS. I'm going to go into these in detail in the next slide so I'll just run through them quickly now. A second attack is that we can modify the option ROMs on PCI devices themselves and then reflash the device. The third attack is different to the first two. We're not interested in modifying code as such. We're interested in modifying some of the data modules that are stored in the BIOS. This attack modifies the advanced configuration and power interface tables. The fourth attack I want to talk about is different to the first three in that though the majority of my talk is about persisting in firmware, this attack shows how we can persist in memory and survive across reboots without touching firmware or disk. The first attack, patching the BIOS, we have a huge amount of freedom in what we can do. Ultimately, the job of the BIOS is to get the bootloader going. If we can subvert the bootloader, which loads the kernel, then we can likely deploy our root kit. Bootloader has to rely on a set of services exposed by the BIOS. These are exposed through the interrupt vector table. You'll probably know that when we're executing the BIOS code, this is 16-bit real mode assembler. If we can subvert the interrupt vector table, if we can hook and interrupt that the bootloader will rely on, then ultimately we can get our code executing in the bootloader, and then we can basically patch the kernel as it loads it. Quite simply, we find where the BIOS calls in 19 hex to pass off control to the bootloader. Before this call, the IVT has hopefully been constructed at this point, and we can simply hook the required interrupt. I'll talk more about which interrupt we might go for on my next slide. Some caveats, we may require physical access, as I talked about. Some vendors in Telan Phoenix, for example, have secure flash these days, which means that we can't necessarily update the firmware with an unsigned update. Of course, if we have a TPM in the system and it's linked into a secure boot process, for example BitLocker on Vista, then we may not be able to update the firmware and get the machine to still boot correctly. Simply having a TPM in your machine, but not using any of the secure boot process, then we can go ahead and flash the firmware. The TPM is simply a device to measure things like the hash of the bias, for example. Simply having a TPM in your machine doesn't offer you any protection. You have to have the whole secure boot process. The second attack is Option ROMs. As I mentioned briefly earlier, Option ROMs are simply ROMs on a PCI card that holds some initialisation code. They can actually be for any architecture, but ultimately they're likely to contain X86 code. Option ROMs are copied to RAM during the system post, and then simply executed. They're just blobs of X86 code that are taken straight off your card, put into memory and executed. They'll be stored in an EEPROM or an EEEPROM, the difference being whether we have to actually remove the chip off the card to flash it. Here's an example. If you have a PCI Express graphics card, it will likely have an EEEPROM, and the initialisation code will basically install a handler for Int 10 hex video. That handler will implement the VGA and the VBE functionality. To attack an Option ROM, attack a PCI card, ultimately we need to dump the Option ROM off the card. Alternatively we can go to the vendor's website. For example, if we're talking about a graphics card and you've updated the BIOS on your graphics card, you know how easy it is to download a tool to do it and the BIOS from the website. We patched the Option ROM. Again, we're interested in subverting the bootloader, so we simply hook and interrupt. Which interrupt to hook? Well, EI released a proof of concept boot sector root kit in 2005, and they demonstrated that if you hook in 13 hex, as in the disk interrupt, when the bootloader starts loading some of the key device drivers in the kernel itself, then essentially we can see that flow of data and we can look for a byte stream and patch it on the fly. The approach I took when I was investigating putting root kits on PCI cards was actually to hook in 10, the video interrupt, though this was a window-specific technique. I noticed that the Windows kernel actually called Int 10 hex during the boot and it's a relatively involved process because the Windows kernel is obviously 32-bit protective mode and these are 16-bit real mode interrupts, so I found that the Windows kernel actually switched the processor into V8086 mode and I was able to influence how it returned back to 32-bit protective mode. I guess my point here is that there are likely other candidates. The key takeaway is that the bootloader in a legacy BIOS relies on services exposed by the interrupt vector table and if we're able to execute code during the power-on self-test during the running of the BIOS then we can simply hook one of those interrupts that it depends upon. Pros and cons of option ROM attacks. Most PCI cards don't have any jumpers so we can flash them pretty easily. The flashing process itself simply is doing IO to the card so we just need root access in both Linux, Windows, OSX for example. We don't actually need to get into kernel. Network cards also have option ROMs and the option ROMs on network cards implement pixie, so the network booting. This is a kind of nice idea that we could make use of their network stack so that we could actually do things like pre-boot updates of our root kit before the bootloader kicks in on phone home, covert channels. Plenty of opportunity. One of the disadvantages is that we're limited by space on an option ROM. We can't simply dump the code that's there because your graphics card probably won't work. At least it won't work while the bootloader is working. By the time the operating system is loaded, we no longer rely on things like the 10 handler so the graphics card will work but ultimately we want to shoehorn our code into some slack space. I played with distributing my root kit across multiple cards but then obviously we're increasing our chances of detection or somebody removing a card and us losing some code. Detection is fairly easy. It's very well documented how to dump option ROMs off the PCI cards in the PCI spec and then we just apply some heuristics to analyse the ROM and if, for example, we see that it has protective mode code and as I said we're interested in we're expecting the option ROM so I have come up with some ways of detecting the of subverting the detection process as I'll talk about later using system management mode it's possible to trap IO access and basically give wrong results back. Moving on to the third attack against legacy BIOS and as I said many of these attacks are going to be applicable to EFI which is why I'm going into them now. This attack targets the advanced configuration and power interface that replaces the advanced power management and this handles all the power management in everything from your notebook to a big server and the way ACP works is ultimately the BIOS contains some data tables and these data tables hold virtual instructions that are interpreted by the operating system ACP device driver and ACP is a standard and consequently there's ACP implementations for pretty much every operating system so the kind of nice thing here is that we're because we're using these virtual virtual instructions we can actually make a root kit that's seemingly platform independent so the way an attack would work against ACP as I said the BIOS holds these tables containing ACP machine language the device driver interprets these instructions so for example if you press one of the hot keys on your laptop and ultimately that will result in the ACP device driver interpreting some of the AML instructions that tell it what to do when you press that button and the key thing is we can take the existing ACP tables for a system and we can append our own virtual instructions into these tables and this allows us to pretty much exert full control over the system so for example from the ACP machine language we can modify system memory so we can patch the kernel we can we have full access to the IO space as well so ultimately we would take a BIOS crack it open into its code modules, its data modules locate the ACP tables disassemble them into the ACP source language, the high level language that the platform designers use to make them modify them to put our root kit in there recompile them and put the BIOS back together and reflasher benefits as I said the ACP machine language is platform independent its these virtual instructions that are implemented by the interpreted by the device driver and as I said the ACP source language is a high level language vaguely object oriented and its easy to disassemble between the ACP machine language that you find in the BIOS and ACP source language the ACP device driver is in obviously that the kernel is loaded so this attack allows us to very easily patch the kernel and also the fact that we've got this virtual machine gives us an abstraction so we can make some smart decisions and we can future proof our root kit so at Black Hat DC in 2006 I talked about a cross platform root kit that had some logic that said are we running on windows are we running on linux and did a series of tests so we were absolutely sure it knew what the target was before then actually patching the kernel limitations we need to modify the system BIOS so again if we have to have a signed update then this attack is mitigated also the operating system must have an ACP device driver basically if we can get hold of the raw ACP tables to then perform some analysis on them then we can spot our root kit and if we can stop the ACP device driver from interpreting our instructions we can stop the root kit deploying and if you turn off ACP your system performance is likely to suffer but your operating system will work and finally this is one thing I noted that when I demonstrated this on windows ultimately I was getting a load of event log messages that were warning me that the ACP device driver was doing things that could compromise stability because I was patching the kernel and so ultimately you could come up with some mitigations in the ACP device driver that sandboxed what the interpreter was allowed to do because quite frankly you shouldn't be patching certain areas of memory you shouldn't be patching kernel code pages for example the last attack I'll talk about on legacy BIOS is warm reboot attacks so the last three attacks require us to make modifications to firmware which kind of makes detection easier and if we think about if you take the case of a web server or a database server they probably have SLAs that mean that these things aren't turned off very often they might be warm rebooted say once a month to install some patches but the only time you might actually remove the power is to replace some hardware for example so it may be sufficient for us to try and persist in memory alone without touching disk or firmware so it's pretty easy to do this because what we actually find is that when the CPU when you first call boot the system those first few memory accesses that go to the firmware hub get cached in RAM for speed and when we warm reboot ultimately we'll actually just execute out of RAM so basically all we need to do is modify this shadow RAM it's called shadow RAM because it's obviously shadowing the contents of the firmware device so ultimately we can remove the right protection on the shadow RAM modify it we can carry out a similar attack to the other attacks where we'll look to patch the interrupt vector table and I guess the only unfortunate thing is it's kind of chip set dependent on how to do this so Intel have a concept of programmable attribute maps and AMD has MTRRs memory type range registers but it's actually fairly easy to do this just download the specs and if you have some code running in actually I was going to say ring zero but again you don't need to be you don't need to be ring zero you just need to be root to be able to remove the right protection and modify these pages okay moving on so why do we need to replace the BIOS with a new technology well the BIOS is written in 16-bit real-med assembler who writes that code these days not very many people and the BIOS just doesn't expose clean interfaces an example of this is interrupt 15 hex the so-called miscellaneous interrupt and you'll find that the subfunctions for this interrupt just totally vary from vendor to vendor and the few interfaces that there are defined are pretty clunky for example I'll show you some documentation from the post-memory manager spec which is a spec for if your code from another code module for example an option ROM wants to allocate some memory we have to jump through a load of hoops to actually get there we have to scan for a particular four-byte string then we have to check some structure to make sure we've found it and then we have some optional stability checks and then finally we're allowed to actually call through a function pointer so it's basically a lot of work so one of the key some of the key design principles of EFI were extensibility one of the other things the designers of EFI kept in mind is that they didn't want to implement a whole new host of technology so they want to use existing technologies there's an EFI system partition any people that have a MacBook will probably know about that I believe it's about 200 megabytes and it's just an empty partition and it's a fat partition that's the EFI system partition that could potentially contain extra EFI modules executable images in EFI are basically PE files and EFI essentially doesn't mess with any of the existing interfaces that the operating system might use so ACP and SMBIOS for retrieving information about your system both of those are there and by and large untouched another key design principle was modularity so the core EFI implementation is stored in firmware but the idea being that and this is really the key idea that we can have third party device drivers so we have just enough just enough implementation in the firmware itself to be able to read the EFI system partition for example and then third parties can drop drivers in to actually bootstrap other hardware you can create EFI code in C and you can compile it you can download a development kit that will let you compile it on any mainstream compiler and EFI is a spec it's not an implementation it simply defines some interfaces to solve the option ROM problem of option ROMs simply containing x86 code the Intel came up with a concept of EFI byte code so essentially their own virtual instruction set so that we can now create cards that have option ROMs containing byte code that's then interpreted by the EFI driver so here's a high level diagram of what EFI really looks like ultimately we start with firmware platform initialization which as I said is just enough to get the thing going and then we iteratively load drivers and you can kind of think of EFI as almost like an operating system in that we have the concept of drivers and we have the concept of applications and eventually we end up choosing a bootloader which is simply an EFI application and there's plenty of tools out there for investigating the EFI environment so for example I suspect many of you that dual boot on a MacBook use something like refit or efi basically a tool that will also let you drop to a shell and type commands as if you're at a prompt and actually refit is pretty flexible and it even uses network stacks to actually connect to sites on the internet for example so some EFI definitions the concept of a protocol protocol is basically an interface that exposes some functions contained in a driver each protocol has a GUID which ties in with the extensibility unlike the interrupt 15 hex in a legacy BIOS where vendors of just kind of redefines sub functions or other hopefully with a GUID there will be no collisions so each vendor generates a GUID and embeds it in the driver and the driver can implement multiple protocols when you launch an EFI application or driver it's passed the pointer to an EFI system table or the EFI system table and this is a pretty key data structure that basically allows an EFI application to locate protocols and therefore functions within them the EFI environment is actually a protected mode but it's a flat memory model so we can simply pass around function pointers to things in other drivers or applications EFI defines boot services and these are services that are available for any application or driver to use and they cover the kind of handy things that you might need for example memory allocation how to locate other protocols that we can actually get stuff done and how to actually query EFI images themselves so we can find out like file paths to things that kind of thing we also have the concept of runtime services and this is quite interesting in that these services are available after the environment has finished so once the bootloader is executing runtime services are still available and the kind of idea of this is that ultimately EFI can provide device drivers that the operating system can also use right now people aren't really using this but it's an interesting idea that you could expose some services in the EFI environment that are still available when the operating system is booted up the final definition is the framework and this is Intel's reference implementation and this is what's actually used by OSX and the interesting thing is that it's actually partially open source so if you're interested go to tianocore.org and have a look at it and perhaps unsurprisingly Intel views the framework as the implementation of choice if you're looking for an EFI implementation so what about EFI and security well the 1.10 spec isn't really focused on security the framework itself the framework spec docs remember that's Intel's implementation actually starts to elaborate and says you should have a security phase the security phase is where you set your core roots of trust and basically you should make sure it's secure so the security phase in Intel's implementation for handling restarts as I said it also serves as a root of trust and it's responsible for handing off to the pre EFI phase the pre EFI phase is basically the phase in which the environment's brought up so we have to get the hardware going so for example this is where the north bridge would be configured and the south bridge would be configured and the PEI phase invokes the driver execution environment which then means we can load drivers and load our applications so this is kind of what it looks like with the various phases so how can we abuse EFI the first objective is we need to get our code running in the EFI environment there's a few different ways of doing this we could modify the bootloader itself the bootloader for ISX is just simply an EFI binary on disk we can simply patch that binary the next stack I'm going to talk about and I'll go through these in detail on the next few slides is modifying envy RAM variables so if you're familiar with open firmware in the way that worked ultimately you have some global variables stored in some non-volatile RAM that basically tell you what bootloader you want to use thirdly we could patch the framework itself and reflash fourthly we could go for an implementation floor in one of the EFI drivers once we've actually got code running in the EFI environment then how do we subvert the bootloader we could hook one of the runtime services or a boot service that we know the bootloader will rely on we could modify the ACP tables as I said EFI basically doesn't really mess with them and it needs to keep them there because the operating system needs them it's an existing spec we could load a system management mode driver and that's probably the most interesting attack so I'll spend time on that or we could carry out an attack that's kind of similar to attacks against the legacy BIOS if we know that there's a compatibility support module bootcamp for example the first attack and the simplest is we modify the bootloader so on OSX that's stored at that path OSX doesn't actually use the EFI system partition but carrying out this attack is kind of unstealthy simply because we could detect it pretty easily with anything like tripwire unless our root kit is aware that those tools are going to be looking for it and if you're patching a file on disk why don't you just patch the kernel directly instead this last point is not really applicable to OSX implementation sorry, Intel's implementation of EFI the one that OSX uses but it will be applicable to the UEFI implementations where basically we can enforce driver signing and so simply trying to get an unsigned bootloader working won't work modifying the non-volatile RAM variables as I said these specify which bootloader we want to use there's an interface for us to do this from EFI if you run the MV RAM tool from OSX it lets you dump and modify the variables we can create a custom bootloader we can set the EFI boot device and tell the system to use that and what we actually do in this bootloader will typically do one of the attacks that I'm going to come on to shortly where we will shim one of the services that's available, the boot services or the runtime service and then simply call the original bootloader is this stealthier than the previous one well probably not because we are modifying MV RAM and if I was doing forensics on OSX I would definitely be interested in what's in MV RAM code injection attacks these are going to be pretty important when when people actually implement UEFI properly ultimately we'll be looking for some kind of overflow stack overflow, heap overflow or some kind of bug in verifying digital signatures and when we talk about the possibility for this and people might ask well what kind of user what kind of data do we control in this environment there's actually some good targets so we could target the file system drivers we could mouth on the file system in some way so that we cause an overflow P passing code is always a good one in my work as a security consultant looking at antivirus vendor software for example the number of bugs I found in their code relating to P passing that ultimately lead to code execution is huge so I'd be really surprised that if there aren't any bugs like that crypto code again we'll obviously be verifying digital signatures on binaries so we've got some good targets here the data itself in the certs or we could go for ASM1 decoding and any data coming off the network so how might we actually support the bootloader once we've got code running in EFI well the spec says that when the bootloader exits sorry when the bootloader is ready to transfer control to the kernel it must notify the EFI environment by calling exit boot services so this is a great place to hook because we know at this point that the kernel is going to be loaded so if we hook exit boot services when the bootloader actually calls exit boot services we get control and we can patch the kernel it's fairly easy to actually carry out this attack we can create a runtime driver that simply locates the EFI system table and replaces the function pointer for exit boot services I also looked at shimming runtime services but not many of them are actually called by far the exit boot services seem the best place to hook this is what elilo booting Linux looks like so we see that loads of the kernel free some resources and then calls exit boot services and then it calls the start kernel function so you can see that obviously if we're getting control when it calls exit boot services it's pretty easy for us to locate the kernel in memory okay this is probably the most interesting attack against EFI system management mode has been on most processes since the 386 and I know virtualization root kits are getting a lot of press these days but actually I think system management mode is scarier than virtualization and it's been on most people's processes system management mode is a kind of get out of jail free card for platform designers so pretty much any time they need to do something that the hardware doesn't let them they can probably do it in system management mode so basically things like the century rollover bug was fixed by vendors putting some code in system management mode and ultimately system management mode very similar to virtualization in that the operating system doesn't know that we've gone into system management mode so in the same way that in virtualization the operating system shouldn't really know that a hypervisor even exists in this scenario the operating system won't know that we've executed code in system management mode and we can get into system management mode a number of ways ultimately we need to get a system management interrupt fired and these can be triggered by external events so for example plugging a USB device into your laptop probably generates an SMI we can also set these up to be triggered periodically every few seconds and we can also trigger SMIs on IO access so this is quite interesting if we do IO access to a particular port then we can track that and jump straight into system management mode how might we abuse system management mode well the only presentation I've seen that I actually discussed this was Luke Defloir at Cansec and he used it for subverting BSD secure levels and in his paper he hinted that system management mode would be pretty bad for malware why is that exactly well things like hardware breakpoints just don't work in system management mode so if we had some detection software and we were using hardware breakpoints and we went through system management mode they don't fire the operating system cannot get access to the RAM allocated for system management mode if the system management the SMRAM config register has been set to not allow access so there's a lock bit that some vendors set some don't in fact Luke Defloir's talk basically only concerns systems where the lock bit wasn't set so once we've actually set that lock bit the operating system cannot see system management RAM SMIs can't be interrupted by anything even non-mascable interrupts and as I said SMM can also trap IO reads and writes which is kind of scary so this is a kind of perfect fodder for a root kit that is seemingly undetectable I say seemingly because ultimately if you're looking for it you could probably find it timing attacks for example but why haven't we actually seen a SMM root kit considering that it's been on processes since 386SL well the barrier is pretty high for entry ultimately to debug system management mode you need a logic analyzer so it's not going to be too easy to develop and there's actually not much code out there that shows you how to get into system management mode and what to actually do how to write system management mode handler there's limited opportunity if the vendor has set the lock bit for malware to use it ultimately if we compromise somebody and the biases set the lock bit then we'll have to wait for the next reboot to actually we'll have to carry out one of the warm reboot attacks for example to then try and get a code into system management mode and also system dependencies make it less attractive that's to say that you don't really know what your vendor is using system management mode for so you probably don't want to go blindly trashing system management ram with your own code because you're probably likely to make something stop working so why do I mention system management mode in the context of EFI well EFI actually provides some very clean, very easy to use interfaces for system management mode they actually take all of the hard work out of creating a system management mode driver they provide us with a protocol for registering our driver an access protocol so we can toggle the lock bit they provide a protocol for triggering system management interrupts and the child dispatch protocol for setting up things like periodic callbacks they even go further they give us some functionality to use when we're in system management mode so the SMST allows us to allocate memory it also gives us access to the CPU context through a nice interface so for example the way it might work is we'll load our driver into system management mode we'll set up a periodic interrupt and every time our callback in system management mode gets executed we might want to use one of these protocols to examine the state of the CPU so we have a context structure when we can see exactly what code was executing and we can modify things appropriately the only kind of warning about the power of system management mode in the specs that I read basically said that you have to preserve the chain of trust that you've already set up which is kind of a pretty vague statement if you don't have a chain of trust set up then ultimately we can trifily write a driver and get it into a system management mode which is what I've been able to do on OSX actually and if anyone's interested I'll show them just the amount of code required to do this it's actually pretty small next thing I want to talk about is compatibility support modules and these provide legacy compatibility so for example you want to install an operating system on an EFI system that requires a BIOS basically all you need to do to implement a compatibility support module which is simply an EFI application or it could be a driver the majority of the work is you need to implement the interrupt vector table so that when the bootloader fires an interrupt ultimately you can actually carry out the same functionality so most compatibility support modules the two I've looked at XP on Mac and Bootcamp will thunk to 32-bit protective mode so they'll execute the bootloader in 16-bit real mode and then when it calls the interrupt there'll be a thunk into 32-bit protective mode it'll then carry out the equivalent EFI function and then thunk back so really if we have code execution at this point all we need to do is hook the interrupt vector table or we can patch the handlers UFI UFI is basically the next version of EFI so Intel developed EFI and version 1.10 is theirs they then gave that to the UFI consortium which has all the major players you'd expect in it and they're up to version 2.1 of the spec and they've started to flesh out security now so for example the trusted computing group have also released specs to say how EFI is supposed to link in with the TPM and how we can actually start doing a secure boot process for EFI kind of I put this in just to demonstrate the point about complexity this is what the UFI spec says this is how you have a PE file that you have to sign and ultimately I'm sure there's going to be code execution bugs as I talked about implementation flaws so some summary and conclusions here EFI is interesting it offers a pretty large attack surface versus a legacy BIOS the fact that these high level development tools are available the fact that you just need to be able to write C code is basically now making it a target for much more of a target than the original BIOS was I will expect that in the next few years we will see some attempt at malware that runs in the EFI environment the third party driver model presents an easy target you can download the development kit and write your own EFI application or driver pretty easily the EFI spec is pretty vague on security it's an interface sorry, it's the interface, it's not the implementation but I would have preferred to see some more concrete information on what they're expecting for example the actual framework so Intel's implementation doesn't go into a great deal of detail about how the sec phase should be implemented UFI is starting to make things a lot clearer but I really believe there will be code injection attacks so that's pretty much as far as I've got on EFI right now if I was to say what the key kind of take away from this talk I think it would be that we should all be concerned about system management mode I don't necessarily think it's a threat that we're going to see any malware like run of the mill malware that tries to get into system management mode but it's something to keep in mind when people are talking about virtualized root kits I'd actually be more concerned about system management mode because that's probably on your processor whereas virtualization it's obviously not on all processors right now so thanks very much