 All right. Thank you. I'm Tramel Hudson and I really like to take things apart. So in this talk I'm going to be talking about Thunderstrike, which is a EFI firmware root kit for Apple MacBooks and The talk is going to have a few parts the first half is going to be about the sort of the journey of reverse engineering the EFI bootrom in the MacBook the second half is going to be about developing the Thunderstrike vulnerability and then the third half is going to be about mitigation strategies. What can we do to prevent it that hopefully are better than epoxying the ports shut? So reverse engineering is a hobby of mine. One of my more famous projects is the Magic Lantern firmware for the Canon cameras. It's a GPL runtime that lets you write your own software. I also really enjoy retro computing and digging through old computers and in the ROMs to see what sort of Easter eggs there are such as this Mac SE that contains a four photos of the team that worked on it back in the mid 80s. And I'd really like to thank my firm Two Sigma Investments. It's a high tech hedge fund in New York City that has encouraged me to do this research and to publish it. I'd especially like to thank my colleagues Thor Simon, Victor DeCovny and Larry Rudolph for their assistance in preparing this for publication. You might ask why is a hedge fund interested in this sort of vulnerability? And it really comes down to security that we care about the security of our data and of our systems. And we'd heard about some some attacks on MacBooks and we were thinking about deploying them. So I was asked to use my reverse engineering skills to look into some of these attacks. So I started by going through and reading and watching conference presentations. And there's an enormous amount of marvelous presentations. In fact a lot by people who are even here today that helped teach me about how systems boot and how to protect the boot process. Although most of them are looking at the the Intel and Windows side of things, the secure boot path. And comparatively few are looking at Apple's boot time security or things like Thunderbolt security. The snares black hat presentation in 2012 was the one that actually started me on this project. So with most reverse engineering projects the first thing that you need to do is get into the system to get a feel for what's there. Apple uses these pentalobe screws to make it a little bit more difficult to get in. I did it the old fashion way and made a bit of a mess. But you can also buy screwdrivers for a few dollars . So once you get inside, Apple has done a beautiful job on the aesthetics of this machine. Despite the fact that they make it so hard to get into, they've really paid a lot of attention to the aesthetics and the layout. Usually what happens with malware is it comes in over the Wi-Fi or the Ethernet, gets a buffer overflow into RAM, gets some code running on the CPU that eventually writes something to the hard drive. What this talk about, though, is the boot ROM, which is this chip over here. If we zoom into it, we can read out the part number, the 25L6406. And we can look up the datasheet. It's a 64 megabit, 8 megabyte serial flash. And we call it a boot ROM, but it's really an EE prom with flash memory in it. SPI means that it has data in, data out, and external clock that's controlled by external hardware. What a lot of other researchers have done is used the bus pirate, which is a off-the-shelf logic analyzer tool and comes with these test clips so you can easily hook it up. The problem is the bus pirate is kind of slow. It takes a couple hours to read and write the ROM, and it's very fiddly. Since I do a lot of work with ROMs, I've actually built a SPI flash reader based on a teensy, which is kind of like an Arduino. The sources are at GPL, and you can download them and have at it. This one can read the ROM in a few seconds and write it in about a minute. One word of caution, if you're doing reverse engineering of this, disconnect the battery before you hook up the external programmer, otherwise you'll have conflicting voltages on the rails, and as the voice of experience, that's not a good thing. So two years ago, when Snare was doing his work, he found that if he changed the ROM at all, the machine wouldn't boot. And he conjectured that there's something checking a signature on the boot ROM, and that made me very curious. What is doing that check? So I repeated his work, and I made a one-byte change to somewhere in the ROM, and the result is pretty much a bricked machine, that there's no lights, no sounds, no sign of any life at all from the outside. But since we have the bottom off, we can flip it over, and we can look at the inside, and when we power it up, the fans spin up, the CPU cooling fans, and then a few seconds later, they spin down. And that indicates that something is checking the ROM. It could be an external piece of hardware, which a lot of folks have conjectured, or it might just be something in the boot ROM itself, which of course leads us to question, what is doing that? If it is only software, we could perhaps bypass that check, and the easiest way to figure that out would be to change the first instruction that gets run. And to find out what that is, we go back to the late 70s, early 80s, for the 8080, because when your modern X8664 starts up, it boots in real mode and reads the first instruction from what at the time was the top of physical memory at one megabyte, and then does a jump somewhere else where in memory to finish the initialization. Using the bus pirate or the flash ROM tool or my SPI flash reader, we can disassemble that part of the ROM, and we find that indeed, it starts with a cache in validate that's actually new, but it does a jump lower in memory to finish the initialization. What if we change the address that that jumps to? So rather than jumping off to there, it just creates an infinite loop, and it will just spin there. When we flash, using the system program, when we flash this into the ROM, there are two possibilities that could happen. The fans might spin up and then spin down again, which would mean that there is something outside that's actually checking that ROM. Or the fans might just keep spinning continuously, which would indicate that there's only a software check. I'm up here today, so there's probably not too much of a surprise as to what happens, but yes, the fans stay on. So this gives us one bit of output before the rest of the system has started, that we now know a way to signal what's going on. And this infinite loop is a very common reverse engineering technique, you can drop it somewhere in the code, and if the system hangs, that means that your code is running. But this also means that there is no external hardware. Apple used to have a TPM on their motherboards, but they actually removed it because they weren't using it at the time. So it's a quick recap. We can now reprogram the ROM with the system program and hardware, and we know that there's no external hardware that's actually checking the ROM validity. But something is checking the validity, and we need to find that piece of code. So to figure out how the ROM is organized, we can go to Intel's EFI specification for their firmware volume. And it has this field labeled signature, which sounds perhaps likely, except it's literally just the four characters underscore FVH. There's this check sum, but it only covers the header. And the other interesting thing in this section is the zero vector, which isn't really defined what it's used for. So we'll come back to that. If we do a hex dump, and there will be some hex dumps in this presentation, if we do a hex dump of the top segment of the ROM, basically the last 64 kilobytes, we can spot that underscore FVH signature pretty easily. And there's the 16-bit check sum here, covering these hex 48 bytes of header. And the zero vector we can see is not zero, it contains something. Those first eight bytes were always the same in every firmware volume in the ROM, but these last eight bytes varied between each of the firmware volumes. And so that's interesting. To try to figure out where things are in the ROM, we can use a tool like strings. And what's interesting is this ROM image actually doesn't have very many strings, but we can find things like that FVH signature. And then a few bytes later, this really tantalizing string that says ROM integrity. So let's fire up our interactive disassembler. I'm using Hopper in this case on that section of the ROM. And apologize, a little small. The slides will be available if you actually want to dig through it later. We can see that it does a comparison of that signature, the FVH. And then there's this chunk of code here that computes some stuff with the length and then it does something with the offset eight into the zero vector at the start of that firmware volume. One thing Hopper can do is give us pseudocode that we can then massage into something that looks kind of like C. And what we can see is that it's calling a function on the data part of the firmware volume, storing the result in that address. And then it compares it to that part of the zero vector. So this function is clearly involved in somehow in checking on that validity. Using Hopper, we can interactively step into that function. And we find that it does a bunch of stuff in a loop reading over the bytes of data, but also accesses this table, 32 bits at a time. As Rudolph suggested two days ago, when you run into these random hex values, toss them into a search engine. And you never know what you're going to find. In this case, there's that constant and there's the next five constants. So a lot of our reverse engineering is done. We now can probably guess this function is CRC 32. And in fact, we can now make a one byte change to the firmware, manually compute that CRC 32, reflash it with the in system programmer. And it now works. So we have a new bullet point that there's only a boot time CRC 32 check of the ROM. This is not a cryptographic check. This is only to ensure that the ROM has not accidentally been corrupted, or that somehow it has been misprogrammed. So simply by regenerating that CRC, you can change the ROM. You might ask, why isn't there a cryptographic check? Other researchers have looked into this and come to the conclusion that the flash ROMs are only checked when they're being updated. And once it's written, it's never checked again. One possible reason for that is for speed to have a faster boot time. But doing the CRC requires reading through the whole ROM anyway. So it's not like you're going to save that much time. The real reason is that malicious software can just skip the checks. But if you can write to the ROM, you can just change that whatever the function is and to always return true, or it can return a pre-computed hash value. So without any cryptographic hardware to help out, a software-only attempt is doomed to failure. Earlier, I mentioned that there weren't a lot of strings in the ROM image. In all 8 megabytes, very little of it had any actual human readable strings. Most of that was up here in the early boot code. And there are two copies. I don't fully understand why. This is a graph of the entropy of the ROM generated with a bin walk, which is a really great free software tool. The zero entropy regions are free space. They're all Fs. And the rest of the ROM is very high entropy, which could be encrypted or compressed. So to figure out what part of the ROM to look at, we can decode the flash descriptor region of the ROM. And Flash ROM tells us that the BIOS is the latter part of it, from 190000 up until the end. So let's look at what's stored at the start of that BIOS region. And again, we can go back to our hex dump. And it looks like a firmware image file section. So we've got three bytes for the length, about 15K for this section. The next byte is the section type. And type one is a compressed section, which matches well with what we thought. So we then turn to the compression section documentation. And we see the next four bytes are going to be the uncompressed length, about 36K, so they've got a little better than two to one. The next byte then is the compression type. And they've got type two, which is not defined in the specification. So that's a bit of a problem. What I did notice, though, is that these next four bytes in all of the firmware sections were the same. What do we do when we see something like that? Toss into the search engine. And we get a perfect hit for LZMA at compression level negative seven. So to verify this, we can use a tool like DD to extract the compressed bytes, skipping that nine byte section header, filtering it through LZCAT, which will decompress it if it's a valid LZMA format. And no complaints from LZCAT. That's great. The file sizes match up with what we saw in the header. And there are now human readable strings. These are just absolute golden if you're doing reverse engineering, especially printf strings, those percent 0D and percent 0S and whatnot. Those are what tell you how things are happening inside the code. So once you have that sort of thing, it's very, very easy to start figuring out what else is going on. So we now know how the firmware volumes are compressed. It's type two. We can flash new code with the insistent programmer after recompression. I'm not the first person to figure this out. I'm quite certainly not the first person. But I've never seen anyone else write it down. So I wanted to make sure that this is now out there where other people can start working with these firmware volumes. Thank you. So why can't we write to the boot room flash from software? Why do we still have to use this hardware programmer? It turns out that the flash is not directly connected to the CPU. That the flash over here is actually connected to the platform controller hub. And access to it is mediated by things like the management engine. When the system boots, the UEFI forum recommends that all of these regions be locked as quickly as possible. This is done via registers like lockdown that control access to the configuration, the rewrite access. And they can only be cleared during a hardware reset. So this means that once the system is booted, you can't write to those parts of the ROM. But we know that Apple updates the firmware that they pretty regularly ship UEFI and SMC firmware updates that write new code into this ROM. And it has a really nice GUI that will make sure it's the right version for your system and whatnot. But under the covers, it's using a tool, a command line tool called BLESS that takes the SCAP file that is stored in the image that you download and copies it to the EFI system partition. And then sets a EFI NVRAM variable. So the next time the system boots, it sees that variable. And it does what's called a recovery mode boot. So the SCAP file is another undocumented blob that we need to figure out what's actually in it. What are they doing in there? So hex dumps are, it's been too much of my life staring at hex dumps. And it's kind of a good way to get accustomed to what's going on in the machine. We can easily spot the file volume signature there. But it's not at the start of the file. It's actually offset by about 50 bytes. And we see that there's a 50 byte value amongst all those zeros. Based on the firmware volume specification, we know that that's the size of the volume. And we see there's a similar value elsewhere in the header, which actually matches the size of the total file. One thing that you encounter a lot if you do EFI firmware reverse engineering is that there are these 16 byte GUIDs, which they can be frustrating, but they're also marvelous search engine targets. So when we toss that into whatever search engine, we get a perfect hit on yet another EFI specification document. And as expected, here's the header size, here's the image size. And the rest of the fields are all zero. But one thing that we noticed there is that there's an extra 220 hex bytes at the end of the file. So let's look at that. Again, hex dump in it. And it's all high entropy. There's nothing human readable. It's just random values. Well, on the off chance that this might be another GUID, what do we do? We search for it. We get one hit. And it's a mailing list post from just a couple months ago. I wish I had actually found this much, much longer ago. And it's describing a RSA 2048 SHA256 signing and gives us a structure that's 210 hex bytes. So this matches very closely to the trailer that we're seeing. So this is a pretty good idea of what's going on there. So my next step would be let's try to check that. And this is a Perl program. I realize Perl may be worse than Assembly for some people, but it's handy. So it reads in the SCAP file and extracts out the firmware volume and then the RSA public key and the signature based on that structure that we found in that mailing list post. It then uses the default RSA exponent since there's not one stored in there. And I really need to give huge thanks to my colleague, Victor Dukovny, who suggested swapping the byte order to put it into a big Indian. And once we've done that, we built the RSA key. We verify the signature and it's okay. So we now know how Apple is signing their firmware updates, which not only do we know how they're being signed, but we know that the BLESS tool doesn't check the signature, that something in the boot process that does it. And as a word of warning, if you BLESS an invalid file, BLESS will happily copy to the partition, set the variable, and you will brick your machine. You will have to do a full in-system programming reflash of the ROM to clear that. So where are those signatures being checked? We know somewhere in that update process. But it could be hardware, again, the management engine or the SMC perhaps could be helping out, or it might just be software. So if we do a binary grep for those GUIDs that we just found, we find one file in the uncompressed ROM that matches. And it actually matches all three of them. So if we look at the bit of code that works with them, we find that it does the GUID compares, as we'd expect. It checks the file size along with that hex 220 byte trailer. And it also then references this GUID, which is the DXC services table, which becomes very interesting. If we step a little bit further in the code to what refers to the DXC table, we find that it passes the firmware volume, the contents of the firmware volume through a function pointer at offset hex 98 in the DXC services table. To find out where that is, we go back to the specification and they don't give us offsets, but we can count eight bytes at a time because we're in long mode here. And we find that that is calling process firmware volume. That takes the RAM copy of the firmware volume and essentially mounts it and makes it available to other functions in the firmware. If that succeeds, it then calls another function at offset hex 80. And this is dispatch, which will execute any code that was in the firmware volume that was just mounted. So assembly is a little messy. Let's translate that to some pseudo code. We see it does the GUID check. It does the RSA check on the SHA-256. It then calls process firmware volume and dispatch. And that then jumps into the flasher that's in the SCAP file. So we can now, because of what we've learned already, we know how to make modifications to the ROM to find out, you know, to try things out. So one question that I had is, is this RSA check the only place that it's done? Or is something in the management engine or some other hardware also doing it? So I can just comment it out. I can just, you know, put jumps around that so it doesn't get executed. And then I can generate a bogus SCAP file. Now, here's the trailer on it with the usual GUIDs and whatnot. But that is pretty clearly not a valid RSA signature in the file. So if I bless this SCAP and the machine bricks, that means that some piece of hardware is also checking it. But if the system accepts this SCAP file and updates the firmware with its contents, then that means that it's just software. Once again, I'm up here giving this presentation so you can probably guess what happens. The firmware gets updated, which, again, is pretty fascinating. This means that the firmware signatures are only being verified by software. There is no hardware involved. So next question is, can we, could we do this sort of change without internal access to the system? Right now, to make these changes, we have to open the machine and to the ROM. And based on the work that Snare did with the Thunderbolt port, I thought we might be able to. So Thunderbolt brings the internal PCIe bus to the outside world. And when the system starts up, it enumerates all the devices on the bus, and it asks if they have any option ROMs that should be executed. Option ROMs are a legacy feature that literally goes back to the very first IBM PC with that Intel 8080. The BIOS was typically a Masquer, a UV ROM, and there were these six sockets where you could put in optional ROMs that would have things like basic and device drivers for other things. And the ISA expansion bus cards could also carry their own ROMs that would then become available for the BIOS. So that's, we're talking about a legacy feature going back 35 years here. Using it as an attack vector is not a particularly new idea. John Heisman at Black Hat in 2007 showed how to put an attack vector onto an expansion card. And Snare's work on the, was pretty damn awesome. He built a gigabit ethernet Thunderbolt adapter that could backdoor the OS 10 kernel. And that was done in 2012. That flaw is actually still in Macbooks. So, you know, if you put one of these Thunderbolt adapters with the option ROM exploit on it and boot the system, this is one that I built, that will capture your file ball password. I have since changed it to a password one, which is much more secure. So the problem is that option ROMs can't write to the flash because they are loaded in the DXE phase of the boot, but the flash is locked during the PEI phase. However, except during boot ROM firmware updates, in which case the flash is not locked. And we saw that the flasher, the flasher code is running in 64-bit mode, which means the firmware update program is also running in the DXE phase, along with the option ROMs, which leads me to question, are option ROMs also loaded during those firmware updates? And the way that I wanted to figure that out, I could go through and do a bunch of reverse engineering and walking through code and stuff, but that's too much work. So I go back to the infinite loop trick, and I built an option ROM that just does an infinite loop. The EFI firmware is single threaded, so this will basically lock up the machine. So now if I connect the Thunderbolt device with that infinite loop option ROM and power on the machine after blessing an SCAP file, if it goes into the firmware update, that means that the option ROMs are not loaded during a recovery mode boot. But if the fans just spin and the machine appears to be bricked, then that means that the option ROMs are being loaded and executed. So do you guys know what the answer is? Yes, option ROMs are loaded during the recovery mode boot. However, there's a minor roadblock that there is a PEI 32-bit mode signature check of the SCAP file before the option ROM gets executed. So is there a way that we could bypass that check? If we go back to that pseudocode for the flasher verification, remember that process firmware volume is being called via a function pointer that's in RAM, not in ROM. So the option ROM could replace that function pointer in a process called hooking. So we can modify the option ROM to now to hook the process firmware volume function pointer and replace it with its own. And it also then stores the old one so that it can reuse it later. If you have a sufficiently large option ROM, you just put your whole firmware exploit in there and it's game over. However, the one that we're using, the Gigabit Ethernet adapter, only has about 32K of space available. So we can't put a full 8Meg ROM image in there. But what we came up with is actually even more interesting, that we can instead put in an RSA public key that we control and the processFirmwareVolume function will search through the firmware volume looking for Apple's public key. If it finds it, it memcopies our public key over it, then fixes up the CRC32 since we now know how to do that. And then it calls the old processFirmwareVolume on this now modified image. And when we now boot the machine again with the Thunderbolt device with what we're called the Thunderstrike exploit because all cool exploits have names these days. So when we boot up the machine, the here's the exploit code running in the recovery mode boot and we're not worried about stealthiness in this proof of concept. And now here is Apple's own firmware update routine flashing our option ROM with our RSA key into the boot ROM on the motherboard. And once that's done, we now own the system and we can flash whatever we want using Apple's own update tools. So and all exploits also get logos and I think theme songs and websites now. So we now know how to circumvent flash security with the option ROMs. And because we've replaced the key, this boot can't be removed without through software alone because we control the key that the firmware is going to use that there's no official channel that can remove it. So how would something like Thunderstrike if it were to be weaponized actually be deployed? You know, one option is something like what the NSA is doing where they intercept shipments of hardware and make modifications as they're seen here doing to SSCO routers. The other ones, the evil mate attack that folks hypothesize in which you're at a conference say in Hamburg and you go down to the hotel to get some breakfast and room service comes in and they make the bed and back door to your laptop and leave some fresh towels. Or when you're flying through international borders. In fact, the US courts have said that there is no protection for citizens or visitors alike at the US border. In fact, in this decision against the US citizen photographer that they said that the laptops are the most dangerous contraband and you have no expectation of privacy. So this vulnerability is in pretty much every MacBook since about 2011 when Thunderbolt showed up. I've personally tested about six or seven and found it in there. The pre Thunderbolt devices are not affected. These also have mask ROMs. So writing to that would be a more challenge anyway. You guys might also have heard of another exploit called Stuxnet that spread via shared USB media and was able to get all the way into the air gapped SCADA systems of Iran's nuclear refinement system. It turns out that option ROMs on extra on Thunderbolt devices can be written from that early boot code. So this allows Thunderstrike to actually spread virally through shared devices. So you have a Thunderbolt device that you share between machines at work and it is able to go across them. So all Thunderbolt Mac books are vulnerable. They can spread virally. What can we do to prevent this? So I've been in contact with Apple and they have a, on their new machines, the Mac minis and iMac retinas that we've tested, they're no longer loading option ROMs during firmware updates. They will be rolling this out for the other Macs. However, they're still loading option ROMs on normal boots. Snare's attack from 2012 still works. You can still get backdoor'd via the OS 10 kernel. It's also possible on the older machines to do a downgrade attack that you can downgrade to an older, vulnerable version of the firmware and then attack it that way. And Thunderstrike v2 could use the dark Jedi sleep attack, which you may have heard of. It was introduced yesterday here at 31c3 by Rafa and Corey. And what they found is that during a s3 sleep, all of the lock bits are cleared, including a flock down in the BIOS control. The Thunderbolt option ROM is in a prime position to be able to do the sort of attack. It doesn't need to do any privilege execution. It's already running in ring zero. So there was not enough club mate for me to actually implement this last night, but look forward in an upcoming paper, perhaps. So Apple could add TPM hardware back to their Macs. It wouldn't prevent the dark Jedi attack, but it would at least let you detect it on the next boot. They could also implement driver signing. Future EFI protocols have it as almost mandatory, but the version they have has this rather ill-defined security, architecture-specific security protocol. And they do implement that, but this is the entirety of the implementation. And it turns out that actually proto can never be null, so it just unconditionally approves every option ROM that it encounters, which does not provide any security at all. So because I don't think option ROMs are a great idea and none of my devices need it, I've modified all of my MacBooks to bypass this call to process option ROM. And Thunderstrike actually does this on the systems that it infects, so you can't actually use Thunderstrike to remove Thunderstrike. It's closed the door behind it. However, closing down the option ROMs might not even be enough. How many of you plugged into the projector up here? How many of you actually verified what the connector was that at Black Hat earlier this year, the alloy viper was deployed? It's a decoy VGA adapter. It's kind of hard to see there, but it daisy-changed to a real VGA adapter, going through a slot screamer, which is doing active DMA attacks against the PCIE bus of the running system. And it can backdoor OS X with a little bit more work. It could actually launch a Thunderstrike attack as well. So I believe that we need a way to disable PCIE functions on Thunderbolt entirely, that if you just want to use it for your display, you shouldn't have to expose your system to this sort of attack. I've done a little bit of work trying to do this. This would be a lot easier for Apple to implement as a configuration option, just like they do right now. But if you set a firmware password, the machine won't boot from external media, because that's a security risk. If you have a firmware password, it shouldn't load option ROMs. You should be able to turn off these things. You could also go a little more extreme. Last year at 30C3, Peter Stujer suggested hard wiring, right protect pins, and desoldering programmable controllers. And he went through a bunch of work on how to harden a ThinkPad against external attacks. And if you do go that far, you also should consider using some sort of tamper-evident coverings over the screws to figure out if anyone has opened your machine. This is as suggested by Eric Michoud last year, also at 30C3. So to sum up, how bad could an actual weaponized version of Thunderstrike be? There's nothing looking for firmware root kits on OS X right now. It's in control of the system from the very first instruction. It can backdoor the kernel. It can log keystrokes. It can exfiltrate data. It can't be removed by software, since it controls the RSA keys. It also controls the update routines. You can reinstall OS X, and it will still be there. You can swap out your SSD, it will still be there. You can swap out your laptop, and your Thunderbolt device might reinfect your new one. So it's very persistent. It can also hide in things like SMM, virtualization, or maybe even the management engine, although that's another area of interesting research. It can spread virally via shared devices, and it affects all current models of Intel MacBooks with Thunderbolt. So that's a pretty bad combination of things, if somebody were to actually take this and turn it into more than a proof of concept. But what would really make it worse is I think this is actually remotely installable. Combining the deep Jedi coma attack with option ROMs embedded in the system, I think this could actually be launched with just merely a root exploit onto the system. So on that cherry note, I'll take some questions, and also we'll be having a workshop for folks who want to do a little more deep dive into the into the firmware images in Hall C in a little while after the talk. Thank you very much. Tramol, we have some time for questions. First are there questions from the internet? Yes, thank you. There's one question from the internet. How many Macs have been destroyed making this presentation? I have been quite lucky, both with Magic Lantern and with this project, I have managed to not brick any machines. Okay, you can also line up behind the microphones if you have questions. There was a second question from the internet. No, then microphone number one, please. Thank you. It was very, very cool presentation. If you have been thunderstruck and you bless an original firmware, will you brick the machine? Yes. Is that something that thunderstruck can prevent? Yes. It's the proof of concept is very, very simple, and it could actually be much more sophisticated. It could detect that this is an Apple signed file and do something different. It has total control of the update process, so it could even allow the update to go and then patch it after the fact, depending on how sophisticated you want it to be. Or it might just pretend to run the update and then ignore it. Okay, thanks. Microphone number two? I understand that you have to request the EFI upgrade while that thunderstruck device is attached in order to do the exploit, or is it possible to do it just by attaching it without having an EFI upgrade? So the option ROM can initiate an EFI update that it can basically anything that the kernel could do, the option ROM could do. But does it have to be attached during the boot phase, or can it just attach it while the thing is running if I want to? So in this case, with a passive device like the Gigabit Ethernet adapter, the machine does have to be rebooted. Okay, so just attach it while it's running to a second screen should be possible, but I have to reboot it basically. Yes, you do have to reboot it. So from the perspective of someone who's been attacked, they come back and they find their machine is rebooted, or their machine is shut down, and they would say curses. It's pretty rare that Mac's crashed, but they do crash occasionally. So it's not out of the question that would tip them off. Thanks. Microphone number four. Hey, so this attack would be mitigated on PCs with Thunderbolt by Secure Boots requiring option ROM signing, right? Absolutely. So a case where Secure Boot does actually protect against vulnerability being demonstrated on stage? I believe so. Awesome. Thank you. Microphone number five. Hi, thanks. Thanks for your talk here in the back. Can you imagine this working on other laptops too, since this is an PCI Express option ROM thing, could this be done on not Apple devices too in some other fashion? So John Heesman's work was on a PC using just a generic PCIe card that had a programmable option ROM. A lot of SATA controllers have them and are potentially vulnerable. The ease of sort of evil man attacking a MacBook via Thunderbolt is much, much simpler than having to open up a PC and put a card into it. Okay. Microphone number one. So this would also apply to other machines with Thunderbolt, for example, as a better Lenovo have Thunderbolt now. And if you search off the TPM chip, then you're probably vulnerable. Or if somebody has a private key and signs some malware with a private key, then you are vulnerable, I think. Exactly. And as Matthew had pointed out, that if you have a Secure Boot that actually signs the option ROMs, then they would not be vulnerable to this. Although a device with Thunderbolt would potentially be subject to the Slot Screamer attack, which was an active PCIe DMA device. Another question from the internet? Yes, thank you. I've got two other questions. The first one is, could you imagine of a pure software solution as well? And the second one is, is there a way to detect that the ROM is tampered with? So to the software question, I could imagine perhaps someone could produce bug-free software and BIOS updates. But the number of presentations that find flaws in software, particularly in BIOS updates, makes me think a software only solution is unlikely. And what was the second question again? Is there any possibility to detect that the ROM is tampered with? So in the proof of concept, it's quite trivial. It actually advertises itself with the logo. But a weaponized version would be very hard to detect, that if it's hiding in either system management mode, it can detect attempts to read from the ROM and serve up a clean copy. Or it could boot the system into virtualization and just provide a complete virtual ROM that looks intact. Microphone number two. Are you missing any features like booting from network if you disable the option ROMs? No. It turns out that the modern MacBooks have the driver for the Gigabit Ethernet adapter bundled into their boot ROM already. So the option ROM is completely superfluous. It starts no purpose. Thanks. Number one. Okay. Two quick questions. First, if you mentioned, I think that you have to bless a firmware update to launch the attack. So if I set a firmware password and shut down my computer before I leave it in my hotel room, can I prevent it? No. The firmware password is actually checked after option ROMs. So there's a much simpler attack that an option ROM can actually just clear your firmware password. And to the other point of your question, the option ROM doesn't actually even need to boot OS 10. It can just set the NV RAM variable and initiate a recovery mode reboot from the option ROM. Because it's in ring zero. It can do pretty much anything. Microphone number three. So do you think that a open source solution, do you think that an open source solution as opposed to an open standard solution would be able to avoid this problem or have you investigated in particular core boot? If core boot is vulnerable to this problem, I believe core boot is not vulnerable to either Thunderstrike or to the Jedi coma attacks. I have not done really any work with core boot. So I'm not sure, although in general, we should talk then we should in general. I think that having open source for the for the early boot is really vital both to trust that the system is doing what we think it is. And this is one of the reasons I'm really excited about things like bunny's laptop that we're all of the source for every piece in the system is available so that we can actually understand how it all works. We are running a bit out of time. So please keep your questions and possibly the answers short microphone number four. Yes, as you've shown, the firmware update not only contains a signature, but also a public key. What happens if you replace the public key and then just create another signature? Have you tried that? I'm sorry. Oh, yes, actually the I didn't go into the presentation. I have a paper that I hope will be coming out sometime soon that actually goes into a lot more technical detail. The the public key in the signature is actually ignored. You can write whatever you want there and it doesn't matter. The the public key is actually stored in in the in the boot ROM. There are actually five public keys, but only key zero is ever read. And that is the one that is actually used to validate the signature. Thanks. Microphone number two. Have you looked at other attack factors than Thunderbolt that expose PCI lanes like express cards? I have not, but I've I've received email from someone who has looked at it and suggests that it would also be vulnerable to this sort of attack. Microphone number one again. Can I launch this attack from another MacBook with a Thunderbolt cable or do I need special hardware? That's an interesting question. I have not looked into that whether or not if you boot into like target drive mode, could you could you fake it out? Possibly. That might be cheaper than I don't know. I haven't looked enough into that part of the firmware. Microphone number five. Yes, you said that with your exploit you can close the door behind you for this exploit. Can you provide the service to close all our MacBooks? If anyone would like to borrow a Thunderbolt Ethernet adapter. So right now my my proof of concept is has a lot of hard-coded things for the specific version. So I verified that the the sort of exploit works against the other ones, but I've only actually implemented the 10 comma one MacBook. So if you have one of those I'd be happy to let you upgrade. Microphone number three. Okay, so I'm wondering since the option ROM is only loaded during boot and you can basically as far as I know prevent DMA access while the system is running by setting a firmware password and you said it's possible to write the option ROM if you are early in the boot process. Is there any way once you've booted to check if your Thunderbolt adapter has been infected? Potentially. So from a clean system you could read out the option ROM and find out if it contains the an exploit in it. But once from a infected system if it were being sufficiently stealthy it could mask that attempt to read. And you had a second question that I actually I thought was was quite good that um oh regarding DMA there's a lot of interesting work being done with Thunderbolt and DMA attacks especially looking into how well does VTD and the IOMMU actually protect you and it's not clear that it provides as much protection as we would like. Microphone number four. Okay, forgive me if this is a stupid question but other than open sourcing the boot process entirely which is a no brainer could vendors protect against this kind of attack by using something like timing based attestation of the boot firmware so knowing the timing signature that the legitimate firmware has and measuring that in the operating system or some another kind of electronic device that measures that that then if an attacker uploads their own malicious firmware they at least have to emulate the timing side channel of the legitimate firmware. So to the first part of the question I don't think so the MITRE presented a really neat piece of malware called a TIC that I think was 51 bytes and was capable of beating the time timing based attestation. The other is that it could boot the system under a virtualized environment or it could just rewrite the timestamp counter that it's you know it's in ring zero it's in real mode it can do really whatever it wants. Thank you. Another question from number four. Just very two very short questions. The one was to verify again you said the current iMacs and Macminis are not affected and future Macbooks will won't have this problem. That's so Apple has produced a fix that they are shipping in the current Macminis and iMac retinas that protects against the proof of concept however it leaves out a huge hole in terms of the option ROMs that I believe could be a Thunderstrike v2 would would fairly easily be able to attack. And the second question was proprietary TPM modules have been criticized what do you think is is are they more helpful or are they in any kind do they have any drawbacks if they're not open source so is it better to have a machine with the TPM module or without one? So perhaps TPM is not not exactly the right word but some systems have sort of you know co-processors or sometimes even hardware devices that will leave the main CPU and reset until they do cryptographic verification of the boot ROM. So that's the sort of technology that I think is really necessary to detect these sort of attacks. There's a huge number of papers about defeating TPMs and secure boot via other techniques so I'm not sure how well you know proprietary TPM versus some more open source one would really be able to do. Okay one final question from number two. Just to make sure it's not that I can't leave my computer in or I can't leave any of my Thunderbolt device either right? That's that's a great point yes you should keep your Thunderbolt devices with you along with the computer. And having said that would it theoretically be possible if you do achieve code execution from the Thunderbolt device to actually perform tests through that code could I create a Thunderbolt device that actually uses an option ROM to check my own EFI? You could unless you're running unless you've already been hit in which case the option ROM won't be loaded. At all. Okay. So all of my machines are protected in this way that they will not load option ROMs which is also you know the sort of thing that would be great if it was a configuration option just to be able to say you know don't do this versus. But then you'd know if it doesn't execute then you'd know. Oh if it had some way to let you know that it had executed I suppose it depends how targeted of an attack you're expecting. Okay so please give again a round of applause to Tremul.