The Thunderclap vulnerabilities
It should come as no surprise that plugging untrusted devices into a computer system can lead to a wide variety of bad outcomes—though often enough it works just fine. We have reported on a number of these kinds of vulnerabilities (e.g. BadUSB in 2014) along the way. So it will not shock readers to find out that another vulnerability of this type has been discovered, though it may not sit well that, even after years of vulnerable plug-in buses, there are still no solid protections against these rogue devices. This most-recent entrant into this space targets the Thunderbolt interface; the vulnerabilities found have been dubbed "Thunderclap".
There are several different versions of Thunderbolt, either using Mini DisplayPort connectors (Thunderbolt 1 and 2) or USB Type-C (Thunderbolt 3). According to the long list of researchers behind Thunderclap, all of those are vulnerable to the problems they found. Beyond that, PCI Express (PCIe) peripherals are also able to exploit the Thunderclap vulnerabilities, though they are a bit less prone to hotplugging. Thunderclap is the subject of a paper [PDF] and web site. It is more than just a bunch of vulnerabilities, however, as there is a hardware and software research platform that they have developed and released. A high-level summary of the Thunderclap paper was posted to the Light Blue Touchpaper blog by Theo Markettos, one of the researchers, at the end of February.
At its core, Thunderclap exploits the ability of devices with direct memory access (DMA) capability to read system memory, including memory that is not at all related to the supposed function of the device. That memory could easily have sensitive information, such as encryption keys or login credentials, that the user probably does not realize they are exposing. In addition, because USB Type-C connectors are used for charging these days, it will be highly surprising that a "charger" may actually also be a Thunderbolt device—with all of the access that implies. Many users may not realize their "innocuous" charging port is really much more than that.
The primary hardware defense against rogue DMA devices is the I/O memory-management unit (IOMMU), but many operating systems do not even enable it. Windows, Linux, and FreeBSD do not enable the IOMMU for Thunderbolt, though Linux has added some support in 5.0. But even for macOS, which does enable the IOMMU, there are significant holes. The researchers created a fake Thunderbolt network card that had far more access than expected on the systems that they tested. Markettos described it this way (some of which found its way into last week's Security quotes of the week):
On MacOS and FreeBSD, our network card was able to start arbitrary programs as the system administrator, and on Linux it had access to sensitive kernel data structures. Additionally, on MacOS devices are not protected from one another, so a network card is allowed to read the display contents and keystrokes from a USB keyboard.
Worst of all, on Linux we could completely bypass the enabled IOMMU, simply by setting a few option fields in the messages that our malicious network card sent.
In theory, the IOMMU could provide the full protection needed, but the current implementations in today's operating systems are lacking:
Markettos likens the situation with the IOMMU to that of the system-call interface. The latter has undergone lots of testing and hardening over the years, but that process is just starting for the IOMMU:
Linux does have support for Thunderbolt 3 security levels (or access controls), though those are fairly coarse controls. The security levels affect whether certain types of devices can be used with the system, but do not restrict the access of authorized devices. There is a user-space daemon and a command-line program to work with the security levels, as well as GNOME integration. These security levels are also governed by the identification string provided by the device itself, so spoofing is certainly a possibility.
Protections against the Thunderclap vulnerabilities range from the drastic to more prosaic mechanisms:
You can also protect yourself by not leaving your computer unattended in public and not using public USB-C charging stations. Be wary of connecting an unknown device to the Thunderbolt port of your machine, even chargers and projectors that may seem harmless.
The advice about unattended computers is true for regular USB ports—and in general—as well. With each new hardware feature, it seems, the physical security of our computers and other devices becomes ever more important. In some sense, Thunderclap isn't really new, but is simply yet another reminder of the perils of hardware (in)security. While our software has its share of problems, of course, the hardware folks aren't making the security story any easier.
| Index entries for this article | |
|---|---|
| Kernel | Security/Vulnerabilities |
| Security | Hardware vulnerabilities |
Posted Mar 7, 2019 0:42 UTC (Thu)
by flussence (guest, #85566)
[Link] (19 responses)
It's pretty shameful that these exploits are happening over and over after the industry's had approximately two decades to learn the risks of giving DMA to external peripherals. The kernel even advertises Firewire debugging as a *feature*!
Posted Mar 7, 2019 2:15 UTC (Thu)
by arekkusu (guest, #54092)
[Link] (2 responses)
What constitute an external or internal interface might not be obvious for some attack. For example the SATA port on my ThinkPad UltraBay is quite accessible. Disabling FireWire and other unused port in the BIOS is something I've been doing for a long time.
But a USB Type-C connector is something everyone will be using. Considering Thunderbolt 3 will become USB4, it is a real concern. And just telling user to not plug in "untrusted device" is not good enough.
And my understanding is that this can not be fully fixed at the OS level:
"Kernel DMA Protection only protects against drive-by DMA attacks after the OS is loaded. It is the responsibility of the system firmware/BIOS to protect against attacks via the Thunderbolt™ 3 ports during boot."
Posted Mar 7, 2019 8:35 UTC (Thu)
by mangix (guest, #126006)
[Link] (1 responses)
Posted Mar 7, 2019 17:39 UTC (Thu)
by mebrown (subscriber, #7960)
[Link]
We don't get equivalent top speeds until USB4 is released.
Posted Mar 7, 2019 2:50 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (15 responses)
Posted Mar 7, 2019 13:58 UTC (Thu)
by robclark (subscriber, #74945)
[Link]
Posted Mar 7, 2019 20:49 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link] (12 responses)
Posted Mar 9, 2019 1:34 UTC (Sat)
by nix (subscriber, #2304)
[Link] (11 responses)
Posted Mar 11, 2019 0:17 UTC (Mon)
by mtaht (subscriber, #11087)
[Link]
Too bad I don't have a spare billion $ to get it past plausible promise.
Posted Mar 11, 2019 19:50 UTC (Mon)
by rweikusat2 (subscriber, #117920)
[Link] (9 responses)
Linux has a general purpose kernel memory allocator. This is a power-of-2-freelist allocator sitting atop the page allocator (more precisely it's implemented as set of object caches for objects whose sizes are powers-of-two). As detailed in the paper, the e1000 driver allocates skbs via kmalloc. This means its network buffers will usually occupy some part of a page. An access control mechanism with page granularity thus cannot prevent malicious devices from accessing the remaining part of the page. As that's just one of the pages currently allocated to one of the kmalloc caches, any other part of the kernel which uses kmalloc could end up using this "remaining part of the page".
The gist of this is that a (page-based) IOMMU can only prevent malicious devices from accessing data they're aren't supposed to access if the devices drivers used for such devices do their own memory management based getting complete pages from the page allocator.
Posted Mar 12, 2019 11:02 UTC (Tue)
by westeri (subscriber, #62678)
[Link] (8 responses)
https://lore.kernel.org/lkml/20190312060005.12189-1-baolu...
Posted Mar 12, 2019 14:25 UTC (Tue)
by rweikusat2 (subscriber, #117920)
[Link] (7 responses)
Posted Mar 12, 2019 16:16 UTC (Tue)
by westeri (subscriber, #62678)
[Link] (6 responses)
Posted Mar 12, 2019 19:48 UTC (Tue)
by rweikusat2 (subscriber, #117920)
[Link] (4 responses)
Assuming that memory protection/ accesss control with page granularity is available, DMA buffers used by untrusted devices (and this should really be all kinds of devices) must not share memory pages with code whose information said untrusted devices are not supposed to access if the access control is supposed to be used effectively. This means *if* such a facility is to be used in a sensible way, DMA buffer allocation must be per-device and separate from all other allocations, including other DMA buffer allocation.
There are obviously tradeoffs here as most real-world devices won't be untrusted but singling out a certain kind of devices and adding an additional DMA buffer allocation system working on top of the existing DMA buffer allocation systems is a technically seriously unpleasant workaround for a highly unlikely fringe case.
Posted Mar 12, 2019 21:01 UTC (Tue)
by westeri (subscriber, #62678)
[Link] (3 responses)
Posted Mar 12, 2019 21:50 UTC (Tue)
by rweikusat2 (subscriber, #117920)
[Link] (2 responses)
Yes. I thought I already wrote this ("this should really be all kinds of devices"): If this issue is supposed to be mitigated by the IOMMU, any driver which supports DMA would need to use its own DMA buffer backing pages cache. There's no need for individual buffers to span a complete page (or some number of complete pages) provided management information used by a driver isn't kept in the unused parts of some page a part of which is currently used as DMA buffer, at least not in a way where corruption could go unnoticed. Malicious device snooping on itself sounds pretty harmless to me ;-).
Assuming that fixing this is considered desirable (the underlying issue has existed forever --- there's no reason why hardware designed by an unknown entity ought to be trustworthy, especially not if this 'hardware' is in itself complicated enough to contain a general purpose CPU running some decidedly non-trivial software), this cries out for some sort of infrastructure support for DMA buffer allocation drivers could easily make use of.
NB: I understand the benefits of the existing approach. But that's still just life-patching of a more fundamentally deficient (in this respect) memory management model.
Posted Mar 13, 2019 15:21 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
The page cache would need to be separate for each *device*, not each driver. A device snooping on itself may be harmless, but the same is not necessarily true for snooping on other devices managed by the same driver. Besides the fact that one driver might manage multiple brands and models of devices, some more trustworthy than others, one can also envision e.g. a system with two identical NICs surreptitiously snooping on each other and transmitting internal network data over the external network.
Posted Mar 13, 2019 19:17 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link]
A driver capable of managing more than one device would obviously need one cache per currently managed device. Do you think somebody wouldn't immediately recognize this if such a driver was under discussion?
Posted Mar 19, 2019 13:31 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Mar 10, 2019 19:07 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
It's a brand new Remote Procedure Call technology; did you read the article? :-)
Remember: code is data and data is code https://lwn.net/Articles/778550/
Posted Mar 7, 2019 7:34 UTC (Thu)
by halla (subscriber, #14185)
[Link] (3 responses)
I think there's a 'not' missing between 'will' and 'be'. At least, I was not highly surprised.
Posted Mar 8, 2019 21:58 UTC (Fri)
by cpitrat (subscriber, #116459)
[Link]
Posted Mar 9, 2019 8:39 UTC (Sat)
by nivedita76 (subscriber, #121790)
[Link] (1 responses)
Posted Mar 16, 2019 1:51 UTC (Sat)
by Garak (guest, #99377)
[Link]
Posted Mar 7, 2019 10:35 UTC (Thu)
by Herve5 (subscriber, #115399)
[Link]
This may become an opportunity to prepare something for USB3/Thunderbolt?
H.
Posted Mar 7, 2019 15:29 UTC (Thu)
by dirkhh (subscriber, #50216)
[Link] (5 responses)
Obviously that would be equally useful when charging your USB-C phone.
Posted Mar 7, 2019 15:42 UTC (Thu)
by corbet (editor, #1)
[Link] (4 responses)
Posted Mar 7, 2019 15:52 UTC (Thu)
by dirkhh (subscriber, #50216)
[Link] (3 responses)
The problem with that is the USB A would limit you to something like 12.5W, right? And for a modern phone that's disappointing whereas for a MacBook Pro that isn't even enough to keep it from discharging while idle...
But yes, it sounds like we need a "USB C condom"...
Posted Mar 8, 2019 23:33 UTC (Fri)
by flussence (guest, #85566)
[Link] (2 responses)
USB-C power negotiation however… makes the Linux x86 early-boot code sound simple and reasonable in comparison. Cables have their own CPUs, voltages aren't fixed, the hardware has to be prepared to put up to 100 watts into a tiny, fully bidirectional connector (and it's already infamous for doing it in the wrong direction too often - your phone will probably make a futile attempt to charge your laptop at some point). The technology's a disaster at every level.
Posted Mar 10, 2019 17:35 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Posted Mar 12, 2019 17:18 UTC (Tue)
by k8to (guest, #15413)
[Link]
Which is probably what you were getting at.
Posted Mar 8, 2019 18:53 UTC (Fri)
by JFlorian (guest, #49650)
[Link]
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
Ref: https://docs.microsoft.com/en-us/windows/security/informa...
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
USB 3.2 2x2 superspeed - 20Gbps top speed
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
> The page cache would need to be separate for each *device*, not each driver.
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
Not for at least 5 years,-standard plug and play security convenience tradeoff thing
https://arstechnica.com/information-technology/2013/12/inside-the-nsas-leaked-catalog-of-surveillance-magic/
the NSA has built and deployed its own USB cables at target locations—complete with spy hardware and radio transceiver packed inside."
I also recall a few articles from those key early Snowden days where one of the oddly louder complaints from the government about Snowden's leak related to them having to replace a large number of cables.
The COTTONMOUTH series of implants are USB devices that provide a covert wireless bridge into a target network. They can be integrated into any USB plug, so check your mouse.
using hardware filters...
The Thunderclap vulnerabilities
I have a "USB condom" for USB A that, naturally, can be used with an A-to-C cable for charging (and I do just that). I haven't seen such a thing for native USB C yet.
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
Having that name actually gives me more interesting Google result - but from what I can see so far there have been quite a few requests similar to mine, but only USB-A versions appear to actually exist.
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities
https://plus.google.com/collection/0Vdov
moving to https://medium.com/@leung.benson
The Thunderclap vulnerabilities
The Thunderclap vulnerabilities