Linked by Thom Holwerda on Sun 29th Oct 2017 17:44 UTC
Google

Two weeks ago, security researchers managed to disable the Intel Management Engine, and last week, Google held a talk at the Open Source Summit (née LinuxCon) in which they unveiled their plans to completely (well, almost completely) replace every bit of code between the operating system you know about (Windows, Linux, BSD, whatever) and the bare metal x86 processor (Intel-only, for now).

With the WikiLeaks release of the vault7 material, the security of the UEFI (Unified Extensible Firmware Interface) firmware used in most PCs and laptops is once again a concern. UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a "Ring -2 hypervisor"). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs.

Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs. The initramfs file system contains an init and command line utilities from the u-root project (http://u-root.tk/), which are written in the Go language.

Both the slides from the talk and the video are available.

Order by: Score:
v Amazing Code.
by Superflukin on Sun 29th Oct 2017 18:48 UTC
How do you verify the code in the firmware?
by teco.sb on Sun 29th Oct 2017 19:00 UTC
teco.sb
Member since:
2014-05-08

I think the larger problem is, how do you verify that the firmware code is actually compiled from that particular source? If you cannot load your own firmware (I know, a pipe dream) how is this different than the current situation? Not just that, if a vulnerability in the current code is found, can you actually update it yourself?

I used to have a Samsung Galaxy Nexus, and know all too well what happens when support is arbitrarily dropped. I would probably still have that phone were I able to load the latest version of Android. But since TI dropped support for the OMAP SoC, I could not upgrade beyond 3.4.

Reply Score: 4

Brendan Member since:
2005-11-16

Hi,

I think the larger problem is, how do you verify that the firmware code is actually compiled from that particular source? If you cannot load your own firmware (I know, a pipe dream) how is this different than the current situation? Not just that, if a vulnerability in the current code is found, can you actually update it yourself?


The other problem is that if you want to do something else (e.g. boot Haiku from USB, boot MS-DOS from CD-ROM, boot FreeBSD from hard drive, etc) you're screwed because they stripped out all of the "non essential" functionality, and if you want to change your hardware (e.g. upgrade the video card) you're also screwed because that'd require a little extensibility.

Mostly it sounds like they're using "open source" as yet another form of vendor lock-in; to make sure the computer will only ever be able to run one specific OS and nothing else (e.g. maybe a special Linux distro created by Google, for Google's benefit and not yours).

- Brendan

Reply Score: 3

jing Member since:
2017-08-19

Trammel is involved with the NERF project
and the project probably use HEADS firmware as a payload:

https://media.ccc.de/v/33c3-8314-bootstraping_a_slightly_more_secure...

HEADS firmware (Linux) can boot any os via kexec
min 39:00s to min 40:30s

Reply Score: 5

Brendan Member since:
2005-11-16

Hi,

Trammel is involved with the NERF project
and the project probably use HEADS firmware as a payload:

https://media.ccc.de/v/33c3-8314-bootstraping_a_slightly_more_secure...

HEADS firmware (Linux) can boot any os via kexec
min 39:00s to min 40:30s


So you can use kexec to boot Windows, and OS X, and Haiku, and MS-DOS, and FreeBSD, and Solaris, and ...?

- Brendan

Reply Score: 4

jing Member since:
2017-08-19

Don't know for MacOS and Windows but those can be virtualized via kvm or xen :-)
for the rest of the list I think so, they should boot.

https://en.wikipedia.org/wiki/Multiboot_Specification

anyway...someone did implement a kexec syscall in a freebsd derivative... and used it to boot linux...
https://github.com/fail0verflow/ps4-kexec

https://www.youtube.com/watch?v=2A7V3GLWF6U

Reply Score: 1

Brendan Member since:
2005-11-16

Hi,

Don't know for MacOS and Windows but those can be virtualized via kvm or xen :-)


Awesome - destroy the capabilities the firmware needed to work properly in an attempt to reduce the attack surface; and then increase the attack surface by multiple orders of magnitude more than it ever was to work around the fact that you've destroyed all the capabilities the firmware needs to work properly!


for the rest of the list I think so, they should boot.

https://en.wikipedia.org/wiki/Multiboot_Specification


The only OS (that I know of) that uses Multiboot was Solaris.

Linux (and its "kexec()") have never officially used or supported Multiboot. Note: if I remember correctly, once upon a time there was a patch written by GRUB developers to add Multiboot support to Linux that was rejected by Linux developers and then died.

