I skimmed the paper and while the research looks solid, just in terms of the digging they did and the documentation they're providing, this website really buries its lede: if you've got a Macbook running macOS, the Macbook IOMMU breaks the DMA attack, which is the thing you're actually worried about here.
Additionally, regardless of the OS you run, Macbooks aren't affected by the Security Level/SPI flash hacks they came up with to disable Thunderbolt security.
This only holds for Macbooks running MacOS. It will not be protected by the IOMMU if the system uses Bootcamp with Windows or another operating system such as Linux.
* except on 90% of computers shipping with Thunderbolt.
Windows PC makers were much later to TB3 and even now only ship it on a small percentage of their computers. I'm not even sure there is a Linux out of the box system with TB3 support.
> there is no malicious piece of hardware that the attacker tricks you into using
> All the attacker needs is 5 minutes alone with the computer, a screwdriver, and some easily portable hardware.
Just started reading, but the comparison is already a little bizarre. It almost seems like the digital version of "This murderer is on the loose and you're in danger! He doesn't need to inject poison into your food. All he needs is just 5 minutes in front of you with a knife!"
What they're trying to get across is that this is not a Bad USB [0] attack, but an Evil Maid [1] attack. In either case, the attacker does not need to rush. To commit a Bad USB attack, the attacker deputizes you and uses your confusion [2] to get you to insert a dangerous peripheral device, on your own time. In an Evil Maid attack, the attacker patiently waits until you trust (read as: "are vulnerable to") their physical presence, and then inserts a dangerous peripheral device.
To use your analogy, in the former case, the murderer poisoned your food at the grocer's, and you unwittingly dose yourself when you make your meal. In the latter case, the murderer spends time getting to know you and letting you trust them, and then one day, when you go to the bathroom, they come in and shoot you like Vincent Vega.
As a general rule, anyone with physical access to your machine already owns it. Physical security matters, a lot.
That being said, malicious hardware is a problem. A hacked phone charging terminal at the airport could certainly be a serious problem if there are enough vulnerabilities in the USB stack.
This is the kind of garbage that the infosec community often memes about. A marketing website, a domain name, a cute logo for a vanity project masquerading as security research. Basically every one of the "seven" vulnerabilities boils down to "if someone can flash the SPI of the thunderbolt controller then xxx" but if they can flash the TB SPI, then they can also flash the BIOS SPI which has a lot of the same "vulnerabilities" but arguably is more impactful. The reason they only mentioned TB is because the BIOS stuff is well known and you can't put your name on it.
Let's break down each of the "vulnerability".
1. "However, we have found authenticity is not verified at boot time, upon connecting the device, or at any later point." This is actually false. Like, the author either didn't experiment properly or is lying/purposely misleading you. The firmware IS verified at boot for Alpine Ridge and Titan Ridge (Intel's TB3 controllers). They aren't for older controllers which does NOT support TB3. When verification fails, the controller falls back into a "safe mode" which does NOT run the firmware code for any of the ARC processors in the Ridge controller (there are a handful of processors where the firmware contains compressed code for). I'm willing to bet the author did not manage to reverse engineer the proprietary Huffman compression the firmware uses and therefore couldn't have loaded their own firmware. Because if they did, it wouldn't have worked. Now the RSA signature verification scheme they use to verify the firmware does suffer from some weaknesses but afaik doesn't lead to arbitrary code execution (on any of the Ridge ARC processors). I would love to be proven wrong here with real evidence though ;)
2. Basically the string identifiers inside the firmware isn't signed/verified. This has no security implications beyond you can spoof identifiers and make the string "pwned" appear in system details when you plug the device in and authenticate it. Basically if you've ever developed custom USB devices you can see how silly this is as a "vulnerability."
3. This is literally the same as #2.
4. Yes, TB2 is vulnerable to many DMA attacks as demonstrated in the past. Yes, TB3 has a TB2 compatibility mode. Yes, that means the same vulnerabilities exist in compatibility mode which is why you can disable it.
5. This one is technically true. If you open the case up, and flash the SPI chip containing the TB3 firmware, you can patch the security level set in BIOS and do stuff like re-enable TB2 if the user disabled it. But if I were the attacker, I would instead look at the SPI chip right next to it containing the UEFI firmware and NVRAM variables (most of which aren't signed/encryption in any modern PC).
6. SPI chips have interfaces for writing, erasing, and locking. If you have direct access to the chip you can abuse these pins to permanently brick the device. Here's another way: take your screwdriver and jam it into the computer.
7. Apple does not enable TB3 security features on Boot Camp. I guess this one is vaguely the only real "vulnerability" although it's well known and Apple doesn't care much about Windows security anyways (they don't enable Intel Boot Guard or BIOS Guard or TPM or any other Intel/Microsoft security feature).
Not that it matters but my personal experience with TB3 is that I've done significant reverse engineering of the Ridge controllers for the Hackintosh community.
Boot Guard makes that impractical in most cases. The point here is that on machines that don't implement kernel DMA protection, you're able to drop the Thunderbolt config to the lowest security level and then write-protect the Thunderbolt SPI so the system firmware can't re-enable it, making it easier to perform a DMA attack over Thunderbolt and sidestep the Boot Guard protections.
This isn't a world-ending vulnerability, but it's of interest to anyone who has physical attacks as part of their threat model.
> Now the RSA signature verification scheme they use to verify the firmware does suffer from some weaknesses but afaik doesn't lead to arbitrary code execution (on any of the Ridge ARC processors).
Hi, I'm the author of Thunderspy. I'll restrict myself to answering your first point.
There appears to be a misunderstanding. The first vulnerability we found is 'Inadequate firmware verification schemes'. We do not claim a general ability to run arbitrary code on the Thunderbolt controller. Rather, we found that the signature does not cover the data in the SPI flash essential for Thunderbolt security. We've released tools that allow you to modify the SPI flash contents without changing the parts of the firmware covered by the signature (see [1], exploitation scenario 3.2.1 in the report [2], and the PoC video [3] that matches the latter scenario). This is how it is possible to read and modify device strings, uuid, and secret values. The steps for doing specifically the latter are detailed in exploitation scenarios 3.1.1, 3.1.2 and 3.1.3. Please let me know where you got stuck.
> Basically every one of the "seven" vulnerabilities boils down to "if someone can flash the SPI of the thunderbolt controller then xxx" but if they can flash the TB SPI, then they can also flash the BIOS SPI which has a lot of the same "vulnerabilities" but arguably is more impactful.
The section "3.1.3 Cloning victim device including challenge-response keys (SL2)" does not require flashing the victim system, it only requires reading flash from victim device which seems lesser hurdle.
What would it take to have a Thunderbolt/USB C condom? You know, like those standard USB adapter that just drops the data leads on a usb charger to make attacks like this impossible. Maybe we would have to implement a hardware switch on the device itself?
I'm not going to feel safe charging with a public use charger until I find some way to insure only power and not data is making it to my device. Even POE feels like it's safer than modern peripheral standards right now.
(I admit this might not be perfectly linked to the article, it's just a need I've felt for a while but I can't seem to buy a solution for.)
USB power delivery does not use the data lines at all. It negotiates the permissible voltage and current using Vbus pin only. There's no reason why your USB data port needs to be enabled while charging. Just disable it. I actually have a charge-only thunderbolt cable in my desk ... it's incredibly irritating because the only way to tell the difference between it and a real thunderbolt cable is that it doesn't work.
I just bring my own brick for such circumstances. It takes no effort for me to evaluate the security, and it’s more flexible than counting on built in USB ports.
I guess MacBook resellers sometimes get computers where the password has been set and they can't get into the computers. I imagine they would be motivated to find anyway they can to unlock the computers.
There is a nice write-up about this on attackerkb. If you're not familiar with it it's a community to provide assessments of vulnerabilities and point out which are worth stopping everything to patch and which are mostly harmless.
It's currently in open beta.
Main site: https://attackerkb.com/
Thunderspy assessment: https://attackerkb.com/topics/mPaHZgsUvk/thunderspy
There were news sometime ago that Microsoft did not include thunderbolt in their surface 3 because it was insecure. I wonder if that's related to this and whether Microsoft knew about this for a while.
> Contrary to USB, Thunderbolt is a proprietary connectivity standard. Device vendors are required to apply for Intel’s Thunderbolt developer program, in order to obtain access to protocol specifications and the Thunderbolt hardware supply chain. In addition, devices are subject to certification procedures before being admitted to the Thunderbolt ecosystem.
> if an attacker has unencumbered access to one’s device, all security goes flying out the window
This is rapidly starting to become less true - full disk encryption is everywhere, backed by hardware TPMs; the Lockdown LSM prevents root from owing the boot chain; devices with soldered RAM are functionally immune to cold boot attacks.
There are still things an attacker can do - put a hardware keylogger on the keyboard wires, a skimmer on the fingerprint reader - but that requires future input from the victim. It is feasible today to defend against a physical attacker if you have the right hardware upfront and don't use it after the attack.
As another commenter pointed out, public charging or borrowed chargers are an issue. Think airport charging kiosks/counters. Maybe power over data connectors isn’t the best idea (I enjoy single cable docking, but an extra, magnetic power cable wasn’t that much more work).
tptacek|5 years ago
Additionally, regardless of the OS you run, Macbooks aren't affected by the Security Level/SPI flash hacks they came up with to disable Thunderbolt security.
AceJohnny2|5 years ago
[1] https://lwn.net/Articles/782381/
redactions|5 years ago
ogre_codes|5 years ago
"THUNDERBOLT IS HOPELESSLY INSECURE AND BROKEN!!"
blah
blah
blah
blah
* except on 90% of computers shipping with Thunderbolt.
Windows PC makers were much later to TB3 and even now only ship it on a small percentage of their computers. I'm not even sure there is a Linux out of the box system with TB3 support.
dataflow|5 years ago
> All the attacker needs is 5 minutes alone with the computer, a screwdriver, and some easily portable hardware.
Just started reading, but the comparison is already a little bizarre. It almost seems like the digital version of "This murderer is on the loose and you're in danger! He doesn't need to inject poison into your food. All he needs is just 5 minutes in front of you with a knife!"
lidHanteyk|5 years ago
To use your analogy, in the former case, the murderer poisoned your food at the grocer's, and you unwittingly dose yourself when you make your meal. In the latter case, the murderer spends time getting to know you and letting you trust them, and then one day, when you go to the bathroom, they come in and shoot you like Vincent Vega.
[0] https://en.wikipedia.org/wiki/USB_flash_drive#BadUSB
[1] https://en.wikipedia.org/wiki/Evil_maid_attack
[2] http://www.cap-lore.com/CapTheory/ConfusedDeputy.html
ashtonkem|5 years ago
That being said, malicious hardware is a problem. A hacked phone charging terminal at the airport could certainly be a serious problem if there are enough vulnerabilities in the USB stack.
kichik|5 years ago
DiabloD3|5 years ago
vvanders|5 years ago
osy|5 years ago
Let's break down each of the "vulnerability".
1. "However, we have found authenticity is not verified at boot time, upon connecting the device, or at any later point." This is actually false. Like, the author either didn't experiment properly or is lying/purposely misleading you. The firmware IS verified at boot for Alpine Ridge and Titan Ridge (Intel's TB3 controllers). They aren't for older controllers which does NOT support TB3. When verification fails, the controller falls back into a "safe mode" which does NOT run the firmware code for any of the ARC processors in the Ridge controller (there are a handful of processors where the firmware contains compressed code for). I'm willing to bet the author did not manage to reverse engineer the proprietary Huffman compression the firmware uses and therefore couldn't have loaded their own firmware. Because if they did, it wouldn't have worked. Now the RSA signature verification scheme they use to verify the firmware does suffer from some weaknesses but afaik doesn't lead to arbitrary code execution (on any of the Ridge ARC processors). I would love to be proven wrong here with real evidence though ;)
2. Basically the string identifiers inside the firmware isn't signed/verified. This has no security implications beyond you can spoof identifiers and make the string "pwned" appear in system details when you plug the device in and authenticate it. Basically if you've ever developed custom USB devices you can see how silly this is as a "vulnerability."
3. This is literally the same as #2.
4. Yes, TB2 is vulnerable to many DMA attacks as demonstrated in the past. Yes, TB3 has a TB2 compatibility mode. Yes, that means the same vulnerabilities exist in compatibility mode which is why you can disable it.
5. This one is technically true. If you open the case up, and flash the SPI chip containing the TB3 firmware, you can patch the security level set in BIOS and do stuff like re-enable TB2 if the user disabled it. But if I were the attacker, I would instead look at the SPI chip right next to it containing the UEFI firmware and NVRAM variables (most of which aren't signed/encryption in any modern PC).
6. SPI chips have interfaces for writing, erasing, and locking. If you have direct access to the chip you can abuse these pins to permanently brick the device. Here's another way: take your screwdriver and jam it into the computer.
7. Apple does not enable TB3 security features on Boot Camp. I guess this one is vaguely the only real "vulnerability" although it's well known and Apple doesn't care much about Windows security anyways (they don't enable Intel Boot Guard or BIOS Guard or TPM or any other Intel/Microsoft security feature).
Not that it matters but my personal experience with TB3 is that I've done significant reverse engineering of the Ridge controllers for the Hackintosh community.
mjg59|5 years ago
Boot Guard makes that impractical in most cases. The point here is that on machines that don't implement kernel DMA protection, you're able to drop the Thunderbolt config to the lowest security level and then write-protect the Thunderbolt SPI so the system firmware can't re-enable it, making it easier to perform a DMA attack over Thunderbolt and sidestep the Boot Guard protections.
This isn't a world-ending vulnerability, but it's of interest to anyone who has physical attacks as part of their threat model.
0xiphorus|5 years ago
Hi, I'm the author of Thunderspy. I'll restrict myself to answering your first point.
There appears to be a misunderstanding. The first vulnerability we found is 'Inadequate firmware verification schemes'. We do not claim a general ability to run arbitrary code on the Thunderbolt controller. Rather, we found that the signature does not cover the data in the SPI flash essential for Thunderbolt security. We've released tools that allow you to modify the SPI flash contents without changing the parts of the firmware covered by the signature (see [1], exploitation scenario 3.2.1 in the report [2], and the PoC video [3] that matches the latter scenario). This is how it is possible to read and modify device strings, uuid, and secret values. The steps for doing specifically the latter are detailed in exploitation scenarios 3.1.1, 3.1.2 and 3.1.3. Please let me know where you got stuck.
[1] https://github.com/BjornRuytenberg/tcfp [2] https://thunderspy.io/assets/reports/breaking-thunderbolt-se... [3] https://www.youtube.com/watch?v=7uvSZA1F9os
zokier|5 years ago
The section "3.1.3 Cloning victim device including challenge-response keys (SL2)" does not require flashing the victim system, it only requires reading flash from victim device which seems lesser hurdle.
redactions|5 years ago
unknown|5 years ago
[deleted]
justaguyonline|5 years ago
I'm not going to feel safe charging with a public use charger until I find some way to insure only power and not data is making it to my device. Even POE feels like it's safer than modern peripheral standards right now.
(I admit this might not be perfectly linked to the article, it's just a need I've felt for a while but I can't seem to buy a solution for.)
jeffbee|5 years ago
ashtonkem|5 years ago
dannyw|5 years ago
If you ever plug in a charging cable and get the prompt, you know something is wrong.
graton|5 years ago
https://www.vice.com/en_us/article/akw558/apples-t2-security...
I guess MacBook resellers sometimes get computers where the password has been set and they can't get into the computers. I imagine they would be motivated to find anyway they can to unlock the computers.
tptacek|5 years ago
fomine3|5 years ago
oicat|5 years ago
zerof1l|5 years ago
mschuster91|5 years ago
I thought that this had changed with USB-C?!
dafrankenstein2|5 years ago
unknown|5 years ago
[deleted]
dafrankenstein2|5 years ago
person_of_color|5 years ago
The website is highly self-promoting.
mappu|5 years ago
This is rapidly starting to become less true - full disk encryption is everywhere, backed by hardware TPMs; the Lockdown LSM prevents root from owing the boot chain; devices with soldered RAM are functionally immune to cold boot attacks.
There are still things an attacker can do - put a hardware keylogger on the keyboard wires, a skimmer on the fingerprint reader - but that requires future input from the victim. It is feasible today to defend against a physical attacker if you have the right hardware upfront and don't use it after the attack.
jonhohle|5 years ago
unknown|5 years ago
[deleted]