BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot

[jesusdf]

The patch in question is already on the GRUB2 mailing list:

https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html

[starshipeleven]

Well maybe I haven't read it well enough, but it does not seem like such a terrible vulnerability, Yes, the code is wrong and need fixing, but once fixed people will still be able to load nasty things by just changing grub.cfg, if they are root. And root should of course be able to. And somebody with local physical access should be able too, in many cases. For the other cases where it is worth it, you go to physical protection.

Always use rubbers.

That said, this is a problem because GRUB will read a config file from the same folder the GRUB binary is, so anyone that can access EFI partition can access this vulnerability (and worse) https://www.phoronix.com/forums/foru...80#post1197580

I think the reason it gets highlighted is because the deployment of fixes is problematic because it might brick stuff if done wrong. But this is not a grub problem, this is the conceptual weakness of secure boot, that had to break somewhere and it just happened to break in grub.

It is not very coherent that MS has to revoke keys in order to fix a free program. Or rather in order to forbid the vulnerable version of it.

This is the "bullshit system", aka what Microsoft does, and they had already problems with their EFI bootloaders similar to this.

Secure Boot can import new keys too, and that's what most distros are doing, so you or the distro maintainers are in charge of what key is still valid and what are revoked. This way it won't boot anymore the vulnerable grub payload.

[bug77]

Exactly! The people reporting this vulnerability make it out to be some huge problem. I mean, it kind of is, but only if the attacker gains root access, modifies the boot.cfg file, and then the system is rebooted without checking the grub.cfg file...........I fail to see how it's a huge practical concern.

Obviously whatever parsing bug it is should be fixed, but practically, if the attacker has that much access, they can already steal existing data, and install a lot of other malware besides.......and it doesn't survive OS reinstallation like they claim it does. It doesn't change UEFI in any way, it merely takes advantage of GRUB to boot whatever at the beginning.

Well, attackers can install stuff to keep spying on you forever, that's most concerning about this.
But now that it's discovered and patched, we should move on.

[phoron]

Well maybe I haven't read it well enough, but it does not seem like such a terrible vulnerability, Yes, the code is wrong and need fixing, but once fixed people will still be able to load nasty things by just changing grub.cfg, if they are root. And root should of course be able to. And somebody with local hysical access should be able too, in many cases. For the other cases where it is worth it, you go to physical protection.

I think the reason it gets highlighted is because the deployment of fixes is problematic because it might brick stuff if done wrong. But this is not a grub problem, this is the conceptual weakness of secure boot, that had to break somewhere and it just happened to break in grub.

It is not very coherent that MS has to revoke keys in order to fix a free program. Or rather in order to forbid the vulnerable version of it.

If you force grub to check signatures in all their files and images then you make it harder for people to personalize their free software (not so hard they just have to keep their personal keys safe, configure them and sign all changes). You could make it easier with some nice UIs but you could also socially engineer people around it.

The ultimate problem is trust. It makes no sense that a vendor tells you what should you trust, but it also doesn't make much sense that MS signs a shim that can basically load anything. The root of trust should be each user, not MS. But if the user does not know what it wants or does, then he simply cannot trust himself. The solution is to use less complex software, learn enough to be able to at least delegate some trust, and distrust much anything you don't understand (until you understand it at least a little).

But they pretend to sell trust in a box and that will never ever work. The worst that can happen is that now they start a spin campaign to stop people to be able to load what they want in their own computers, and further tivoization like in mobile and so on. I hope more than I expect people to be less gullible than that.

[starshipeleven]

Ok so apparently even if you have your grub.cfg in an encrypted partition, GRUB will happily use any grub.cfg that's on the same partition it's loaded from. So anyone can drop a modified grub.cfg file into your unencrypted ESP and GRUB will just use that. Facepalm. (Got this info from Matthew Garrett).

Ah, that's neat. I hope this capability gets disabled by a compile option because it's insane for security.

[starshipeleven]

Surely the greater news with this bug is that SecureBoot doesn't succeed in doing what it was designed to? (Which IIRC also happened with Windows' EFI handling a few years ago? I forget the details...)

Umm... no? Secure Boot is doing its job, booting the signed bootloader application.
It really cannot magically keep people from exploiting bugs in the signed, genuine bootloader application.
Same as with Microsoft's EFI bootloaders.

The main difference is that with Microsoft everything is signed with the same key (that they also leaked afaik, so at this point... whatever) so you can easily just swap the good bootloader with the vulnerable one, while for decent Linux setups you are signing the bootloader with your own key and importing that into the UEFI keychain, so it's as easy as changing the key and removing the old one, boom it won't boot the vulnerable bootloader anymore.

So it's another case of "if malicious actor has root/admin, you're screwed".

It seems so. To exploit this you need to edit a config file that is usually in /boot so if you encrypt your drive it should not be accessible without knowing the password and having root privileges.
EDIT Nope, see below, anyone can add a grub.cfg in the ESP partition and GRUB will read it, so you don't need root access for this exploit.

[Mike Frett]

This right here is why some of us are crying out for things to be made in Rust. Is it perfect? Hell no! It shows signs of being maintained by drug addicts. But it is an improvement over C for security, however.

I don't care what kind of drugs you're doing as long as your work is A+.

[mdedetrich]

This right here is why some of us are crying out for things to be made in Rust. Is it perfect? Hell no! It shows signs of being maintained by drug addicts. But it is an improvement over C for security, however.

Yeah exactly. This appears to have been a buffer overflow in reading a configuration file which would have been caught by Rust

Also this is the reason why people make a big deal out of Rust, code written in C/C++ has a very high chance of having security vulnerabilities which effect everyone. Even if the code was originally written without any bugs by a very good programmer, it still needs to be maintained and it gets worked on by other people. The argument that "we should just write better C/C++ or get better C/C++ programmers" clearly is not working.

Surely the greater news with this bug is that SecureBoot doesn't succeed in doing what it was designed to? (Which IIRC also happened with Windows' EFI handling a few years ago? I forget the details...)

So it's another case of "if malicious actor has root/admin, you're screwed". Which really should be the first disclaimer on any system, because it's always true - some of the things anyone compromising a system can do are more (or less) obvious than others, of course.

For the truly paranoid about this, I remember reading a guide a couple of years ago setting up Gentoo with the bootloader on a USB stick which could be pulled out as soon as the OS was up. Hard to do malicious mods to the bootloader if it's missing...

Well it's not SecureBoot itself that is the problem here, it's actually the bootloader that is compromised here. I agree that the boot process is vulnerable, but SecureBoot itself doesn't have a vulnerability.

[Paradigm Shifter]

Surely the greater news with this bug is that SecureBoot doesn't succeed in doing what it was designed to? (Which IIRC also happened with Windows' EFI handling a few years ago? I forget the details...)

So it's another case of "if malicious actor has root/admin, you're screwed". Which really should be the first disclaimer on any system, because it's always true - some of the things anyone compromising a system can do are more (or less) obvious than others, of course.

For the truly paranoid about this, I remember reading a guide a couple of years ago setting up Gentoo with the bootloader on a USB stick which could be pulled out as soon as the OS was up. Hard to do malicious mods to the bootloader if it's missing...