tl;dr: Xeno Kovah, Corey Kallenberg and I ported several previously disclosed vulnerabilities from Windows UEFI systems to Apple's EFI firmware. Using the 2014 Darth Venamis ("Dark Jedi") vulnerability we were able to unlock the motherboard boot flash, write our proof of concept to it, then scan the bus for PCIe Option ROMs and copy the worm to them as well. This allowed it to spread to other systems via shared Thunderbolt devices, possibly across air-gap security perimeters or via evil-maid attacks.

Like the original Thunderstrike vulnerability presented at CCC last year[0], firmware passwords and FileVault encryption don't prevent infection, reinstalling OSX won't remove it and it changes the RSA keys in the ROM so that Apple's firmware update routines can't remove it either. The only way to remove it is with a hardware in-system programming device connected to the SPI flash chip.

This is a transcript of our hour long presentation at DefCon 23 / Blackhat 2015 last week, which is why it is too long to read... Here is a shorter overview[1] and a demo video[2].

0: https://trmm.net/Thunderstrike_31c3

1: https://trmm.net/Thunderstrike_2

2: https://trmm.net/Thunderstrike2_demo

> then scan the bus for PCIe Option ROMs and copy the worm to them as well. This allowed it to spread to other systems via shared Thunderbolt devices

Is a thunderbolt display considered to be an "option ROM"? Meaning it would be possible to have a rogue monitor spreading a firmware infection?

The display itself isn't, but the existing Thunderbolt displays contain a PCIe network adapter that probably carries an option ROM.

Yep. It's got a chip covered by b57.c in it.

I see that the chip has a Write-Protect PIN on it. Could it be held (high or low) in order to prevent the attack from becoming persistent?

What about firmware updates? The usual way that Apple distributes Thunderbolt Display updates is using the OSX update mechanism. That has to be able to write to the firmware somehow.

Potentially, yes. However, if you want to have the ability to write firmware, etc, you're going to want some way of toggling that pin, leaving us right back where we started.

You connect that pin to a small switch in a not-so-easily-accessible place and tell the user to connect it whenever firmware updating is required. Something as simple as pushing a paperclip into a hole would be sufficient.

Firmware updates should not be "transparent", "seamless", "one click", or whatever other terms are used today to describe silent or little-noticed changes. They are modifying a very important part of the system, and the user has to be aware of that.

For better or worse, that's definitely not the "Apple Way".

Apple did do that before though: http://support.apple.com/kb/DL1283

Being in control of so much of your hardware of course some hardwired logic could be included e.g. in the keyboard matrix that would make some physical interaction necessary during firmware upgrades, but not require a hidden button.

Nevertheless, as long as such a button or switch is easily accessible, and not able to be covered by a seal, the system stays vulnerable to evil maids. And such a thing definitely wouldn't be the Apple Way™

So basically thunderbolt is a vulnerability in itself, only hampered by its own lack of market penetrating?

Ow.

No, the vulnerability is in the firmware doing nothing to ensure that the code it's executing is unmodified. This part of the attack isn't possible on systems that have UEFI Secure Boot enabled - once the option ROM is modified, the firmware will simply refuse to execute it.

Does Apple's firmware support Secure Boot? I've always heard of it in connection with Windows 8+. If they support it, is it enabled by default? If either answer is "no", it seems like the Option ROM vuln is pretty severe for Macs.

It's neither enabled, nor supported on Apple machines. Apple's not using UEFI, they're using their own fork of EFI 1.10

question for you - Secure Boot basically screws up the ability to boot Linux OSes. From this article, it seems Secure Boot is a good thing.

How do you see this working out in the longer term - is there a Secure Boot alternative that allows freedom to boot Linux, yet protects against vulnerabilities like these ?

SecureBoot implementations often let a user, via some means, add additional keys that they trust.

Any user can simply create their own key, sign their own firmware, linux, and what have you with it, and then boot away.

Unfortunately, Microsoft mandates secure boot but doesn't require the feature of adding keys to be present... so the reality is a bit more grim.

The reality is that most distros have managed to get a signing key from microsoft (and those that haven't, there's a grub shim signed by such a key) that is included by default in microsoft certified secureboots. This has been working, but is not as ideal.

> Secure Boot basically screws up the ability to boot Linux OSes

Not really. The barrier to obtaining a signed bootloader isn't that large, and if you're unwilling or unable to do that you can use http://mjg59.dreamwidth.org/20303.html and just oblige your users to jump through an additional (easily documented) hoop. We had legitimate concerns over the impact of Secure Boot on free operating systems, and for the most part we were able to reach some reasonable solutions.

does the shim solution not lead to this exact same security problem ?

No. How would it?

Linux distributions can and do support Secure Boot. I know Fedora, Ubuntu, and OpenSUSE do. FreeBSD is planning[1].

