[thudson]

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

[outworlder]

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

[mjg59]

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

[Sanddancer]

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

[25L6406]

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?

[outworlder]

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.

[Sanddancer]

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.

[userbinator]

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.

[spacehome]

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

[josteink]

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

Ow.

[mjg59]

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.

[scintill76]

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.

[Sanddancer]

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

[sandGorgon]

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 ?

[TheDong]

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.

[mjg59]

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

[abrowne]

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

[josteink]

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