Extremely impressive this, the tenacity of the author is incredible.
Basically the upshot of this article is (for me) that if you own some piece of hardware you can only really trust it if it has never been out of your sight after you bought it (and hopefully it wasn't compromised before you bought it).
Shipping your laptop as checked in luggage, leave it on your desk overnight or go to lunch and when you see it the next time around it might not be your computer any longer.
Another very impressive bit to me was the fact that a financial institution took its security serious enough that they commissioned this work.
The whole thing is reminiscent of the inception hack:
You'd probably be interested in Trammell's other projects (trmm.net has a list), including Magic Lantern, which arguably makes Canon cameras significantly more useful, and his older UAV work.
Definitely more than 'arguably' more useful. The intervalometer alone fills in for a $129 piece of hardware [0] and the HDR recording, although far from the standard of a Blackmagic camera, allows a $500 consumer SLR to produce HDR video where a $2000 camera would normally be required.
And those are just the features I could easily equate to money. There's also the zebra striping and so many other features I can't think of right now.
It's probably a threat. Enable ML for the pro series cameras, and we encrypt boot loaders etc. Or even sue. But don't touch them and we'll have a gentlemen's agreement.
I often come to the comment section looking for a summary of a dense article like this. Didn't find it, so here is my best shot at one:
Through the thunderbolt port, an attacker can put code that controls the firmware updates onto a mac. This cannot be removed by software, and could do all sorts of nasty stuff.
Anyone with physical access to the computer and a weaponized version of this exploit could do this. This includes intercepting hardware en-route to its recipients, spending a few minutes with a laptop while its owners are away, or while crossing international borders.
According to the author, this exploit works with every Mac with a thunderbolt port that they tested. Apple has a partial fix coming as a firmware update soon, but the author expresses concern that the proposed fix could still be bypassed.
I seem to recall that FireWire ports were disabled in some way when the system was locked (tip: show Keychain Access icon in menubar to have a manual lock at a click's distance) and that such attacks therefore required the computer to be unlocked.
Did I dream about that feature, and is that applicable to Thunderbolt?
As I mentioned in a previous discussion here (https://news.ycombinator.com/item?id=8779696 ), Thunderbolt is basically "external PCIe" so you wouldn't want to plug in anything that you wouldn't plug into a PCIe slot on the motherboard of a desktop... it's not like USB where communication has to go through a special controller that requires drivers, this is the raw system bus itself.
Note that what Apple refers to as the SMC (it's usually known as the EC/embedded controller/keyboard controller in other laptops) is another programmable controller, one that runs as long as the system has power - even from the battery - and is responsible for actually powering up the main CPU, so an exploit could hide itself there too and be even more difficult to detect. The main difference is the SMC/EC has much less memory so what can be hidden there is relatively limited.
Thunderbolt is basically "external PCIe" so you wouldn't want to plug in anything that you wouldn't plug into a PCIe slot on the motherboard of a desktop... it's not like USB where communication has to go through a special controller that requires drivers, this is the raw system bus itself.
As cool as the raw power you get from Thunderbolt is, I wonder if externalizing an internal bus was a fundamental design flaw. PCIe descends from PCI, which descends from ISA, bringing along all sorts of backward compatible cruft, including the Option ROM support used by this exploit.
Option ROMs are certainly useful - for example, every GPU has one to initialise it, and it's how devices like RAID controllers can be used for booting or network cards adding PXE support. Things like putting a standard GPU over Thunderbolt would've been very difficult to do otherwise.
However, you're right that the security characteristics of an external bus are quite different from an internal one. I haven't looked in detail at the specs but I've worked with PCI/PCIe and it should certainly be possible to distinguish between a device plugged into the external port (it likely appears as a separate bus with a PCI-PCI bridge) and an internal one, allowing a BIOS (EFI, whatever it's called these days) option to control it. Something like "Execute Thunderbolt Option ROM [Yes/No/Prompt]"? But then, knowing Apple, they'd be more inclined to want everything to "just work" and default it to Yes without allowing the user to change it...
That's not surprising since Intel's whole business is built on backwards compatibility. And the benefits are pretty clear: Thunderbolt devices can use existing PCIe chips and drivers. If it was an incompatible protocol then it would require new TB-to-X chips for all X, and since the Thunderbolt market probably isn't large enough to support those chips then it would just fail.
It's s huge problem, and another curse Apple has gotten the rest of the laptop industry to adopt. Newer ThinkPads ship with Thunderbolt instead of DisplayPort. So if I want external monitors, I'm screwed. I can't just epoxy the port, like I did with FireWire.
AFAIK, it's not Thunderbolt on Lenovos, just Mini DisplayPort+Audio, which has similar connectors and cables but excludes the PCI-alike interface for high-speed general purpose IO which this exploits.
Basically, when a MacBook is booted it allows random code to be executed from an attached Thunderbolt device (in a form of a legacy mechanism of Option ROM). The Option ROM is loaded unconditionally, including the case when the host system is rebooted to update its firmware. During such upgrade its primary on-board ROM is writable, so the exploit can write itself in it, replace RSA key used to verify firmware upgrades and thus prevent re-flashing the host with any official updates. Additionally, all this is possible because ROM includes only rudimentary self-integrity checks (in a form of CRC32) and proper crypto-signature checks are only applied during the update and not on every boot.
This particular exploit is pluggable by making firmware not use Option ROM during upgrades, which is a fix being deployed by Apple. Meanwhile you may want to superglue your TB port.
Maybe I'm missing something, but if an attacker can update the firmware without Apple's RSA key, then Apple (or you self) should be able to flash it in the same way the attacker did (even though the official update procedure is blocked) and "fix it", or?
The attacker can essentially "seal" the firmware in by writing a modified BIOS that either skips executing option ROMs, or write-protects the flash before executing them (as Apple's firmware should've originally done); then you'd need to use hardware to reflash.
The attack as described is plausible on non-Apple hardware, provided that the system doesn't have UEFI Secure Boot enabled. If it does then you'd need a separate attack to circumvent the requirement for signed drivers.
Also worth mentioning that this isn't specific to Thunderbolt - Expresscard also breaks out PCIe to an externally-accessible port.
Yeah - after the previous day's discussion on how pretty much every existing Secure Boot implementation was vulnerable to kernel-level attack, it was nice to hear about something that was fully prevented by Secure Boot.
An amazing write-up. Although I am using my EE training a lot more at work these days, and I've designed my fair share of MCU (and USB, FPGA, analog...) projects I've never found the time to dip into learning even a fraction of the detail presented here on low-level modern x86 architecture.
For me, reading this really hammers home just how feasible evil maid type attacks really are (considering attacks aimed at defeating Eg. Full disk encryption). But at the same time, if I am still typing the passphrase for my encrypted disks at each boot, simply filming me use my laptop would seem easier... So using that logic, I have been working on passwordless unlock before fiddling with the very tedious task of maintaining a SecureBoot Linux installation.
Can anyone say how strong the x86/TPM-equipped machines out there are against malicious firmware updates, assuming one has their BIOS admin password set?
> Can anyone say how strong the x86/TPM-equipped machines out there are against malicious firmware updates, assuming one has their BIOS admin password set?
A machine with VT-d (IOMMU), TPM and TXT is needed.
From the FAQ:
Can it actually decrypt FileVault? Thunderstrike can not directly decrypt FileVault keys, but it does record the password the user types in to decrypt an encrypted boot volume and could use other data exfiltration techniques to send the key to the attacker's system.
I can't wait for the same demo next year, but wireless. I wish I were joking:
The WiGig Bus Extension (WBE), which can enable a wireless
version of the PCI Express (PCIe) slots used to connect
everything from video cards to hard drives. WBE is now a
published specification available to members of the
consortium.
WiGig Bus Extension (WBE) aka PCIe over Wi-Fi, coming to a laptop near you.
WBE would essentially replace the cable. It is invisible to upper stacks. There is encryption/scrambling. I'm sure there are vectors for snooping attacks but I don't see viable "imitation" attacks where you could issue commands on behalf of the other device.
There is an interesting opportunity here for a Thunderbolt "condom". You would permanently attach it to your Mac's TB port -- and plug everything through that. It would block Snare attacks by detecting/preventing PCIe reads in a certain address range.
During boot time, it would read your BootROM and compare it against a known good and visually let you know if your ROM is compromised or not.
It is my understanding that verifying the BootROM is not possible once infected with sufficiently malicious code. I talked with Trammell about this briefly and my takeaway was that once you have code on the BootROM, you can control how code is read from the BootROM, making it possible to present the appearance of a non-compromised ROM image.
To the best of my knowledge, the only solution is something sitting on top of the BootROM chip, monitoring for writes. It may also be possible to alter the write-protect/write-enable pin (forget which it has) on the ROM to prevent all writes.
However, I can't see how that would be possible. While it is possible for the BootROM to block reads to ROM once it is done executing or not execute external Optional ROMs but both of those would be detectable by the external accessory.
It is not possible for the ROM however to return a different set of data than what is in the ROM.
The only thing I can think of is if the PCIe bridge had aperture/remapping registers and it would alter those to point to RAM instead of ROM and copy a "good" ROM into that range but that would be detectable by writing to the address over PCIe and seeing if the region is writable.
I'll have to find the data sheet, but it should be very possible to pull a pin high or low to disable writing to the chip itself. I doubt they do any checks for being able to write to the chip in software, that would just wear out the flash unnecessarily.
Excellent article. I haven't watched the presentation yet, but I believe only the article is enough.
Also I liked it was somewhat step-by-step without jumping too far and losing the reader. This must be related to his class experience and is really awesome to broaden the access.
I would like to see way more of this kind of presentation/article had this step-by-step guiding through the discovery process.
Well done! That makes me wish to return to the field after some time _sleeping_.
I did not realize that macs did not include a TPM... So there can be no equivalent to bitlocker for them. This seems like a big competitive disadvantage for them.
I suppose you could make a dongle with a tpm for macs.. Perhaps there would be a market for it.
For the low, low price of $2000 you can buy one of my new, patent-pending Thunderbolt TPM dongles. Simply plug it in, reboot your machine, and you're protected from future EFI firmware changes! One use and you're protected, so pass it on to family and friends!
Includes other Thunderstrike implementations and official Apple updates.
This is not about the endianness of the processor, but about the endianness of the RSA signatures placed in the file - which is a programming decision, not an architecture/hardware one.
Apple machines are little-endian, as are any other IA32e machines. The rest of the common 'full' architectures (ARM, MIPS, Power, SPARC, ...) are bi-endian, that is they can switch endianness on demand via a register.
People have finally realized Little Endian is the only true endianness ;).
More likely a holdover from the power architecture days. I highly doubt a single bit made it from the 6502 days to the power pc days but I would not be at all surprised if some bits made it from the power days to the present.
I think the author is talking about something else (or is confused), the Motorola 68K processors were big-endian and the PowerPC had a big-endian mode (which was used by both PowerMacs and other POWER architecture systems).
The key to that in a way is embedded in the article. He doesn't give up, just keeps plugging away at it. That most likely goes for other things he does as well, including learning.
If you want to understand anything at all you'll end up branching out into tons of other fields besides the one you started out in. Want to understand something about biology? Off you go to Chemistry, Physics and even Math...
Basically the upshot of this article is (for me) that if you own some piece of hardware you can only really trust it if it has never been out of your sight after you bought it (and hopefully it wasn't compromised before you bought it).
Shipping your laptop as checked in luggage, leave it on your desk overnight or go to lunch and when you see it the next time around it might not be your computer any longer.
Another very impressive bit to me was the fact that a financial institution took its security serious enough that they commissioned this work.
The whole thing is reminiscent of the inception hack:
http://www.breaknenter.org/projects/inception/
I'm imagining this guy working for the Apple center on Wall Street or near it plugging a little dongle into every macbook before it gets sold.