Apple EFI Firmware Security Vulnerabilities(trmm.net)
trmm.net
Apple EFI Firmware Security Vulnerabilities
https://trmm.net/EFI
12 comments
I'm not sure if the jumpers were meant as a malware protection.
[...] make it impossible for the BIOS to be corrupted
by software, malicious or otherwise
Jumper JP4 controls the protection scheme that
prevents accidental damage to or rewriting of the data
stored in Flash memory.[1]
That is an interesting example of a hybrid protection scheme - you get to choose between "software decides", "always protected", and "always unprotected". Given that the jumper is located right next to the flash, I'm inclined to believe this is a true hardware protection; likely the middle pin is connected to the write-enable of the flash, the left pin is connected to a GPIO so the software can control it, and the right pin is connected to a constant voltage to disable any writing via hardware. The open position leaves the pin free to allow writes.
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).
PowerPC Macs (in the 2000s, before the switch to Intel) did indeed require a manual step to update Boot ROM/firmware - a different mechanism than resetting the PRAM. You'd run the installer, then either shut down or reboot the Mac. As it booted, you'd either hold down the power button or the interrupt button (depending on the model) to initiate the update.
No, resetting PRAM is triggered by holding down command-option-P-R. This was a special step that was required specifically for firmware updates.
This reminds me of the hardware switch in the original Chromebook, the cr-48, which requires you to flip a switch underneath a piece of tape before you can install an alternative operating system.
https://www.chromium.org/chromium-os/developer-information-f...
https://www.chromium.org/chromium-os/developer-information-f...
Actually, Chromebooks should be the most secure laptop platform nowadays, since every Chromebook has signed binaries and to enter in developer mode, you need some kind of switch so you can overwrite your bootloader.
Of course, this is assuming Chromebooks' bootloader doesn't have any secured problems.
Of course, this is assuming Chromebooks' bootloader doesn't have any secured problems.
Assuming that the signing key hasn't been compromised and added to an attacker's collection of keys, which is something certain three letter agencies have a habit of doing.
> 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.
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.
NO!
Summarizing as “when you have physical access, the game is up” is the same as saying that employees who pick up abandoned USB thumbdrives on parking lots and plug them into work computers are guilty.
Plugging things in are what Thunderbolt/USB ports are FOR. This is how you transmit data and how you extend the computer with new peripherals. It may be impossible to prevent a Thunderbolt or USB peripheral from bricking the computer, but that doing so can end up giving control of it to a third party is an unacceptable security failure, is not the user's fault, and needs to be fixed.
A physical hardware switch located inside the box would be quite appropriate. Everyone knows that you don't need to open the computer to read from an external drive.
Summarizing as “when you have physical access, the game is up” is the same as saying that employees who pick up abandoned USB thumbdrives on parking lots and plug them into work computers are guilty.
Plugging things in are what Thunderbolt/USB ports are FOR. This is how you transmit data and how you extend the computer with new peripherals. It may be impossible to prevent a Thunderbolt or USB peripheral from bricking the computer, but that doing so can end up giving control of it to a third party is an unacceptable security failure, is not the user's fault, and needs to be fixed.
A physical hardware switch located inside the box would be quite appropriate. Everyone knows that you don't need to open the computer to read from an external drive.
> is the same as saying that employees who pick up abandoned USB thumbdrives on parking lots and plug them into work computers are guilty
oh my science they most certainly are.
> Plugging things in are what Thunderbolt/USB ports are FOR
yes, but the moment you insert them into a machine they are assumed to be trusted. (this is my opinion, it could be incorrect)
oh my science they most certainly are.
> Plugging things in are what Thunderbolt/USB ports are FOR
yes, but the moment you insert them into a machine they are assumed to be trusted. (this is my opinion, it could be incorrect)
> the same as saying employees who pick up abandoned USB thumbdrives on parking lots and plug them into work computers are guilty
This has been true for as long as USB has existed. The broader version -- "don't attach untrusted hardware" -- has been true for as long as there have been computers.
There is a reason secure installations do not allow employees to bring in arbitrary electronics.
This has been true for as long as USB has existed. The broader version -- "don't attach untrusted hardware" -- has been true for as long as there have been computers.
There is a reason secure installations do not allow employees to bring in arbitrary electronics.
>Remember when BIOS flash ROMs were write-protected with a physical hardware switch/jumper?
Remember how that was only for a short 1-2 years as a knee jerk reaction to CIH virus?
Older PCs had bios in EPROM (UV window on the chip) instead of EEPROM. That was the only physical protection. Later Intel introduced firmware hub (FWH) with software protection against flashing (you had to unlock certain memory region/io access), then we got SPI flash chips with some copy protection (again software controlled).
Jumper was a short lived, useless (after the fact) feature that died because nobody needed/wanted/asked for it.
Remember how that was only for a short 1-2 years as a knee jerk reaction to CIH virus?
Older PCs had bios in EPROM (UV window on the chip) instead of EEPROM. That was the only physical protection. Later Intel introduced firmware hub (FWH) with software protection against flashing (you had to unlock certain memory region/io access), then we got SPI flash chips with some copy protection (again software controlled).
Jumper was a short lived, useless (after the fact) feature that died because nobody needed/wanted/asked for it.
Out of curiosity: Can anyone point me where to find how a recent x86-cpu actually boots? Where's the code that gets executed in the first few CPU cycles?
The bulk of the firmware, that's clear, nowadays will be fetched from a serially connected flash, which this initial code will copy to the (then initialized) DRAM, also probably in several stages. But where do the first few instructions hide? Mask-rom in the CPU, or the chipset?
I know how initial bootup works on my day-job-default-CPU (a m68k/coldfire that basically just starts executing from a parallel connected flash), on a few ARMs and some PPC, but I have no idea about a "typical" intel core/i5..7/... CPU.
The bulk of the firmware, that's clear, nowadays will be fetched from a serially connected flash, which this initial code will copy to the (then initialized) DRAM, also probably in several stages. But where do the first few instructions hide? Mask-rom in the CPU, or the chipset?
I know how initial bootup works on my day-job-default-CPU (a m68k/coldfire that basically just starts executing from a parallel connected flash), on a few ARMs and some PPC, but I have no idea about a "typical" intel core/i5..7/... CPU.
The first "code" would probably be microcode in the CPU itself, but if you mean x86 instructions, recent CPUs boot in the same way as the orginal 8086: the first instruction after a reset is fetched from FFFF:FFF0, or 16 bytes less than the end of memory, in realmode. The BIOS ROM is mapped into this area.
There are some good articles here:
https://sites.google.com/site/pinczakko/
There are some good articles here:
https://sites.google.com/site/pinczakko/
> the first instruction after a reset is fetched from FFFF:FFF0
I trust you that this logically will certainly be true, but: what memory will that access to ffff:fff0 be mapped to if the "bios" in my PC is stored in a SPI flash that certainly can't be connected directly to anything resembling a "address/data-bus" in a modern PC...
I trust you that this logically will certainly be true, but: what memory will that access to ffff:fff0 be mapped to if the "bios" in my PC is stored in a SPI flash that certainly can't be connected directly to anything resembling a "address/data-bus" in a modern PC...
There is circuitry that translates the requests from the CPU into read commands to the serial flash. Depending on the system, this can be in the LPC-connected SuperIO, the southbridge, or on laptops more likely part of the EC (embedded controller) which is also connected via LPC. This is also why executing from the BIOS is slow - SPI flash bandwidth is in the dozens of MB/s range, and if it's going over LPC the max bandwidth on that is <16MB/s.
If you're really interested in this stuff the articles in the above link are a good read, as well as datasheets for the various chipsets involved. I'd recommend even looking at the original IBM PC/AT Technical Reference, with BIOS listings and full schematics.
If you're really interested in this stuff the articles in the above link are a good read, as well as datasheets for the various chipsets involved. I'd recommend even looking at the original IBM PC/AT Technical Reference, with BIOS listings and full schematics.
Indeed, fascinating! The CPU will have to wait thousands of waitstates for each bytes from the SPI-flash, but who cares in the first few ms of booting ;-). Thanks for pointing me in that direction!
There's quite some information also in the "7-series chipset datasheets" (and 8-series) from Intel, it seems that they have a very elaborate SPI implementation, in the chipset, in hardware...
There's quite some information also in the "7-series chipset datasheets" (and 8-series) from Intel, it seems that they have a very elaborate SPI implementation, in the chipset, in hardware...
If I recall corretly, the access is mapped to the SPI flash chip which is memory-mapped into the CPU address space by the chipset. Access to this address range is of course relatively slow, but that's always been true of BIOS flash.
The best place to look is probably Coreboot. It's the boot firmware used by Google Chromebooks. (Github mirror links used here for politeness to the project's servers.) Taking Intel Haswell processors as an example (because I know this code path) we can sketch the general process.
Start at 0xfffffff0, the boot vector for x86, executing in 16-bit "I can run DOS 1.0" mode. https://github.com/coreboot/coreboot/blob/master/src/cpu/x86...
It just jumps to the entry to 32-bit mode https://github.com/coreboot/coreboot/blob/master/src/cpu/x86...
Turn on FPU https://github.com/coreboot/coreboot/blob/master/src/cpu/x86...
Turn on SSE https://github.com/coreboot/coreboot/blob/master/src/cpu/x86...
Configure the cache not to require a backing DRAM so that it can be used temporarily as RAM. https://github.com/coreboot/coreboot/blob/master/src/cpu/int...
Now that "RAM" is available for use as a stack, the next steps can be written in plain-ole C https://github.com/coreboot/coreboot/blob/master/src/cpu/int...
From there, mainboard-specific code sets up things like which SuperIO chip to configure, the i2c addresses to interrogate for information on RAM geometry and timing, and how the chipset is wired to connectors on the board. Commong chipset (northbridge and southbridge) init code is run using that configuration data. https://github.com/coreboot/coreboot/blob/master/src/mainboa...
Then DRAM is initialized (the Haswell example is a bit lame in that currently a binary blob of compiled code from Intel does this job.) The Sandybridge DDR3 init was recently reverse-engineered and re-implemented and fully exemplifies the training processes required. https://github.com/coreboot/coreboot/blob/master/src/northbr...
Now that Gigagbytes of RAM are available, another boot stage is fetched from flash. When generic framework gets back to cpu-specific stuff, power management is configured,Inter-Processor Interrupt handlers are installed, and other cores go through a quick init sequence. https://github.com/coreboot/coreboot/blob/master/src/cpu/int...
Then essentially the PCI tree is walked to setup all the chipset devices. https://github.com/coreboot/coreboot/tree/master/src/southbr...
Once hardware is running, Coreboot loads a "payload" that is in turn responsible for loading the OS.
Start at 0xfffffff0, the boot vector for x86, executing in 16-bit "I can run DOS 1.0" mode. https://github.com/coreboot/coreboot/blob/master/src/cpu/x86...
It just jumps to the entry to 32-bit mode https://github.com/coreboot/coreboot/blob/master/src/cpu/x86...
Turn on FPU https://github.com/coreboot/coreboot/blob/master/src/cpu/x86...
Turn on SSE https://github.com/coreboot/coreboot/blob/master/src/cpu/x86...
Configure the cache not to require a backing DRAM so that it can be used temporarily as RAM. https://github.com/coreboot/coreboot/blob/master/src/cpu/int...
Now that "RAM" is available for use as a stack, the next steps can be written in plain-ole C https://github.com/coreboot/coreboot/blob/master/src/cpu/int...
From there, mainboard-specific code sets up things like which SuperIO chip to configure, the i2c addresses to interrogate for information on RAM geometry and timing, and how the chipset is wired to connectors on the board. Commong chipset (northbridge and southbridge) init code is run using that configuration data. https://github.com/coreboot/coreboot/blob/master/src/mainboa...
Then DRAM is initialized (the Haswell example is a bit lame in that currently a binary blob of compiled code from Intel does this job.) The Sandybridge DDR3 init was recently reverse-engineered and re-implemented and fully exemplifies the training processes required. https://github.com/coreboot/coreboot/blob/master/src/northbr...
Now that Gigagbytes of RAM are available, another boot stage is fetched from flash. When generic framework gets back to cpu-specific stuff, power management is configured,Inter-Processor Interrupt handlers are installed, and other cores go through a quick init sequence. https://github.com/coreboot/coreboot/blob/master/src/cpu/int...
Then essentially the PCI tree is walked to setup all the chipset devices. https://github.com/coreboot/coreboot/tree/master/src/southbr...
Once hardware is running, Coreboot loads a "payload" that is in turn responsible for loading the OS.
That's a really neat walk-through - mind if I put it on the coreboot wiki? And how do you want attribution to look like?
http://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."
"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."
I was just coming here to say I would pay money for a pre-rootkit-rootkit. Someone has to get there first and it might as well be my own code.
Can their be an external IO port that is both (a) fast and (b) access limited?
-- BadUSB shows that the USB controller can fake keystrokes, modify the recipient USB controller, etc.
-- This attack now shows an even more dangerous attack that can be mounted by a malicious thunderbolt adapter (the one that you unknowingly connected by habit at a conference, say).
Trammell is giving a longer talk about this work at CCC next week. (http://events.ccc.de/congress/2014/Fahrplan/events/6128.html)
The attack is implemented (he has a demo macbook with "ThunderStruck" bootloader), and it has been disclosed to apple >400 days ago.
One aspect of the attack can be patched with 2-byte change, but apparently apple hasn't bothered.
-- BadUSB shows that the USB controller can fake keystrokes, modify the recipient USB controller, etc.
-- This attack now shows an even more dangerous attack that can be mounted by a malicious thunderbolt adapter (the one that you unknowingly connected by habit at a conference, say).
Trammell is giving a longer talk about this work at CCC next week. (http://events.ccc.de/congress/2014/Fahrplan/events/6128.html)
The attack is implemented (he has a demo macbook with "ThunderStruck" bootloader), and it has been disclosed to apple >400 days ago.
One aspect of the attack can be patched with 2-byte change, but apparently apple hasn't bothered.
> Can their be an external IO port that is both (a) fast and (b) access limited?
Yes. eSATA is one example. 10 gigabit Ethernet is another. DisplayPort is, for certain applications.
Yes. eSATA is one example. 10 gigabit Ethernet is another. DisplayPort is, for certain applications.
I believe that the two year old Option ROM vulnerability to which this post refers was this one described by Loukas(snare) at Black Hat and Ruxcon 2012: https://www.youtube.com/watch?v=XcFvgAsfdqg
Although I may be wrong, it's certainly a related vulnerability and an interesting presentation to watch. Skip to ~54mins if you just want to see the demo.
Although I may be wrong, it's certainly a related vulnerability and an interesting presentation to watch. Skip to ~54mins if you just want to see the demo.
http://puri.sm
"The first high-end laptop that respects your freedom and privacy. The Purism Librem 15 is the first laptop in the world that ships without mystery software in the kernel, operating system, or any software applications."
"The first high-end laptop that respects your freedom and privacy. The Purism Librem 15 is the first laptop in the world that ships without mystery software in the kernel, operating system, or any software applications."
>i7-4770HQ
haha
Intel cant even get rid of binary blobs from their official open source Atom platform (minnowboard).
Intel UEFI bios is >100K lines of hand tuned spaghetti code that never saw version control system, thats straight from the mouth of Intel employee.
haha
Intel cant even get rid of binary blobs from their official open source Atom platform (minnowboard).
Intel UEFI bios is >100K lines of hand tuned spaghetti code that never saw version control system, thats straight from the mouth of Intel employee.
Actually Intel run EDK2/Tianocore, the open-source "reference implementation" of UEFI. Its core functionality is pretty good quality, but the repo is huge and there's a lot of junk in there. Actual motherboards usually run (closed) forks of it.
I know that legacy BIOS has its issues, but from what I have seen and read, EFI/UEFI is a quagmire.
(U)EFI is essentially a little OS that eventually loads the OS that runs the software you care about. Intel sponsors most of the core OS code (mirrored) at:
https://github.com/tianocore/edk2
A Bios vendor takes that code, drops in a bunch of hardware init code from Intel (or AMD), adds thier own user interface, "csm16" old-school BIOS implementation, and value-adds like debugging and automation for factory test and provisioning.
In order to comprehend anything in the codebase, the first step is probably to get acquainted with the local vernacular. https://github.com/tianocore/tianocore.github.io/wiki/Acrony...
A Bios vendor takes that code, drops in a bunch of hardware init code from Intel (or AMD), adds thier own user interface, "csm16" old-school BIOS implementation, and value-adds like debugging and automation for factory test and provisioning.
In order to comprehend anything in the codebase, the first step is probably to get acquainted with the local vernacular. https://github.com/tianocore/tianocore.github.io/wiki/Acrony...
The Gluglug (http://shop.gluglug.org.uk/product/ibm-lenovo-thinkpad-x60-c... ), basically a Thinkpad X60 with Coreboot, beat them to "first laptop in the world" (PC-compatible, at least), but maybe not "first high-end laptop". I think there's optional non-free microcode updates that might be useful, but it can definitely run 100% blob-free.
What CPU does it use? Does it need microcode?
Interesting thread on exactly how free this laptop is: https://trisquel.info/en/forum/librem-15-freelibre-and-open-...
(Edit: This post seems a bit harsh. My view is that any movement towards a more free laptop is welcome, especially since things like Android are going rapidly in the opposite direction)
Interesting thread on exactly how free this laptop is: https://trisquel.info/en/forum/librem-15-freelibre-and-open-...
(Edit: This post seems a bit harsh. My view is that any movement towards a more free laptop is welcome, especially since things like Android are going rapidly in the opposite direction)
You just won't get a blobless AMD or Intel computer. Intel for the chipset and CPU, AMD for the GPU firmware.
And ARM is worse, since a majority of the ARM ecosystem just acts like bootloaders and their gpu drivers don't even exist.
And ARM is worse, since a majority of the ARM ecosystem just acts like bootloaders and their gpu drivers don't even exist.
Thanks for the link. Who are the guys behind this?
I see you asked here as well [1]. Todd (the founder) answered some questions at Ars Technica: http://arstechnica.com/information-technology/2014/11/crowdf...
Do you need more than what he says there?
[1] https://news.ycombinator.com/item?id=8779973
Do you need more than what he says there?
[1] https://news.ycombinator.com/item?id=8779973
Purism CEO is Todd Weaver, he has posted on the Qubes list, https://groups.google.com/forum/m/#!topic/qubes-users/WX1IXB... where he responded to feedback by changing the motherboard design to increase max RAM and add a CPU with an IOMMU.
What I find most incredible about this is that apple has been told about this over and over again for the past 600 days, and did nothing would be the bigger issue.
I have watched Trammel demonstrate this attach right in front of me about a year ago. Apple has repeatedly ignored the fact that they are vulnerable.
It should also be noted that while this talk is Apple focused, it not a Apple thunderbolt specific attack. It affects all badly implemented thunderbolt ports.
Apple's growing popularity and strong hardware standardization makes them especially susceptible to the wormificaiton of this attack. How many offices have a supply cabinet with thunderbolt to HDMI/Ethernet/other connectors that are shared around the office freely?
I have watched Trammel demonstrate this attach right in front of me about a year ago. Apple has repeatedly ignored the fact that they are vulnerable.
It should also be noted that while this talk is Apple focused, it not a Apple thunderbolt specific attack. It affects all badly implemented thunderbolt ports.
Apple's growing popularity and strong hardware standardization makes them especially susceptible to the wormificaiton of this attack. How many offices have a supply cabinet with thunderbolt to HDMI/Ethernet/other connectors that are shared around the office freely?
Wanted:
- "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).
- "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).
The second thing you mention already sort-of exists in the form of qubes os: https://qubes-os.org/
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.
> 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.
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.
Would it be possible to create a virtual thunderbolt port similar to virtual cd/dvd drives? and if so would that be vulnerable?
Curious as to why the title is "EFI Firmware Security" and not "Apple EFI Firmware Security," which is the title of the piece linked?
No idea, but we changed it to agree with the article.
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...