Security researchers at the Network and Distributed Systems Security Symposium in San Diego are announcing the results of some fascinating research they’ve been working on. They “built a fake network card that is capable of interacting with the operating system in the same way as a real one” and discovered that
Such ports offer very privileged, low-level, direct memory access (DMA), which gives peripherals much more privilege than regular USB devices. If no defences are used on the host, an attacker has unrestricted memory access, and can completely take control of a target computer: they can steal passwords, banking logins, encryption keys, browser sessions and private files, and they can also inject malicious software that can run anywhere in the system.
Vendors have been gradually improving firmware and taking other steps to mitigate these vulnerabilities, but the same features that make Thunderbolt so useful also make them a much more serious attack vector than USB ever was. You may want to consider ways to disable your Thunderbolt drivers unless you can be sure that you can prevent physical access to your machine.
I’ve got a very strong sense of deja-vu here. These weaknesses with thunderbolt ports were well known in the past. Thunderbolt is essentially an external link to the system bus.
https://www.osnews.com/story/28172/thunderstrike-firmware-vulnerability-in-apples-efi/
The solution back at the time was to add access controls via IOMMU…big surprise , they got it wrong:
Thunderbolt’s lack of a separate DMA controller between the bus and peripherals helps reduce components, but allowing peripherals to initiate DMA transfers to RAM of their choosing was a recipe for disaster. With some work, IOMMU helps to tame it, but I’m quite astonished this design got the green light in the first place. Peripherals have no business being a bus master and poking into computer memory addresses. Think about how that’s supposed to work in the normal case for a second: a driver on the hosts allocates memory for a buffer and then passes this as a pointer to the peripheral. The peripheral, say a thunderbold drive, is then expected to read/write directly into host ram at the address it was told to use. Simple? Yes. Secure? Not at all, thunderbolt simply trusts that peripherals are using the addresses they were told to use.
An SATA drive, by contrast , doesn’t know about host memory. Rather it’s the SATA controller on the motherboard that performs the DMA such that all transfers are enforced by the operating system. Same for USB.While it’s possible for there to be other vulnerabilities in these subsystems, thunderbolt is notable because it is extremely vulnerable by design. Up until IOMMUs it’s security was based entirely on trust and based on the author’s findings it’s still remains vulnerable.
I’m not surprised, this is just Firewire all over again:
The same vendors were involved, the same kind of security model (full DMA access) is involved.
I’m surprised anyone thought this time would be different.
Yeah, instantly reminded me of Firewire …they should have known better with Thunderbolt.
You’re right. There really is no excuse for the new version of Thunderbolt to be such an easy attack vector since the same was true of the older versions, and everyone should have known this for years.
The thing is.; it’s impossible to defend against malicious thunderbolt devices.
IOMMU on its own can’t work because a malicious device can tamper with the code the OS uses to configure/enable the IOMMU before that code is executed. To guard against that, modern CPUs do provide (possibly several flavors of) encrypted RAM and this could be used to protect the code that configures/enables the IOMMU; but a malicious device can tamper with the code the OS uses to configure/enable encrypted RAM before that code is executed (and then tamper with the code that configures/enables the IOMMU).
“Hopefully in theory maybe” the OS sets all this up as soon as possible during boot (e.g. the first thing its boot loader tries to do), and if you’re lucky the boot loader is protected by SecureBoot so that…. This still doesn’t work. The malicious device can wait until after SecureBoot checks have passed and then tamper with the boot loader before it configures/enables encrypted RAM and/or IOMMU.
Of course all of this applies equally well to the firmware itself. E.g. the malicious device can “cut and paste” a perfectly acceptable UEFI driver (e.g. from a different manufacturer/vendor) into its ROM (including copying the driver’s perfectly acceptable digital signature); and then modify its own driver after it’s installed so that the “formerly perfectly acceptable” driver installs a rootkit in SMM (and so the computer is “root-kitted” before the firmware tries to boot the OS, despite TPM and SecureBoot).
There is only one possibility that can be guaranteed to be secure. It involves carving a piece of plastic the right shape and then super-gluing it into the thunderbolt. socket.
As has been pointed out, this can be easily defended against, the problem is that most consumer operating systems just don’t do so (macOS being the big exception), at least partially because Intel seems to consider an IOMMU to be a ‘premium’ component that people with low powered devices don’t care about.
ahferroin7,
That’s not what the article said though.
Locking down the IOMMU isn’t trivial because it needs a lot of help from the drivers. It’s not something you just turn on and it’s fixed. Some of these drivers are written by the manufacturers themselves, Those engineers may find their primary job function is to make the peripherals work. Penetration testing & OS security to mitigate hypothetical attacks by malicious 3rd party thunderbolt peripherals may not be something they are necessarily paid or qualified to do.
A fundamental problem with relying on the IOMMU to block malicious activity is that it only offers course grained protection. As the authors pointed out, linux allocates a whole bunch of buffers in it’s networking subsystem and uses DMA to transfer them directly to/from the network. Even when the IOMMU is enabled, DMA is still possible to other allocations in the network memory space that wasn’t intended to be accessed by the thunderbolt device. In theory a driver might update the IOMMU to limit the DMA range for every single packet, but performance would take a nosedive. In theory a driver might give the thunderbolt device access to it’s own memory space. But now the kernel has to constantly be copying data between the network subsystem and the separated thunderbolt NIC memory space prior to transmitting and after receiving packets. It defeats the zero-copy performance benefits of DMA and puts a greater load on the CPU.
DMA is great for performance because it enables hardware to read&write directly into their respective memory buffers without additional copies and it’s even possible for disks to read data and write it out to the network without the raw data ever having to go into the CPU. It’s usually secure from external hacks even without an IOMMU because sane hardware doesn’t expose DMA to the outside world. But thunderbolt’s design of having the DMA controller exist in the peripheral rather than in the computer implicitly means operating systems have to treat DMA itself as untrustworthy. And even with an IOMMU, there’s no easy fix, it requires re-engineering the kernel and loosing performance too. Personally I think the effort should be put elsewhere and the world should relegate thunderbolt to the legacy bin. It just sucks that it was designed this way to begin with.
Well, I think the main motivation for IOMMU is for hardware to be directly accessible to virtual environments by isolating it from the rest of the system. It just so happens that this can be used to keep thunderbolt peripherals out of host address space too.
Considering I dock my computer using a thunderbolt 3 dock…
Since my laptop never leaves my home, Thunderbolt is just awesome for me.