Apple EFI Firmware Security Vulnerabilities

Remember when BIOS flash ROMs were write-protected with a physical hardware switch&#x2F;jumper? It was an extremely simple measure that basically made it impossible for the BIOS to be corrupted by software, malicious or otherwise.<p>It was certainly &quot;inconvenient&quot; to perform BIOS updates, but back in those days BIOS updates weren&#x27;t all that common either. I don&#x27;t think it should ever be &quot;convenient&quot; 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 &quot;boot from a floppy to a plain DOS prompt, run the updater, and wait for a few tense seconds as it updated the BIOS&quot;.<p>The mention of &quot;Thunderbolt Option ROM&quot; 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&#x27;t plug a random untrusted PCI(e) adapter into your system, you should exercise the same caution with Thunderbolt...

Out of curiosity: Can anyone point me where to find how a recent x86-cpu actually boots? Where&#x27;s the code that gets executed in the first few CPU cycles?<p>The bulk of the firmware, that&#x27;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?<p>I know how initial bootup works on my day-job-default-CPU (a m68k&#x2F;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 &quot;typical&quot; intel core&#x2F;i5..7&#x2F;... CPU.

<a href="http://theinvisiblethings.blogspot.ca/2011/09/anti-evil-maid.html" rel="nofollow">http:&#x2F;&#x2F;theinvisiblethings.blogspot.ca&#x2F;2011&#x2F;09&#x2F;anti-evil-maid...</a><p><i>&quot;Anti Evil Maid is an implementation of a TPM-based static trusted boot with a primary goal to prevent Evil Maid attacks.<p>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&#x27;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>&quot;

Can their be an external IO port that is both (a) fast and (b) access limited?<p>-- BadUSB shows that the USB controller can fake keystrokes, modify the recipient USB controller, etc.<p>-- 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).<p>Trammell is giving a longer talk about this work at CCC next week. (<a href="http://events.ccc.de/congress/2014/Fahrplan/events/6128.html" rel="nofollow">http:&#x2F;&#x2F;events.ccc.de&#x2F;congress&#x2F;2014&#x2F;Fahrplan&#x2F;events&#x2F;6128.html</a>)<p>The attack is implemented (he has a demo macbook with &quot;ThunderStruck&quot; bootloader), and it has been disclosed to apple &gt;400 days ago.<p>One aspect of the attack can be patched with 2-byte change, but apparently apple hasn&#x27;t bothered.

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: <a href="https://www.youtube.com/watch?v=XcFvgAsfdqg" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XcFvgAsfdqg</a><p>Although I may be wrong, it&#x27;s certainly a related vulnerability and an interesting presentation to watch. Skip to ~54mins if you just want to see the demo.

<a href="http://puri.sm" rel="nofollow">http:&#x2F;&#x2F;puri.sm</a><p><i>&quot;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.&quot;</i>

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.<p>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.<p>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.<p>Apple&#x27;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&#x2F;Ethernet&#x2F;other connectors that are shared around the office freely?

Wanted:<p>- &quot;Tripwire&quot; for firmware - host-based (not perfect) &amp; bootable live cd&#x2F;usb&#x2F;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.)<p>- Host-based peripheral firewall (not perfect, but more usable) - e.g.: selectively disable, ask user permission and&#x2F;or limit rights to connecting devices from the various buses: USB, FW, PCI, SD card, SATA&#x2F;SAS, BT, TB, SPI, FC, ... On OSX, it&#x27;s doable considering VMware Fusion &quot;patches&quot; IOKit (check out IORegistryExplorer) selectively based on user preferences (whether to redirect a USB device to a guest or to the host).

&gt; the larger issue of Apple&#x27;s EFI firmware security and secure booting with no trusted hardware is more difficult to fix.<p>IMO this shouldn&#x27;t really be a problem. If the SPI payload disables writes before executing anything unsigned, then it&#x27;s really quite hard to bypass.<p>Presumably the bug is a result of EFI capsule on disk support. The design is sh*t for exactly this reason.<p>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&#x2F;dvd drives? and if so would that be vulnerable?

Has anyone looked at using VTd to secure Thunderbolt devices from the system bus?

Curious as to why the title is &quot;EFI Firmware Security&quot; and not &quot;Apple EFI Firmware Security,&quot; which is the title of the piece linked?