Live data from Hacker News

When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

thunderspy.io

101–109 of 109 posts

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#101
post #10

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 c…

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.

Windows 10 also supports Kernel DMA protection by IOMMU. Win10 on Macbooks not work for it?

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#102
post #63

I wonder if that could be used by used sellers of MacBooks to get into the computers. 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.

Maybe it could be done by checkm8 exploit?

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#103
post #90

Earlier quoted context omitted.

Full disk encryption is still be broken, given a decade or 3. You might care about that risk or not, but the fact is still there. The point still is that if the attacker has unencumbered access to your device then indeed _further_ use of the device is unrecommended to say the least. It doesn't matter if you had or did not have full disk encryption. It does not matter if you had or did not have Thunderbolt. An extreme…

> Full disk encryption is still be broken, given a decade or 3. What? FDE is all symmetric crypto, long since 256-bit, and I think all AES. AES is extremely well understood, and the threat scenario for FDE is also purely cold attacks so even any side channels are irrelevant. I've never seen any feasible attack suggested even in principle, so I'm curious what you have in mind in 10-30 years. If you're thinking "quantu…

I still doubt about how TPM is durable against attackers.

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#104
post #97

Earlier quoted context omitted.

After the device is connected, use looks like a key consistency aware system like an ssh client. It is as you note very different in the first protocol run. To extract the device secret value, an attacker needs to connect the target device to an attacker device. As you note, the thunderbolt device leaks the secret value over the untrusted channel. Impersonation of that device after that moment is trivial as a result.…

> To extract the device secret value, an attacker needs to connect the target device to an attacker device. As you note, the thunderbolt device leaks the secret value over the untrusted channel. If victin device is connected to attacker host, then only responses to challenges are potentially leaked. That might allow active mitm, but not cloning the key. That's the whole reason TFA needed to go poking around in flash…

ssh uses asymmetric keys and the cache on the client has a three tuple (host,ip,public key) which allows a client to notice a difference in any of the three elements. By comparison, Thunderbolt leaks the entire secret as the first step and subsequent steps use derived values. ssh is secure if the key doesn't change and isn't compromised through other means. Thunderbolt is not secure and it fails under a passive surveillance adversary, it also fails for active adversaries.

I take your point that subsequent secret use in the n+1 protocol run isn't as bad as the very first run, and as you note, that probably doesn't matter in the face of an active attacker.

If Thunderbolt had used asymmetric cryptography, I would probably agree with you that the protocol has the same semantics as ssh. The reason that I disagree is that it appears to have the same semantics for the user interface but the underlying protocol differences are what make the protocol unsuitable for use. It's at least part of why Intel has now retired Security Levels and is leaning so strongly on kDMA. Security Levels as a protocol is simply not cryptographically secure for any meaningful definition of secure as the first step exposes the base secret value.

Note: the attack doesn't require the use of a flash clip, that's just a simple way to demonstrate device specific state extraction.

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#105

Earlier quoted context omitted.

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.

Windows 10 also supports Kernel DMA protection by IOMMU. Win10 on Macbooks not work for it?

No, Bootcamp enabled operating systems do not have the same protections as MacOS on the very same hardware. Apple says to use MacOS if you want (IOMMU+kDMA) security protections.

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#106
post #23

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 "vulner…

Have you documented or published any of your Thunderbolt reverse engineering efforts?

I'm not a hacker so my reverse engineering is about getting TB3 working on OSX instead of attacking it but it requires the same level of understanding. I have personally tested flashing modified ARC code on Alpine and Titan ridge and can confirm that it fails with an "authentication error" making the author's first claim demonstrably false. https://osy.gitbook.io/hac-mini-guide/details/thunderbolt-3-...

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#107
post #71

Earlier quoted context omitted.

Yes, buries the lede indeed. "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.

Dell XPS 15 can ship with Linux.

I should have figured the machines with a Linux option would be the higher end ones for developers, makes sense from a lot of perspectives. Just didn't really look.

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#108
post #23

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 "vulner…

> 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.

[1] https://github.com/BjornRuytenberg/tcfp [2] https://thunderspy.io/assets/reports/breaking-thunderbolt-se... [3] https://www.youtube.com/watch?v=7uvSZA1F9os

Re: When Lightning Strikes Thrice: Breaking Thunderbolt 3 Security

#109
post #44

Earlier quoted context omitted.

> they could remove my hard drive and insert it into an identical laptop Does that make having a layer of stickers on one's laptop also a layer of defense?

Stickers are an inconvenience, especially when applied over a screw hole required for disassembly or similar, but it's not exactly cryptographically secure. What stops the attacker from buying the same sticker as you, or taking a good picture of it before destroying it and printing a new one off?

I think you may have missed that my comment was primarilly a terrible pun.
Post reply on HN