Hacker News new | past | comments | ask | show | jobs | submit login

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?


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: