 Welcome back to the RC3 on the R3S stage in Munheim. Our social media channels for asking questions for the next talks are RC3-R3S on Hackend IRC, the hashtag RC3R3S on Twitter and Mastodon and the Mastodon handle at R3S at chaos.social. Up next is Björn Reitenberg who is a master student at the Eindhoven University of Technology. He is a vulnerability researcher for hardware and firmware and the talk is related to master's thesis and he played around with lightning. Yeah, so please enjoy when lightning strikes thrice, breaking Thunderbolt 3 security. It's really great to be here. This is my first time at CCC, so it's an incredible honor that I can share my research here with you. My name is Björn Reitenberg. I'm a vulnerability researcher, mainly interested in hardware and firmware security, sandboxing and virtualization. I'm also a master student in computer science at Eindhoven University of Technology and the work that we're presenting today is part of my master's thesis. So let's talk about Thunderbolt. Well, Thunderbolt is a hard performance for proprietary IO protocol developed in 2011 by Intel and Apple. And well, it's PCI Express-based and the device is possessed what is called Direct Memory Access. Now I will go into these terms in a little bit but for now you could say that based on these technologies, Thunderbolt is really the first external interconnect that allows use cases such as connecting external GPUs to a laptop or connecting 5K monitors or accessing hard speed external storage at its maximum performance. Now the first two versions were mostly exclusive to Max and used to mini-displayport form factor. Thunderbolt 3 is the first version to be widely adopted among both PCs and Macs but uses the USB-C for factor instead. And well, thereby also aside from Thunderbolt devices also allows connecting DisplayPort and USB-C devices. Right, so PCI Express, I already mentioned it. PCI Express is essentially the core technology that allows connecting your CPU to the peripherals inside your system. And it's basically a packet switch network that has many similarities to Ethernet consisting in this case of four components. So let's briefly go through them. Now the root complex essentially connects the CPU to the PCI Express network and the switches in turn provide some means to divide bandwidth both in the sense of time and actual throughput. Then there's the actual endpoints. And if you're using hardware from back in the old days then you might be able to use them by means of a so-called PCI Express to legacy bridge. So the endpoints will be mostly familiar to you and they can be anything from a GPU to a USB controller to an Internet or Wi-Fi NIC. Now, when a CPU requests data from a third-party device there are essentially two methods to do this. And the first method which we see on the left is called program IO. Now in program IO, basically what happens is the CPU issues a reach request to the third-party device. Now the third-party device will require some time to get the requested data. And meanwhile the CPU will keep polling the status from this device. Now at some point the device will be ready and then the CPU will copy the data from the device into its own system RAM and then move on to the next instruction. Now, eventually a second method was developed which is called direct memory access and that's what we see on the right. The first step in DMA is that the CPU issues a DMA read command and well it can immediately move on to the next instruction that is not dependent on the data that's being requested. Now at some point the data will be made available by the third-party device but this time the device will copy the data directly into system RAM and then raise an interrupt with the CPU. Now in a way DMA is you could say the cornerstone technology to PCI Express. So for example if the CPU requests data from a SATA SSD then the SATA controller will fetch the data from that SSD and place it directly into system RAM and then finally raise an interrupt with the CPU. Now DMA is a very powerful concept and basically only because it puts the burden of copying the data into system RAM on the device. From a user's perspective this is of course great because this means lower latencies and much higher bandwidth. From a security perspective this could pose a threat and this was actually the case with Thunderbolt 1. So with Thunderbolt 1 only attacker had to do was connect a malicious device and then it would immediately get unrestricted read and write memory access which in turn would enable them to access data from encrypted drives and even gaining persistent access for example by installing a root git. Now DMA attacks are generally well understood. First started with FireWire back in 2004 and over the years gradually moved on to PCI-X Plus including all of its form factors such as a stress card and two and eventually Thunderbolt. Now when Hollywood wants to show you what a hacker looks like this is the kind of picture that you will typically see. But what you should be actually looking out for is the person looking like this while the person in the background of course. So the threat model that we're talking about tonight is brief physical access to victim systems also known as an evil maid attack and some of the example scenarios that you can think of are for example, laptops that is locked or set to sleep and they're being left unattended in the hotel room or desktop systems sitting in an office and at some point a cleaning crew comes in and has brief unfettered access. So over the years the industry developed several measures against this so-called opportunistic physical access. So let's briefly go through them. First one is really simple you put a password or your bias so when the attacker gets all of your laptop they cannot change any of the system settings. Second one is called secure boot. Secure boot basically verifies the entire boot chain starting from the OS boot loader all the way to the kernel and the five strivers. Boot card focuses on critically verifying the bias itself. There's full disk encryption. Well, if you enable full disk encryption and the attacker gets all of your laptop well they could disassemble the SSD from it but they still would not be able to read the data unless they know the correct password. And finally in terms of Thunderbolt well into introduce what they call security levels and security levels are intended to protect the entire thing that you see right here. All right, so let's dive a little bit deeper into the Thunderbolt security architecture. Basically security levels is an access control system. So for example, if you have a Thunderbolt powered hard drive and you attach it to your laptop for the first time then you will get a pop-up and the pop-up will let you identify the device. Now at some point you will choose to authorize the device and then when the second time or any subsequent times when you attach this Thunderbolt hard drive it will start working immediately without prompting you again. Right, so Thunderbolt security levels they rely on Thunderbolt devices authenticated to the host and the devices do this using the parameters shown right here. The most important one being the universally unique ID or UUID. Now this number is intended to like the name says uniquely identify any single Thunderbolt device in the world and it's also defined to be fused in silicon so it shouldn't be easy to change. Right, so security levels is a multilevel system. As a user you can select any of these in the BIOS so let's quickly go through them. There's SL0 which means no security and that's basically the same situation as with Thunderbolt 1. There's SL1 which means that device authorization is based on the UUID. SL2 is similar to SL1 but adds what Indokal's cryptographic device authentication. SL3 disables Thunderbolt but still allows USB-C and display port devices. Now some newer systems supports SL4 which is intended for use with Thunderbolt docks. So when you connect to dock you cannot connect any additional devices through that dock via so-called DC chaining. And if you're using SL1 or SL2 you get pre-book protection for free. So essentially that means that at boot time you can start using devices immediately and all the other devices will be rejected. Right, so security levels, they're mostly known for protecting against DNA attacks specifically the device to host DNA attacks but since it prevents PCIe endpoints from accessing the PCIe domain it protects against a lot more PCIe inherent attack factors as well such as peer-to-peer DNA attacks and PCIe ID spoofing to target vulnerable device drivers. And finally of course TLP source ID spoofing. So in essence security levels is really a powerful and much needed protection scheme. So introducing ThunderSpy. Well previous research before security levels mainly focused on PCIe level DNA attacks to compromise Thunderbolt security. After the introduction of security levels they mostly focused on tricking the user into authorizing malicious devices. Now ThunderSpy is a new class of vulnerabilities that really breaks Thunderbolt protocol security thereby being the first attack on Thunderbolt security levels. And so what we're presenting today is seven vulnerabilities and nine practical scenarios to exploit them. So the first red step in your research was to find out how Thunderbolt works and well Thunderbolt is a proprietary standard. So if you try to look at protocol specifications you will not find them. And if you try to find diagrams that would tell you what the hardware architecture is like you will not find it higher. So the first thing that we did was dissecting Thunderbolt devices and Thunderbolt equipped systems. Now eventually we came up with this diagram that I'm showing here for future research. So starting with the Thunderbolt host controller on the PC end. Well the Thunderbolt host controller connects to the PCH and the DGPU and ITPU take care of generating a discord signal. On the other hand there is the USB power delivery controller which multiplexes between USB signaling for the PCH and Thunderbolt as appropriate. On the device side we kind of see a merit version of what we see on the PC. So the Thunderbolt signal comes in gets the multiplex on two PCI Express on the one end and if it's a device with two ports Thunderbolt on the other which in turn allows connecting a another Thunderbolt device or a USB-C or just the port device. Right so let's have a look at some Thunderbolt devices. We'll look at various Thunderbolt devices starting from simple Thunderbolts to ISADA adapters to storage solutions, Thunderbolt docks and eventually EGPUs. They were pretty much all the same but this NetStore NVMe enclosure had a really nice clean PCB layout so that's why I'm showing it right here. Our prime suspect is of course in the top right corner a Intel Thunderbolt 3 host controller and there is a USB power delivery controller one for each Thunderbolt port. There's a spy flash which we'll be talking about a lot more later and an ISQUARE-C interface. Now if you have an electronics background you probably know what that means. We could get some information from it and there's an interface which appears to be JTAC but to answer your question no it doesn't work, sorry. All right so the Thunderbolt controller this is really an interesting model because it supports running in both in host and endpoint mode and it's from the so-called Alpine-rich generation so it supports DisplayPort 1.2, HDMI 2.0, USB 3.1, USB power delivery. Now in terms of analyzing how this particular controller works it's not really an attractive device to have a look at at least initially because it's the BGA package so all the pins are on the bottom and there are no public data sheets so yeah we had a look at the other chips first. The DPS is really the opposite situation there's a public data sheet and you can actually talk to this thing over ISQUARE-C for example to get some firmware identifiers and the current operational state and I think there are also some registers in there that allow you to control the output voltage so we know it's what you could do with that. The spy flash is really much the same there's public data sheet and well we dumped this content and we found that it stores the Thunderbolt 3 device controller firmware. When you dump this firmware you will immediately notice a section called the D-ROM or the device ROM and this device ROM stores all the parameters that we saw on the previous slide. Now of course the most important question is is the UUIE in there? And the answer is yes but only two out of eight bytes. Still we would like to know whether we can change any of these parameters so is there a cryptographic signature in there? Well the answer is yes there's a public key and a sign digest changing the public key doesn't really work so the fingerprint is likely being stored somewhere in silicon. Now our second question remains unanswered because we would like to know whether we can change any of these details without breaking the cryptographic signature. So what is covered by the signature? Well, not the D-ROM. Basically we found that we can create completely arbitrary device identities like the one shown right here made by the vendor totally legitimate which of course makes no sense. What's more interesting is that for example you would expect the vendor ID to be tied to the vendor name any other way around and during our research we found that this is actually not the case basically you can enter arbitrary values for any of these entries. All right so I want to look at the Intel white paper on Thunderbolt 3 security and there was this interesting section on the unique ID and it said and I'm reading off the screen here every Thunderbolt 3 controller has a unique ID fused in silicon during production. Now you already know the statement is not true because we can change two out of eight bytes but there was this interesting emphasis on Thunderbolt 3. Try to look at Thunderbolt 2 controller firmware. And well to answer your question, yes that's the UID. It's there in plain text and no it's not covered by any signatures. Now what's more interesting is that it turns out Thunderbolt 2 devices can spoof or clone Thunderbolt 3 device identities. So what does that mean when you can clone identities? Well remember in our example we had this Thunderbolt powered hard drive but this time the laptop is set to sleep or is screen locked. Well in this case this is not really an issue because the Thunderbolt powered hard drive was already authorized by the user so when connecting it will start working immediately without prompting the user. Now a new attacker comes in and tries to connect their device. Well of course the attacker device will have a completely different identity and so the system will deny Thunderbolt connectivity. Also the laptop is locked or set to sleep so the attacker won't be able to authorize their device. Now this is in theory how this protection scheme should work but during our research we found that we can actually clone identities from one device to the other. So all the attacker would have to do is get a hold of one of the user's pre-authorized Thunderbolt devices, clone its identity and then finally gain access to the laptop even if it's set to sleep or screen locked. Right so let's dive a little bit deeper into the device controller firmware. We have a jump address on top but what's more interesting is there's a secure key dictionary so when the user is using asl2 this section stores the secret keys that maps to the host controller UUID and it's there in plain text. Now there's the DRUM section which we've discussed earlier and the PHY configuration. There's the public key and the sign digest and what turns out to be the USB power delivery firmware. So this is really interesting because that means that the Thunderbolt host controller and the USB PD controller share the same spy flash. And finally there is a what I like to call scratch pad section that temporarily stores firmware updates for firmware updates initiated from the host. Right so let's have a look at some Thunderbolt Equip systems. We have a look at Thunderbolt Equip systems from all major vendors across five generations of Thunderbolt controllers starting from Falcon Reach on Thunderbolt 2 all the way to Ice Lake on Thunderbolt 3. They were pretty much all the same but this Lenovo had a really nice and clean USB layout so that's why I'm showing it right here. If you've ever opened up a laptop most of these components will be familiar to you but of course the most interesting components are in the top right corner. Starting with the Thunderbolt host controller a dual port version in this case. The TPS slightly different version that we saw on the devices and the wind-borne spy flash which we'll be talking about in a bit. Now for the host controller the key questions are well first there is the option to change security levels in the BIOS and so this kind of seems to suggest that the BIOS stores the security level state. But if you want to know whether it's actually true. Now when the user selects either SO1 or SO2 this requires storing device UI IDs and so we would like to know where this device is stored. So we had a closer look at the host controller firmware and essentially it was very similar to the device firmware but there are a couple of important differences. First one being there's no security key dictionary and there is a list of allowed devices, UUIDs. So this is really interesting because when the user selects SO2 this means that at boot time the device authorization still happens based on the UUID only which kind of seems to contradict Intel's claim. Now there's the D-ROM, again the PHY configuration and all the remaining components that are the same. But there was another important difference. We found that it stores the host security level configuration and to answer your question, yes it's in plain text and no it's not covered by any signatures. So all the attacker would have to do is patch the host controller firmware to, for example, disable Thunderbolt security entirely or re-enable Thunderbolt connectivity when it was disabled by the user. Right, spy flashes, they're really interesting devices and usually support some kind of write protection mechanism. Now this particular wind bond we found in a lot of samples that we had access to and well this model supports five types of write protection and one is called one time program. Now one time program essentially turns the spy flash into a read only memory. So from that point on, the data that is stored on the spy flash can no longer be changed. Now in the footnote it says special order but we found during our research that a lot of samples that we had access to still appear to ship this kind of support. So as an attacker this opens up a new attack factor because basically what the attacker could do is exploit the previous vulnerability to disable Thunderbolt security entirely and next exploit this vulnerability to disable Thunderbolt security permanently so that the user could never reactivate Thunderbolt security ever again. Right, so to summarize basically there are two attack methods. So the first attack method requires brief access to the laptop to reprogram the host controller firmware and this only takes under five minutes. It does not require access to any of the user's Thunderbolt devices. Now the second attack method is kind of the inverse so it does not require access to the host controller firmware but only requires brief access to any of the victim's pre-authorized Thunderbolt devices. Now the impact is really the same for both so attacker could get unrestricted written rights access to system memory access data from encrypted drives and get persistent access by exploiting vulnerability six or installing a rootkit. All right, so let's have a look at how attack methods one can be used in practice. So what we have here is a Lenovo P1 which was purchased last year and as you can see it's in sleep mode. Yes, it's been locked so I don't know the password and the password isn't empty either as you can see. So that's all good. What we're gonna do now is turn over the laptop so that we can reach the backplate and we unscrew the backplate. Right, there we go. So now I'm going to attach my spy programmer which is a device called BusPirate and it allows me to interface with the spy flash that is storing the Thunderbolt controller firmware. So attaching the BusPirate to my attacker laptop and now we're going to use a tool called flash ROM to get the firmware from the spy flash. Right, so now I have a dump and I'm going to feed that dump to a tool that I wrote which is called Thunderbolt Controller Firmware Patcher. And so as you can see apparently the Thunderbolt controller was set to security level one which is the default security level on all Thunderbolt laptops and I'm patching it now to an insecure state. And so as you can see it says SL0 which means all Thunderbolt security is disabled. Now we're going to write back the firmware to the spy flash. Now this might take a bit because flash ROM will be trying various methods to program the spy flash and as you can see eventually it will succeed. Okay, so now we've written our custom firmware to the spy flash and we're detaching the spy programmer and putting back the backplate onto the laptop, turning over the laptop and opening it up. Now, as you can see it's still up and running. We still can get into the laptop and here I'm attaching my Thunderbolt based attack device. Now what you see here is a device that will be attacking the laptop and we're going to use that device with a DMA attack tool called PCI Leach developed by Ofrisk and here I'm loading a kernel module into the memory of the laptop which allows me to bypass Windows lock screen. We're entering no password and there we go. You can get into the laptop. Thank you for watching. Right, so let's have another look at Thunderbolt security levels. This is how it's defined and well, let's have a look at what we found it to mean. So starting with as a one, device authorization is based on the UUID. Well, this UUID is not really so unique because they can be spoofed and no, the UUID is not really fused in silicon. As a two stores secret keys on the spy flash. Sure, that could work, but they're in plain text so that can be cloned. For SL3, well, SL3 disables all Thunderbolt security. That could work, but the attacker could reprogram the host controller firmware to disable Thunderbolt security altogether. There's SL4, which was really puzzling to us because all the attack would need to do is unplug any existing devices or just pick another Thunderbolt port. And finally, pre-boot protection. Well, pre-boot protection has no effect because all of these security levels are essentially broken. All right, so if you're feeling adventurous, you can try any of these tools that you saw in the demo yourself. I've published them on my GitHub repo. The first one is the Thunderbolt controller firmware patcher and the second one is called spy block, which lets you configure all flash drive protection. Quickly moving on to effective systems. So all Thunderbolt equipped systems shipped between 2011 and today are vulnerable and this especially applies to all PCs released between 2011 and 2018 because they are fully vulnerable. All Macs running Windows and Linux using Bootcamp are fully vulnerable as well. Now some systems providing kernel DMA protection, which we'll be talking about in a bit, are partially vulnerable. And if you're using macOS, please keep doing so because systems running macOS are also partially vulnerable. So if you would like to check whether your system is vulnerable, have a look at our tool spy check or follow the manual authentication steps on our website. All right, so Intel's response to ThunderSpy was what you could say quite underwhelming and essentially what they suggested is kernel DMA protection. Now kernel DMA protection is an opt-in DMA remapping mechanism for vulnerable devices. And according to Intel, all you need is a recent version of Windows 10 or a recent version of the Linux kernel. So let's have a look at how that works. Well, normally when a device does DMA to the host, it does so directly to the IO additional region in kernel space. With kernel DMA protection, there's an IO MMU in between. And so the PCI Express endpoints, including those in Thunderbolt, would not be able to read or write outside the memory range that is signed by the IO MMU. So all in all, it sounds like a sound strategy, but what Intel didn't tell you is that this is a partial mitigation only. Specifically, it only mitigates vulnerabilities 4.2.6. And yes, it prevents attacks via DMA, but it does not prevent vulnerabilities 1.2.3 from being exploited, which leaves the system open to, well, what is called back USB style of attacks. Also, kernel DMA protection requires IO MMU and BIOS support. And this BIOS support during our research we found is only available on some systems released since 2019. So all the previous systems, starting from 2011 to 2019, do not support this kind of protection. So no fix from Intel. So essentially what they're saying is, if you bought a laptop in the past nine years, just buy a new one. Well, obviously it wasn't the answer that we had hoped for. So we had a look at the question, what is actually needed for the system to support kernel DMA protection? And it turns out it's this list of components. So let's briefly go through them. First, there's the IO MMU. Well, it turns out that most systems since Haswell ship with an IO MMU. The DMAR table, well, if the CPU provides an IO MMU, the firmware also ships a DMAR table. We need a system capable of running either of these recent OS versions. Well, obviously this is the case for all Haswell systems and newer. And then there's this UEFI support, which apparently is not present. So we had a look at what this UEFI support actually means. And it turns out that we had to take a look at the DMAR table. And in the DMAR table, there is a flag which denotes which DMA remapping features have been enabled. Now for kernel DMA protection to work, all we needed to do is search two bits, one for enabling interrupt remapping, and the other is called DMA control platform opt-in. And then finally chain loads the OS bootloader. So that's what we did with Thunder Spy 2, which is not an attack, but two methods that bring kernel DMA protection to roughly six years worth systems. The first method is called kernel DMA protection patcher. You can find it on my GitHub repo. Essentially what it does is, well, patching the ACPI table using a UEFI module is OS agnostic, so it works with both recent versions of Windows 10 and Linux. The second method, if you're using Linux, basically comprises mentally patching the DMAR table, and you can find the steps to do so in the guide that I linked right here. Now in terms of protection, the protection level is similar to officially supported systems at OS runtime. It does not protect against boot time attacks, but the good news is that screen locking and sleep modes are covered again. Linux users will soon have another option as we're working with the Linux kernel hardware security team to develop kernel level mitigations. Meanwhile, Linux users can still use KDMA P patcher. If you do so, we would recommend to sign the UEFI extension using your own keys and for additional security, firmly combine it with measured boot using, for example, TBM-enabled grub or heads. Right, so let's have a look at how kernel unit protection patcher works in practice. This is a Dell XPS 15 purchased in 2018. Now, when we look at MS-info 32, we see that it is running Windows 10 20 H2. And since it's a 2018 model, we see this laptop does not support grilled DMA protection as expected. So I've pre-compiled KDMA P patcher and we'll now copy it from a USB flash drive. There you go, that's the UEFI image. Opening up a command prompt. And now we're going to mount the UEFI system petition to the drive letter T, navigating to the Microsoft boot folder and we're copying the KDMA P patcher image. Finally, we ensure that the KDMA P patcher gets loaded first by renaming the Windows bootloader and renaming KDMA P patcher to the original Windows bootloader file name. Right, so all done. We're now going to reboot the laptop. Okay, so now in the top left corner, we see KDMA P patcher at work. It has enabled both the interrupt mapping and DMA control platform maps in flags. We quickly log into Windows and we have another look at MS Info32. And indeed it says kernel DMA protection has been enabled successfully. Right, so let's just attach a Thunderbolt 3 SSD like this one. There we go, it connected. So just for fun, we will now copy over some large files to the SSD. Now as you can see, there is no performance accreditation. And we're now going to safely unmount the SSD. Oh, that was a bit too early. Trying again. Yeah, all good. Okay, so we're now going to lock the screen. And now we're going to attach our Thunderbolt ATACO device from demo one. And next we're going to attempt to perform our DMA attack against the laptop. Now Windows has detected what it calls a drive for DMA violation. And so that means it caught us reading outside the memory range assigned by the IO memory. So kernel DMA protection is working as intended. Right, so UE5 support, what does it mean? Well, essentially it means sending a flag in Zmar table. And that's what we're doing with Thunder Spy 2. So we're all done. Right, so what's next for the future of Thunderbolt-based interconnects? Well, basically two issues remain unaddressed. So regarding Thunder Spy, there's Thunderbolt is 1, 2, 3. There is actually no means for the user to distinguish between forged and legitimate D-ROMs. So the files could be looking okay physically, but internally could still have been tampered with. And then there's kernel DMA protection, which Intel proposes as a replacement of security levels. Well, kernel DMA protection does protect against DMA attacks, but it does not protect against any other PCIe inherent attack factors, such as spoofing arbitrary PCIe IDs to target vulnerable device drivers, or spoof TOP source IDs to hijack transactions. And so both of these issues, they will most likely affect USB 4 and Thunderbolt 4. And actually for Thunderbolt 4, we know that Intel now requires vendors to implement kernel DMA protection as part of their vendor product certification scheme. So the good news is that if you buy a Thunderbolt 4 laptop, you will be guaranteed to have kernel DMA protection. But unfortunately, backwards compatibility likely means that both of the issues that we mentioned here still remain unaddressed. So potential avenues on mitigating these remaining issues, starting with the Thunder Spy vulnerabilities, essentially everything is in there in the firmware regarding the public key and assigned digest. So if Intel shares the digest scope, either the firmware or the device driver could verify the firmware authenticity. And there's kernel DMA protection. My proposal would be to allow all devices on boot for practical reasons, but at OS runtime initially disable all new DMA devices. So essentially no route them using the IO and unmute. And then require screen unlocking and explicit authorization from their user. And then finally only then assign an IO memory range. Now for kernel memory safety issues, one could use virtualization based security. And I think Microsoft is currently working on that with kernel data protection. And I could see the learners kernel doing the same soon. And finally, well, to prevent TLP source ID spoofing, one could implement the source ID verification similar to PCIe ACS. And finally, I don't know if anyone from Intel is watching, but if you are, please implement a UEFI toggle that controls PCIe signaling. And when you do so, please maintain the state in UEFI only. Right, so the takeaway that I would like to give you tonight is Thunder Spy is a new class of vulnerabilities really breaking Thunderbolt security. There is no fix from Intel. So, yeah, check if your system is funneled using either spy check or by verify manually. There's the full vulnerability report published on our website in case you're interested in more details. We've presented Thunder Spy 2, which really shows that kernel EMA protection can be patched onto previous systems that are technically capable but have not received any firmware updates. And well, finally, the future is PCI Express, whether we like it or not. That means, well, this would enable some very nice news cases. But on the other hand, there are also several issues that currently remain unaddressed. So when new hardware arrives with USB 4 and Thunderbolt 4, I hope the issues that we mentioned here will have been addressed. So that's it for today. If you have any questions, you can reach me on Twitter or just ask me here in the Q&A. Thank you very much for joining. Well, Björn, thank you for your very interesting talk on that. I had a quick look in the IOC in between and I saw that many took great interest into your talk. And your talk was quite comprehensive, so we only have got two questions left, actually. And the first one is, is it possible to manipulate the host controller firmware from the operating system or did you have to open it up and read flash directly? Yes, it is possible to manipulate the firmware from the host. This is actually what the Thunderbolt device and host controller vendors do when they update the controller firmware. There is a caveat. You cannot write to every offset in the firmware right from the host. So in particular, the security level configuration is not reachable from the host, but there is a backdoor via the TPS, the USB power delivery controller. So in theory, yes, this attack could be done from the host, but of course you would need to have root access or administrator share windows. So that's a different threat model than physical attacks, but yes, it is possible. Okay, thank you for that. Then we've got another question. Is the memory access completely unrestricted or only in certain regions regarding Thunderbolt One? Regarding Thunderbolt One, yes, completely unrestricted. At the time, kernel DMA protection didn't exist. This was only introduced with Thunderbolt, some Thunderbolt three systems starting from 2019. So not even all of them, but just a number. And all the systems before 2019 are guaranteed not to have kernel DMA protection. So that means that if you're either using Thunderbolt One or Thunderbolt two or three with security levels, you're vulnerable to Thunder Spy. Okay, thank you for taking the time and preparing this talk. Thank you for coming virtually over here. Also, lots of thanks from the IOC. I'm told the reaction is broadly positive. And I would like to wish you very much fun on the remaining RC three and hope to hear from you again. Your talk was great. Thank you. Thank you for joining me.