anyway...someone did implement a kexec syscall in a freebsd derivative... and used it to boot linux...
https://github.com/fail0verflow/ps4-kexec


Sounds great until Linux updates/improves/changes "kexec()" (or more correctly, the Linux Boot Protocol) and both new versions of Linux and that one "FreeBSD derivative" no longer boot (preventing you from running the firmware update tool/s needed to fix/update the firmware).

Note: The original "kexec()" on Linux was exploitable (allowed unsigned kernels to be booted, so a hacker could use a signed Linux kernel followed by "kexec()" to bypass UEFI Secure Boot); and this was eventually fixed. The patch you linked to has the same exploit without the fix.

- Brendan

Reply Score: 3

Bill Shooter of Bul Member since:
2006-07-14

That is the exact reason why Google has the new project treble. If the bulk of the software can be updated without the hardware drivers needing to change devices can stay useful longer.

But thats oreo and beyond so maybe the nexus 5x will be a long lived device? One can dream anyways.

Reply Score: 3

yoshi314@gmail.com Member since:
2009-12-14

and the hardware driver security holes (intentional or not) will remain there for longer.

Reply Score: 2

Kochise Member since:
2006-03-03

Since there's no firmware upgrade after a while, the holes will remains anyway. Without the system upgrade either in the old case.

Reply Score: 2

am i missing something
by codifies on Sun 29th Oct 2017 21:42 UTC
codifies
Member since:
2014-02-14

coreboot, libreboot, openbios...

there are alternatives already... auditable alternatives....

Reply Score: 3

RE: am i missing something
by The1stImmortal on Sun 29th Oct 2017 22:01 UTC in reply to "am i missing something"
The1stImmortal Member since:
2005-10-20

coreboot, libreboot, openbios...

there are alternatives already... auditable alternatives....

And none of those seem to address the Intel IME/AMD PSP security coprocessor issue. This one at least plans to, though how successful it can be I don't know.

Edited 2017-10-29 22:01 UTC

Reply Score: 4

RE[2]: am i missing something
by FlyingJester on Mon 30th Oct 2017 20:34 UTC in reply to "RE: am i missing something"
FlyingJester Member since:
2016-05-11

Why wouldn't you just put that into one of the existing (shipping) solutions, like Coreboot?

Reply Score: 3

v RE[3]: am i missing something
by The1stImmortal on Mon 30th Oct 2017 20:46 UTC in reply to "RE[2]: am i missing something"
RE[4]: am i missing something
by leech on Tue 31st Oct 2017 11:48 UTC in reply to "RE[3]: am i missing something"
leech Member since:
2006-01-10

The purism Librem laptops also disable the IME, and they use Coreboot, if I recall, so it's not just a Google thing, for sure.

Reply Score: 0

RE: am i missing something
by zima on Tue 31st Oct 2017 23:58 UTC in reply to "am i missing something"
zima Member since:
2005-07-06

I'm partial to the Open Firmware (of which openbios, which you mention, seems to be an implementation) - used in many ~alternative systems (like Pegasos for MorphOS) or in the One Laptop Per Child XO-1 ...not chosen over UEFI seemingly because it just wasn't done by Intel.

And written in Forth... (one day I'll learn it, I promise ;) )

Edited 2017-11-01 00:06 UTC

Reply Score: 3

Disable?
by Munchkinguy on Tue 31st Oct 2017 03:40 UTC
Munchkinguy
Member since:
2007-12-22

I might be confusing it with something else, but isn't it possible to disable UEFI in the CMOS setup?

Reply Score: 1

RE: Disable?
by ssokolow on Tue 31st Oct 2017 10:04 UTC in reply to "Disable?"
ssokolow Member since:
2010-01-21

You're thinking of Secure Boot. UEFI is what's used these days instead of BIOS.

(The UEFI is responsible for things like initializing your RAM and bringing your motherboard into a state where an OS can recognize it. "The CMOS setup" just configures a very small portion of it.)

Edited 2017-10-31 10:05 UTC

Reply Score: 3

RE[2]: Disable?
by leech on Tue 31st Oct 2017 11:47 UTC in reply to "RE: Disable?"
leech Member since:
2006-01-10

Not to mention you don't really disable it, it's more like BIOS emulation mode.

Reply Score: 0

Terrifying
by Lazarus on Tue 31st Oct 2017 04:08 UTC
Lazarus
Member since:
2005-08-10

Replacing one buggy nightmare with another...

Reply Score: 3