Thunderstrike – Apple EFI firmware vulnerability | Hacker News Reader

Thunderstrike – Apple EFI firmware vulnerability

trmm.net

392 pointsofficialjunk68 comments

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:

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.

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.

Magic Lantern is beautiful.

[0] http://www.bhphotovideo.com/c/product/164271-REG/Canon_2477A...

Interestingly the developers of Magic Lantern have explicitly stated that they will never develop it for the pro 1D and C ranges of cameras.

Apparently this is a result of some informal or undisclosed agreement with Canon, as the pro cameras are where Canon's recurring revenue lies.

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.

+1 for using the term "weaponize".

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?

Described exploit requires a reboot, so it doesn't matter if the computer is locked or not.

The article claims he can trigger the reboot from the device, although that wasn't implemented in the proof of concept.

In-lining this exploit in a bit of cable would be fairly trivial. This is a nasty one.

Just note that the 2014 iMac Retina and Mac mini are (at least paritally) not longer vulnerable to this.

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.

Now I wonder if anyone has made a port-80 diagnostic card (dongle?) for Thunderbolt... http://en.wikipedia.org/wiki/POST_card

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.

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.

The W540 has Thunderbolt, but also miniDP. I guess that's OK. But seeing as how they try to ape Apple, who knows what the next gen will bring.

Ah, okay. I looked at a few models and only saw MiniDP, I guess some of them actually are Thunderbolt, Interesting.

I suppose it may depend on the model, but all the modern Thinkpads I've seen rolling around the office in the past year or so come with thunderbolt.

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

It's not so much about what you plug in but what others plug in that have temporary access to your machine.

Very nice read.

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.

I see, thanks for the explanation! As written in the other response, hopefully we'll see an EFI upgrade fixing it soon.

This attack "closes the door behind it" so that you can't use the same vector to undo it. Specifically it completely disables loading option ROMs.

I see, thanks for the explanation! Hopefully we'll see an EFI upgrade fixing it soon.

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.

I assume it was you that asked the question about Secure Boot at the end of this talk at 31C3?

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.

http://theinvisiblethings.blogspot.com/2011/09/anti-evil-mai...

Heh, but be careful of (intentional?) bugs. I have seen some versions of UEFI which do not measure option ROMs for example.

Look for changes to pcr-2 and pcr-3 when you plug or unplug cards with option ROMs:

  cat /sys/devices/* /* /pcrs

The 31c3 video for this exploit is here: http://media.ccc.de/browse/congress/2014/31c3_-_6128_-_en_-_...

Anyone noticed that the File Vault password also seems to leak? https://www.flickr.com/photos/osr/16139512701/lightbox

So basically a File Vault disk encryption is useless? Any clarification would be welcome :)

That has been known since 2012

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.

There is already a wireless USB.

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.

No need to issue commands, just provide an Option ROM over Wi-Fi like this attack. It's the same PCI protocol after all, just over Wi-Fi...

PCIe is a bus. It is the drivers that would choose to read and execute option ROM. It isn't part of the protocol actually.

If your peripheral device is compromised by a third party (say NSA) then it doesn't matter if it is over wireless or cable.

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.

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.

SPI flash has a write disable pin but that would also prevent Apple updates.

Could bodge in a physical switch for write protect.

Thanks! I'll email him and ask for details.

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.

This is one of the original purposes for the Trusted Platform Module which Apple has never used and no longer even includes in their hardware.

Indeed.

Great read to start 2015, it's been a while since I read something of that quality.

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'm reminded of a quote attributed to Benjamin Franklin:

    "Three can keep a secret, if two of them are dead."

Maybe our new world version is:

    "Your computer can keep your secrets as long as it's dead".

Or maybe better:

    "Computers will keep secret anything you don't share with them."

Someone needs to make a physical Thunderbolt port lock, like there are for Ethernet, USB, etc...

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.

</s>

Why Apple uses little-endian, while everything else uses big-endian, is another mystery.

The Apple-I and Apple-II family were 6502 based machines and the 6502 was little-endian, would be my guess. Any takers?

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

Intel x86 processors are little-endian.

http://en.wikipedia.org/wiki/Endianness#Endianness_and_hardw...

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

I wonder...how did the author gain such a wide variety of knowledge to figure this out.

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

Efi standard documents are available on the net.

Is every security bug now going to get a fancy name? We'll run out pretty fast.

Go read the article, then decide if you snark is appropriate and substantiated.

I did read the article and found it extremely interesting. My comment is not detracting of the work itself.

Same reason that hurricanes (and now powerful tornados) are named.

Naming something makes it more real as a thing and easy to speak about.

What I've experienced so far is that companies seem to care more if it gets press and a fancy name while every other CVE is ignored.

It's not a great trend but if that's what it takes to improve global security...

Reply on news.ycombinator.com