Apple EFI Firmware Security Vulnerabilities
1–10 of 52 posts
Re: Apple EFI Firmware Security Vulnerabilities
#2Wanted:
- "Tripwire" for firmware - host-based (not perfect) & bootable live cd/usb/image (still not perfect)... Perhaps some JTAG verifying device that could be hard-wired to all supported chips directly? (Very painful to setup, but potentially interesting.)
- Host-based peripheral firewall (not perfect, but more usable) - e.g.: selectively disable, ask user permission and/or limit rights to connecting devices from the various buses: USB, FW, PCI, SD card, SATA/SAS, BT, TB, SPI, FC, ... On OSX, it's doable considering VMware Fusion "patches" IOKit (check out IORegistryExplorer) selectively based on user preferences (whether to redirect a USB device to a guest or to the host).
Re: Apple EFI Firmware Security Vulnerabilities
#3Remember when BIOS flash ROMs were write-protected with a physical hardware switch/jumper? It was an extremely simple measure that basically made it impossible for the BIOS to be corrupted by software, malicious or otherwise.
It was certainly "inconvenient" to perform BIOS updates, but back in those days BIOS updates weren't all that common either. I don't think it should ever be "convenient" to do something like that with basic system firmware - by its very nature, it is supposed to be stable and rarely changed. Somehow this is making me terribly nostalgic... for the days when BIOSes seemed far less buggy and in need of constant change. Now, I hear stories of laptops with factory-installed crap that silently updates the BIOS in the background(!), bricking the machine when something else unfortunate happens coincidentally with it (e.g. hard reset.) I remember the ritual of "boot from a floppy to a plain DOS prompt, run the updater, and wait for a few tense seconds as it updated the BIOS".
The mention of "Thunderbolt Option ROM" makes it clear that Thunderbolt is basically an external version of PCI(e). In other words, even without being able to modify any firmware, plenty of other maliciousness is already possible - the same with any other device that has direct access to the system bus. In the same way that you probably wouldn't plug a random untrusted PCI(e) adapter into your system, you should exercise the same caution with Thunderbolt...
Re: Apple EFI Firmware Security Vulnerabilities
#4Remember when BIOS flash ROMs were write-protected with a physical hardware switch/jumper? It was an extremely simple measure that basically made it impossible for the BIOS to be corrupted by software, malicious or otherwise. It was certainly "inconvenient" to perform BIOS updates, but back in those days BIOS updates weren't all that common either. I don't think it should ever be "convenient" to do something like tha…
Macs used to require a physical step in addition to the software setup to modify the boot ROM. I think it was something along the lines of load firmware update which initiates a reboot, after reboot press and hold the power button until there was a loud beep from the computer, then the firmware update could proceed. Not convenient, but more secure.
Re: Apple EFI Firmware Security Vulnerabilities
#5Remember when BIOS flash ROMs were write-protected with a physical hardware switch/jumper? It was an extremely simple measure that basically made it impossible for the BIOS to be corrupted by software, malicious or otherwise. It was certainly "inconvenient" to perform BIOS updates, but back in those days BIOS updates weren't all that common either. I don't think it should ever be "convenient" to do something like tha…
Macs used to require a physical step in addition to the software setup to modify the boot ROM. I think it was something along the lines of load firmware update which initiates a reboot, after reboot press and hold the power button until there was a loud beep from the computer, then the firmware update could proceed. Not convenient, but more secure.
That's resetting the PRAM and was required on old macs for some of the fimrware changes to actually take place (since the firmware was cached).
Re: Apple EFI Firmware Security Vulnerabilities
#6Wanted: - "Tripwire" for firmware - host-based (not perfect) & bootable live cd/usb/image (still not perfect)... Perhaps some JTAG verifying device that could be hard-wired to all supported chips directly? (Very painful to setup, but potentially interesting.) - Host-based peripheral firewall (not perfect, but more usable) - e.g.: selectively disable, ask user permission and/or limit rights to connecting devices from…
In some cases, it's not possible to have a "Tripwire" equivalent for firmware. For example, Intel's Management Engine on modern chipsets runs code from a firmware region that's read-protected against access from user code.
Re: Apple EFI Firmware Security Vulnerabilities
#7Remember when BIOS flash ROMs were write-protected with a physical hardware switch/jumper? It was an extremely simple measure that basically made it impossible for the BIOS to be corrupted by software, malicious or otherwise. It was certainly "inconvenient" to perform BIOS updates, but back in those days BIOS updates weren't all that common either. I don't think it should ever be "convenient" to do something like tha…
> Remember when BIOS flash ROMs were write-protected with a physical hardware switch/jumper?
this is a physical access attack. when you have physical access, the game is up. (and your bios switch isn't any use).
i appreciate that inserting a thunderbolt device is easier than getting access to a switch, but it's not that much harder.
Re: Apple EFI Firmware Security Vulnerabilities
#8Wanted: - "Tripwire" for firmware - host-based (not perfect) & bootable live cd/usb/image (still not perfect)... Perhaps some JTAG verifying device that could be hard-wired to all supported chips directly? (Very painful to setup, but potentially interesting.) - Host-based peripheral firewall (not perfect, but more usable) - e.g.: selectively disable, ask user permission and/or limit rights to connecting devices from…
The second thing you mention already sort-of exists in the form of qubes os: https://qubes-os.org/
Re: Apple EFI Firmware Security Vulnerabilities
#9> the larger issue of Apple's EFI firmware security and secure booting with no trusted hardware is more difficult to fix.
IMO this shouldn't really be a problem. If the SPI payload disables writes before executing anything unsigned, then it's really quite hard to bypass.
Presumably the bug is a result of EFI capsule on disk support. The design is sh*t for exactly this reason.
The firmware could lock the flash, detect the capsule after initializing option ROMs, copy it to RAM, do a full reset, then find the capsule in RAM and verify a signature prior to re-locking the flash, though.
Re: Apple EFI Firmware Security Vulnerabilities
#10http://theinvisiblethings.blogspot.ca/2011/09/anti-evil-maid...
"Anti Evil Maid is an implementation of a TPM-based static trusted boot with a primary goal to prevent Evil Maid attacks.
The adjective trusted, in trusted boot, means that the goal of the mechanism is to somehow attest to a user that only desired (trusted) components have been loaded and executed during the system boot. It's a common mistake to confuse it with what is sometimes called secure boot, whose purpure is to prevent any unauthorized component from executing."