The Thunderclap vulnerabilities

By Jake Edge
March 6, 2019

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):

We found the attack surface available to a network card was much richer and more nuanced than was previously thought. By examining the memory it was given access to while sending and receiving packets, our device was able to read traffic from networks that it wasn't supposed to. This included VPN plaintext and traffic from Unix domain sockets that should never leave the machine.

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:

Existing strategies for using the IOMMU to protect against DMA attacks come with a high performance cost. This cost has led current operating systems to trade off security for performance gains - in some cases even disabling the IOMMU by default. Current operating systems also put sensitive data in the same regions of memory used for peripheral device communication, which facilitates attacks even when the IOMMU is enabled.

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:

More generally, since this is a new space of many vulnerabilities, rather than a specific example, we believe all operating systems are vulnerable to similar attacks, and that more substantial design changes will be needed to remedy these problems. We noticed similarities between the vulnerability surface available to malicious peripherals in the face of IOMMU protections and that of the kernel system call interface, long a source of operating system vulnerabilities. The kernel system call interface has been subjected to much scrutiny, security analysis, and code hardening over the years, which must now be applied to the interface between peripherals and 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:

More generally, however, we have discovered a larger vulnerability space that is not fully addressed by mitigations for specific attacks. The best way to fully protect yourself is to disable the Thunderbolt ports on your machine. However, the need to charge and connect legitimate peripheral devices makes doing so infeasible in general. PCs often allow disabling Thunderbolt in firmware (BIOS/UEFI) settings, while permitting power, video and USB. Externally, a USB hub/docking station without Thunderbolt support should suffice to prevent a USB-C port being switched into Thunderbolt mode.

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

to post comments

The Thunderclap vulnerabilities

Posted Mar 7, 2019 0:42 UTC (Thu) by flussence (guest, #85566) [Link] (19 responses)

Yet another Intel-designed thing full of holes? What a shocker.

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*!

The Thunderclap vulnerabilities

Posted Mar 7, 2019 2:15 UTC (Thu) by arekkusu (guest, #54092) [Link] (2 responses)

Nothing new with DMA being dangerous (and also useful of debugging). However we're in 2019 and I think providing unrestricted DMA to external device should not be acceptable.

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."
Ref: https://docs.microsoft.com/en-us/windows/security/informa...

The Thunderclap vulnerabilities

Posted Mar 7, 2019 8:35 UTC (Thu) by mangix (guest, #126006) [Link] (1 responses)

Actually there will be a USB 3.2 which brings the same speed as thunderbolt 3 but for USB (so no DMA).

The Thunderclap vulnerabilities

Posted Mar 7, 2019 17:39 UTC (Thu) by mebrown (subscriber, #7960) [Link]

Thunderbolt 3 - 40Gbps top speed
USB 3.2 2x2 superspeed - 20Gbps top speed

We don't get equivalent top speeds until USB4 is released.

The Thunderclap vulnerabilities

Posted Mar 7, 2019 2:50 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (15 responses)

How is it Intel's fault that Linux puts function pointers in the same page as network packets?

The Thunderclap vulnerabilities

Posted Mar 7, 2019 13:58 UTC (Thu) by robclark (subscriber, #74945) [Link]

Seems like we need the concept of a "less trusted" dma capable device that both sits behind iommu plus gets bounce buffer for things smaller than a page..

The Thunderclap vulnerabilities

Posted Mar 7, 2019 20:49 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (12 responses)

One could argue that Intel wrote the e1000 driver which uses kmalloc to allocate 2K areas which thereby enables the malicious device to access what's in the other 2K of the page the buffer resides in. Shockingly, other kernel code also uses kmalloc, hence, this can lead to a variety of interesting observations.

The Thunderclap vulnerabilities

Posted Mar 9, 2019 1:34 UTC (Sat) by nix (subscriber, #2304) [Link] (11 responses)

In Intel's defence, "I allocated 2K of memory rather than a full page" is not exactly an *obvious* equivalent to "now externally-connected peripherals can spy on kernel data structures". Developers do generally assume kernel memory is only readable by the kernel, and that the PCIe bus is trusted -- both of which are, it is true, questionable assumptions, but it's damn hard to write useful code at that level without making at least one of them. (And the e1000e driver is much older than Spectre and other similar families of oh-just-blow-away-access-protection attacks.)

The Thunderclap vulnerabilities

Posted Mar 11, 2019 0:17 UTC (Mon) by mtaht (guest, #11087) [Link]

Millcomputing's PLB is the only way out. ( http://millcomputing.com/wiki/Protection )

Too bad I don't have a spare billion $ to get it past plausible promise.

The Thunderclap vulnerabilities

Posted Mar 11, 2019 19:50 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link] (9 responses)

The point was supposed to be that "Linux" doesn't "put function pointers in the same page as network packets" in the way this statement suggests.

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.

The Thunderclap vulnerabilities

Posted Mar 12, 2019 11:02 UTC (Tue) by westeri (subscriber, #62678) [Link] (8 responses)

There is now a patch series from Lu Baolu aiming to fix the remaining issues here:

https://lore.kernel.org/lkml/20190312060005.12189-1-baolu...

The Thunderclap vulnerabilities

Posted Mar 12, 2019 14:25 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (7 responses)

"Copy the data into a dedicated page" is an ugly workaround for the issue.

The Thunderclap vulnerabilities

Posted Mar 12, 2019 16:16 UTC (Tue) by westeri (subscriber, #62678) [Link] (6 responses)

Feel free to propose a better one that does not involve fixing all the possible PCI drivers using DMA ;-)

The Thunderclap vulnerabilities

Posted Mar 12, 2019 19:48 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (4 responses)

"Don't buy devices from the people who wrote the paper"?

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.

The Thunderclap vulnerabilities

Posted Mar 12, 2019 21:01 UTC (Tue) by westeri (subscriber, #62678) [Link] (3 responses)

The problem here is that you can essentially plug in any PCIe device to a Thunderbolt enclosure (as they come with one or multiple PCIe slots). This means that you would need to fix each and every PCI driver to make sure they only do DMA to/from buffers that fill the whole page (the minimum IOMMU window size). Doing it in the IOMMU driver allows us to prevent the DMA attack now without need to modify all the PCI drivers. Since it only bounces buffers not filling the whole page so when a driver gets "fixed" it won't bounce anymore and eventually we can turn the bouncing off completely.

The Thunderclap vulnerabilities

Posted Mar 12, 2019 21:50 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

> The problem here is that you can essentially plug in any PCIe device to a Thunderbolt enclosure (as they come with one or multiple > PCIe slots). This means that you would need to fix each and every PCI driver

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.

The Thunderclap vulnerabilities

Posted Mar 13, 2019 15:21 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (1 responses)

> any driver which supports DMA would need to use its own DMA buffer backing pages cache

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.

The Thunderclap vulnerabilities

Posted Mar 13, 2019 19:17 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link]

>> any driver which supports DMA would need to use its own DMA buffer backing pages cache
> The page cache would need to be separate for each *device*, not each driver.

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?

The Thunderclap vulnerabilities

Posted Mar 19, 2019 13:31 UTC (Tue) by nix (subscriber, #2304) [Link]

It feels to me like a pooled allocator is what you want: each DMA-capable device gets a separate pool, and memory the allocator gives back to a given pool uses pages distinct from that used by all other pools; memory is zeroed before being placed in the pool. That way, a hostile device can only spy on memory it itself has populated (assuming that page-level protection still functions properly: so even this still needs a working IOMMU).

The Thunderclap vulnerabilities

Posted Mar 10, 2019 19:07 UTC (Sun) by marcH (subscriber, #57642) [Link]

> How is it Intel's fault that Linux puts function pointers in the same page as network packets?

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/

The Thunderclap vulnerabilities

Posted Mar 7, 2019 7:34 UTC (Thu) by halla (subscriber, #14185) [Link] (3 responses)

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

I think there's a 'not' missing between 'will' and 'be'. At least, I was not highly surprised.

The Thunderclap vulnerabilities

Posted Mar 8, 2019 21:58 UTC (Fri) by cpitrat (subscriber, #116459) [Link]

It will be highly surprising for the average user I guess.

The Thunderclap vulnerabilities

Posted Mar 9, 2019 8:39 UTC (Sat) by nivedita76 (subscriber, #121790) [Link] (1 responses)

Really? You wouldn’t find it highly surprising that what looks like a wall wart is reading out your laptop’s memory?

standard plug and play security convenience tradeoff thing

Posted Mar 16, 2019 1:51 UTC (Sat) by Garak (guest, #99377) [Link]

Not for at least 5 years,-

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

Posted Mar 7, 2019 10:35 UTC (Thu) by Herve5 (guest, #115399) [Link]

I for one have been happily using a couple of "USG" filters (https://github.com/robertfisk/USG), which work absolutely well for USB1; I see now the author builds USB2 filters (faster, but not fully open anymore apparently)

This may become an opportunity to prepare something for USB3/Thunderbolt?

The Thunderclap vulnerabilities

Posted Mar 7, 2019 15:29 UTC (Thu) by dirkhh (subscriber, #50216) [Link] (5 responses)

Ever since buying my first Mac with USB-C charging I wondered if there's a simple way to have a hardware dongle that allows JUST the charging, but none of the data access. I.e., male/female USB-C connector with enough electronics in between to enable charging, but nothing else.

Obviously that would be equally useful when charging your USB-C phone.

The Thunderclap vulnerabilities

Posted Mar 7, 2019 15:42 UTC (Thu) by corbet (editor, #1) [Link] (4 responses)

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

Posted Mar 7, 2019 15:52 UTC (Thu) by dirkhh (subscriber, #50216) [Link] (3 responses)

Hi Jon,

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

Posted Mar 8, 2019 23:33 UTC (Fri) by flussence (guest, #85566) [Link] (2 responses)

Basic USB2 is limited to 5V@500mA - 2.5W. There's fast charging “standards” that go up to 900mA or more and most of them use passive components to signal it.

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.

The Thunderclap vulnerabilities

Posted Mar 10, 2019 17:35 UTC (Sun) by marcH (subscriber, #57642) [Link]

Probably the best technical blog about Type-C
https://plus.google.com/collection/0Vdov
moving to https://medium.com/@leung.benson

The Thunderclap vulnerabilities

Posted Mar 12, 2019 17:18 UTC (Tue) by k8to (guest, #15413) [Link]

I think this complexity doesn't prevent categorically the idea of a device which tries to limit the interaction to charging. However, it does make it challenging, and fairly hard to imagine proving it safe.

Which is probably what you were getting at.

The Thunderclap vulnerabilities

Posted Mar 8, 2019 18:53 UTC (Fri) by JFlorian (guest, #49650) [Link]

Seems like a good time to mention usbguard [https://usbguard.github.io/]. Obviously this is only one attack surface but it helps.