[1]: https://wiki.freebsd.org/SecureBoot

> Secure Boot basically screws up the ability to boot Linux OSes.

Funny. And here I thought I was secure booting Ubuntu already.

I think this issue was resolved 2 or 3 years ago.

Off topic, but highly recommended: Trammell Hudson's other projects[0]. The most famous of which is Magic Lantern, an alternative firmware for Canon DSLRs which makes them infinitely more useful for movie making (and a little more useful for stills); but other projects are also worth looking at.

[0] https://trmm.net/

For me, this the single most insightful / unsettling quote from the article:

  > Thunderstrike 2 doesn't make use of any new zero-day
  > vulnerabilities -- these are all older vulnerabilities
  > that had been previously disclosed and fixed on other
  > platforms.

The 'other platform' bit is a tad ambiguous, or simply overly generous, if you consider (U)EFI to be the platform.

It sounds like unsigned Option ROMs are an even bigger problem. If anything, UEFI provides an effective defense via Secure Boot. Sadly, Apple doesn't currently implement this feature -- at a minimum, they'd need to upgrade from EFI 1.10 to UEFI 2.3 to even be able to consider it.

Why do exploits tend to have such ridiculously good names recently?

Security researchers have learned that marketing works.

Heartbleed appears to have kicked off the "good marketing" of vulnerabilities that others alluded to. :-)

I think they go back further than that. There's some pretty popular ones here:

https://en.wikipedia.org/wiki/Timeline_of_computer_viruses_a...

For one thing, it helps when googling for more information.

The media loves good names so they can spread their fearmongering.

I wish more security vulnerabilities were fearmongered. Users caring about it and admins being bugged to fix it is a good thing.

Firmware worm? Can we call this "Wormware"?

I saw the name "FirmWorm" used for this vuln.

Apparently having a programmable operating system that allows reading/writing to RAM and system devices and that is rarely updated running under your own operating system allows easy exploitation, who would have guessed?

System integrators shouldn't be trusted to write software. If you've ever installed software from your various BIOS manufacturers you surely know that

Collectively the computer industry has become much stupider over the decades.

Back in the 1970s, when 9-track mag tape was popular, there was a saying: "no ring, no write". There was a physical plastic ring that needed to be inserted into the tape reel hub before the tape could be written to.

When 8" and 5" floppy disks were popular, you needed to place a physical piece of tape onto the side of the media, to cover a cutout. Without that, you couldn't write to the floppy.

Then 3.5" floppies became more popular and you had a mechanical tab you needed to move to enable/disable writing.

Same with early PCs. In order to update the BIOS you needed to physically move a jumper on a motherboard.

All the above was enforced by hardware. There was no magic SMM that could do whatever it wanted.

But all that was too expensive, or just not friendly enough for end users.

The bean counters and hipsters making the decisions nowadays have learned nothing from computer history. We've regressed.

Now get off my lawn. And be quiet, it's time for my nap.

> The bean counters and hipsters making the decisions nowadays have learned nothing from computer history.

As someone who's also used and remembered write-rings, etc., this is nonsense. The concern over threats back then was VASTLY lower than today, because the threat was in fact far lesser. Computers were vastly less interconnected and knowledge about exploit tactics was still nascent, and a fair bit harder to come by. Stuff was massively exploitable because in the "good 'ol days" there were a lot fewer computer literate people to think about things like "attack surface", and fewer still who had motive to use such knowledge maliciously. I knew grad students back in the 80's who had written their own illicit versions of "su" to make their lives easier. I.e. local privilege escalation tools. An undergrad banned (and transformed into an overnight pariah amongst his peers) for hacking CS dept servers. All kinds of devices hacked by the curious via some hardware port intended for maintenance or just left behind on the PCB. Those things happened, but the collective impact of much of that is less than one major exploit pattern today (Flash 0-day, legacy consumer routers, take your pick).

No, the root problem vs "yesterday" is just that our computers are cheaper and far more interconnected than ever before. Things like the option-ROM-as-vector being an economically practical technology. Our collective level of ability to ship secure systems is probably far better than it ever has been, but that's almost nothing in the face of an exponential explosion in the pervasiveness of computing. We still ship an incredible amount of insecure software and hardware systems, just because we make so damn much of it. Why design a complex fixed mechanism or circuit for something when you can solve the problem 1000x better with a CPU or DSP? That's great, but "oops, we forgot the security again." Or we didn't, but an exploit was still found and updating is otherwise infeasible.

It seems that ability to ship secure tech needs to be nearly pervasive, enough for a sort of technological herd-immunity (or herd-defense-in-depth), if you will. At this point, I suppose we're looking forward the day when all our little computers are muttering to themselves like trees in a forest chemically signaling about attacking pests.