Live data from Hacker News

Apple EFI Firmware Security Vulnerabilities

trmm.net

41–50 of 52 posts

Re: Apple EFI Firmware Security Vulnerabilities

#41
post #16

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

Re: Apple EFI Firmware Security Vulnerabilities

#42
post #37

Earlier quoted context omitted.

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

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.

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.

Re: Apple EFI Firmware Security Vulnerabilities

#43
post #14

Earlier quoted context omitted.

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

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

Re: Apple EFI Firmware Security Vulnerabilities

#44
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?

Re: Apple EFI Firmware Security Vulnerabilities

#45
post #7

Earlier quoted context omitted.

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

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 bric…

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

Re: Apple EFI Firmware Security Vulnerabilities

#46
post #7

Earlier quoted context omitted.

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

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 bric…

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

Re: Apple EFI Firmware Security Vulnerabilities

#47
post #19

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…

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

Re: Apple EFI Firmware Security Vulnerabilities

#48
post #34
post #23

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

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.

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

Re: Apple EFI Firmware Security Vulnerabilities

#49

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…

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.
Post reply on HN