Live data from Hacker News

Thunderstrike – Apple EFI firmware vulnerability

trmm.net

11–20 of 72 posts

Re: Thunderstrike – Apple EFI firmware vulnerability

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

Re: Thunderstrike – Apple EFI firmware vulnerability

#12
post #9

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.

Re: Thunderstrike – Apple EFI firmware vulnerability

#15
post #2

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 in…

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

Re: Thunderstrike – Apple EFI firmware vulnerability

#16

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

Re: Thunderstrike – Apple EFI firmware vulnerability

#17
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."

Re: Thunderstrike – Apple EFI firmware vulnerability

#19
post #9

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

Re: Thunderstrike – Apple EFI firmware vulnerability

#20
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?
Post reply on HN