Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thunderstrike – Apple EFI firmware vulnerability

trmm.net

Post reply on HN
Print view View original

21–30 of 72 posts

Re: Thunderstrike – Apple EFI firmware vulnerability

#21

Post by userbinator »

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

Re: Thunderstrike – Apple EFI firmware vulnerability

#22

Post by userbinator »

ripa wrote: post #20
eps wrote: post #8

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…

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.

Re: Thunderstrike – Apple EFI firmware vulnerability

#23

Post by helper »

ripa wrote: post #20
eps wrote: post #8

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…

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?

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.

Re: Thunderstrike – Apple EFI firmware vulnerability

#25

Post by ripa »

helper wrote: post #23
ripa wrote: post #20

Earlier quoted context omitted.

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?

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.

Re: Thunderstrike – Apple EFI firmware vulnerability

#26

Post by ripa »

userbinator wrote: post #22
ripa wrote: post #20

Earlier quoted context omitted.

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.

Re: Thunderstrike – Apple EFI firmware vulnerability

#27

Post by twoodfin »

userbinator wrote: post #21

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…

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.

Re: Thunderstrike – Apple EFI firmware vulnerability

#28

Post by jacquesm »

userbinator wrote: post #21

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…

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

Re: Thunderstrike – Apple EFI firmware vulnerability

#29

Post by fungos »

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

Re: Thunderstrike – Apple EFI firmware vulnerability

#30

Post by beagle3 »

jacquesm wrote: post #11

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…

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.
Post reply on HN