
Apple EFI Firmware Security Vulnerabilities - SpaceInvader
https://trmm.net/EFI
======
userbinator
Remember 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...

~~~
weinzierl
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
    

The jumper could enable the erase voltage for the flash. On the other hand it
could also just pull up or down a pin that is queried before the flash routine
does its work. For example one Intel Mobo manual[1] says explicitly the jumper
protects from _accidental_ corruption.

    
    
        Jumper JP4 controls the protection scheme that
        prevents accidental damage to or rewriting of the data
        stored in Flash memory.[1]
    
    

[1] [http://www.manualslib.com/manual/77721/Intel-
Iwill-P4d-N.htm...](http://www.manualslib.com/manual/77721/Intel-
Iwill-P4d-N.html?page=40)

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

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

~~~
userbinator
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/](https://sites.google.com/site/pinczakko/)

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

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

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

------
walterbell
[http://theinvisiblethings.blogspot.ca/2011/09/anti-evil-
maid...](http://theinvisiblethings.blogspot.ca/2011/09/anti-evil-maid.html)

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

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

------
abhv
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](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.

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

------
dominicgs
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](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.

------
walterbell
[http://puri.sm](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."_

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

~~~
RexRollman
I know that legacy BIOS has its issues, but from what I have seen and read,
EFI/UEFI is a quagmire.

~~~
tryp
(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](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...](https://github.com/tianocore/tianocore.github.io/wiki/Acronyms-
and-Glossary)

------
georgyo
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?

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

~~~
SCHiM
The second thing you mention already sort-of exists in the form of qubes os:
[https://qubes-os.org/](https://qubes-os.org/)

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

------
pix64
Would it be possible to create a virtual thunderbolt port similar to virtual
cd/dvd drives? and if so would that be vulnerable?

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

~~~
amluto
That wouldn't help. This attack happens long before the OS loads, and EFI
explicitly _executes_ code from the option ROM, so DMA isn't even involved.

------
markbnj
Curious as to why the title is "EFI Firmware Security" and not "Apple EFI
Firmware Security," which is the title of the piece linked?

~~~
wmf
Do we have reason to believe that non-Apple implementations are any better?

Most non-Apple computers don't have an external PCI bus, so there's that.

~~~
markbnj
No, not necessarily, and yet the article was specifically about an Apple
exploit. Just seemed off to omit that from the post title.

