BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot

[Paradigm Shifter]

Thank to all who responded with so much information.

I remember being deeply unhappy with the SecureBoot proposal at the time it was announced, and just as unhappy with the "fix/workaround" that the Linux distros developed in the form of the "shim". Not just because it all relies on the goodness of Microsoft's heart, but because the shim method itself appeared to provide a perfect stage for malicious modifications to the next thing the shim called, while still believing that everything was OK.

It is something of a double-edged sword, because due to Microsoft laying down the law to various OEMs regarding how things had to be, we have less of a mess than it could be - as starshipeleven points out above with regards to methods for booting ARM systems. But the viability of other operating systems on any hardware with SecureBoot is predicated on the benevolence of what could be broadly interpreted as a dictatorship... which has historically shown itself to be anything but benevolent.

Don't even get me started on some of the early ideas for UEFI, which included such wonderful insanity as "OS-free browser", "OS-free media player" and similar nonsense. There are several ideas for which UEFI applications would make sense - eg: a battery level tester for laptops so that if you try to boot it up at a charge where it might not get through boot (less of a problem with SSDs and <10 second boot times) it pops up a "please charge the battery first" message... but a web browser which may or may not get timely security updates? And has the ability to write to any FAT32 filesystem? Like, oh, the EFI partition? Uh...

Ars Technica reported that from Windows 10 the ability to disable SecureBoot would be optional, but I've not yet encountered a system where I couldn't turn it off; admittedly, with the exception of laptops I build other systems myself, so have no idea what desktop ODMs might be doing.

Why on earth grub will happily read a .cfg file from the EFI partition I have no idea; I'm surprised that that hadn't been identified (and abused) in the past. Well, actually, for all I know it has been but those using it have kept quiet...

[tuxd3v]

You can sign it, keep it in /boot (in an encrypted root setup) or do whatever. There are many ways to make it safe.

For the moment, the DSL parser doesn't verify the signature..

You need to run grub-update scripts anyway after each edit, just make them sign again the file.

The signing of a file only makes sense if you will later verify its signature, which doesn't happen( Only one vendor do that.. ).
For that to happen it needs to sign the file, and later verify the file at boot time..

What key you will use to sign the file?
Usually you sign a file with a private key( it doesn't need to be that way, but usually it does.. )

Because on servers none is giving a fuck, it's probably going to be running blobs for the cards and stuff anyway.

A lot of people do.
Its a severe concern on the server.. on the desktop its almost irrelevant,
GNU/Linux in the Desktop is almost a pipe dream, we can't say the same on the server were it rules by a large margin..

[Jabberwocky]

Why do you even need that? UEFI forces you to have a "boot partition" where you must drop a bootloader and you must sign it because you can't encrypt the EFI partition, what's the difference between using GRUB and just dropping the whole kernel in EFI?

Direct UEFI is probably be the best option when UEFI is available. It's ironic though if I went through the effort to hide the EFI partition (on a flash drive for example) then this BootHole vulnerability would not have been a concern for me.

I might try experimenting with something like this, it's probably not worth the effort: https://www.reddit.com/r/archlinux/c...cryption_with/

I have a few systems where UEFI doesn't work (yet) and I have to use GRUB2/TrustedGRUB2 to plug the holes somewhat. It doesn't look like it's maintained very well, but it at least allows full disk encryption which I value above latest TPM support (for my non-mobile devices anyway). It's being looked-at/discussed by some: https://linuxplumbersconf.org/event/...and_TPM2.0.pdf

[Paradigm Shifter]

I might try experimenting with something like this, it's probably not worth the effort: https://www.reddit.com/r/archlinux/c...cryption_with/

Thanks for this. I linked earlier in the thread to a Gentoo equivalent.

[starshipeleven]

For the moment, the DSL parser doesn't verify the signature..
...
The signing of a file only makes sense if you will later verify its signature, which doesn't happen( Only one vendor do that.. ).
For that to happen it needs to sign the file, and later verify the file at boot time..

I'm not saying what GRUB does, I'm saying how it can do it safely.

What key you will use to sign the file?
Usually you sign a file with a private key( it doesn't need to be that way, but usually it does.. )

It can generate its own and change it every time it wants, since with grub-update scripts you can have them change the binary in the /boot/efi folder too.

A lot of people do.
Its a severe concern on the server..

No, not really. Most servers are full of blobs and firmwares and whatnot, hardware raid, 10+ GB network cards, NVIDIA Quadro GPUs. People deploying them and administering them are used to dealing with a system where you trust the vendor to some extent.

[starshipeleven]

if I went through the effort to hide the EFI partition (on a flash drive for example) then this BootHole vulnerability would not have been a concern for me.

Yes, but if you are using a removable EFI there is even less reason to use GRUB.

I might try experimenting with something like this, it's probably not worth the effort:

Yeah it really isn't. The main problem is that UEFI firmware itself is not worth of any trust, so whatever matrioska you do with encrypted partitions inside other encrypted partitions on flash drives, you still won't avoid UEFI rootkits and the ME/PSP.

This means that your security setup does not really need to be over the top like that, and just using Secure boot and encrypting root fs is enough to twart all attacks that aren't sophisticate enough to actually compromise UEFI to get at you. (and let's be fair, most attacks aren't going to)

I mean yeah it would be cool if you could get better security than that without moving to an ARM board or the Talos PowerPC thing from Raptor Computing Systems, but since you can't, there is no point in beating around the bush like that.

If you really need this level of security, then you must use different hardware you can actually trust first.

I have a few systems where UEFI doesn't work (yet) and I have to use GRUB2/TrustedGRUB2 to plug the holes somewhat.

Same as above, it's ok to have some security because 99% of the attacks will probably be low-skill, but don't go overboard, since BIOS is also crap and will execute whatever is in MBR so anyone can just replace that to point to his own malware and keylog the shit out of your PC.

[Slartifartblast]

Really, if we are talking of board firmware and hardware interfaces in general, Microsoft has been a very positive force, ruling with an iron fist and slapping the OEMs into compliance of some standards for booting,

Hmmm, Bill Gates saw it differently

http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf

When supping with the devil, use a long spoon.

[starshipeleven]

Hmmm, Bill Gates saw it differently

Lol, I think he failed.

MS has their own ACPI stuff and compiler https://docs.microsoft.com/en-us/win...t-asl-compiler and devices using ACPI tables compiled with that are causing grief sometimes because something is buggy or weird and Linux isn't 100% reading them correctly these ACPI tables, but for most systems all that bs has been reverse-engineered and implemented years ago.

In the end we got "Linux working great without doing the work", which is what I said.

When supping with the devil, use a long spoon.

Even evil people can do good actions, not for good reasons maybe.

[Kano]

Bugs happen everyday but for most Linux installations this kid of bug does not really matter. If you are able to modify the grub.cfg then a rootkit or any other backdoor could be placed as well. Some distributions restrict loading of unsigned kernel modules by default in case of active secure boot but if you want to load Nvidia or any other out of tree module you have to disable this or secure boot.

Btw. I am sure 99 % of all Linux installs don't secure the GRUB edit feature. It takes just a few seconds on a reboot to be root. But maybe I a wrong and somebody can tell me some distributions with default password protection for the edit mode.

[starshipeleven]

Bugs happen everyday but for most Linux installations this kid of bug does not really matter. If you are able to modify the grub.cfg then a rootkit or any other backdoor could be placed as well.

grub will read any grub.cfg file placed in the same folder of its EFI binary, which is in the EFI partition.