Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple EFI Firmware Security Vulnerabilities

trmm.net

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Apple EFI Firmware Security Vulnerabilities

#31

Post by cnvogel »

userbinator wrote: post #29
cnvogel wrote: post #25

Earlier quoted context omitted.

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

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

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

Re: Apple EFI Firmware Security Vulnerabilities

#32

Post by userbinator »

weinzierl wrote: post #15
userbinator wrote: post #3

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

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

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.

Re: Apple EFI Firmware Security Vulnerabilities

#34

Post by wmf »

markbnj wrote: 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.

Re: Apple EFI Firmware Security Vulnerabilities

#35

Post by pascal_cuoq »

foxhill wrote: post #7
userbinator wrote: post #3

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

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.

Re: Apple EFI Firmware Security Vulnerabilities

#36

Post by thanksgiving »

mattstocum wrote: post #24
aroch wrote: post #5

Earlier quoted context omitted.

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

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

Re: Apple EFI Firmware Security Vulnerabilities

#37

Post by m45t3r »

thanksgiving wrote: post #36
mattstocum wrote: post #24

Earlier quoted context omitted.

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

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.

Re: Apple EFI Firmware Security Vulnerabilities

#38

Post by walterbell »

listic wrote: post #30
walterbell wrote: post #11

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

Thanks for the link. Who are the guys behind this?

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.

Re: Apple EFI Firmware Security Vulnerabilities

#39

Post by sounds »

listic wrote: post #30
walterbell wrote: post #11

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

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

Post reply on HN