BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot

[Slartifartblast]

Secureboot, a pestilence. I'm sure just about every secret service agency around the World is able to bypass it and put persistent bootable code on a PC should they so desire.

[NotMine999]

When I first read the title of this article I thought ... "I know a great boot cobbler. I've been taking my boots to them for decades."

Then I read the article and realized it's another "security flaw" that requires either "admin privileges" or "physical access" or both to pull off.

That reminded me of something I learned in an entry-level security class decades ago: "If you have physical access to your target, then there is no security. So do as you please."

[starshipeleven]

Secureboot, a pestilence. I'm sure just about every secret service agency around the World is able to bypass it and put persistent bootable code on a PC should they so desire.

Secureboot is fine, it's just a signature checking system and you can delete Windows key and enroll your own keys.

The issue is that the UEFI firmwares are a joke, but BIOS isn't different in this regard either.

[starshipeleven]

When I first read the title of this article I thought ... "I know a great boot cobbler. I've been taking my boots to them for decades."

Then I read the article and realized it's another "security flaw" that requires either "admin privileges" or "physical access" or both to pull off.

GRUB will read a grub.cfg from the EFI partition too, so no root required

[Guest]

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

Well, preferably a grub-install parameter so that people don't have to recompile GRUB to get the behaviour they want.

[Guest]

It will require,
Or the helper functions or the parser flex/Bison DSL code, need to change, and so they need to revoke the earlier keys, and sign it again( the new version )..
This for EFI, of course..
basically they need to add the previous keys to the dbx database( disallow database )
remove the previous keys from the db( Allow Database )
Sign the new software versions, and put the key in db( Allow Database )

Yeah, it took me a while to understand that they're talking about different OS and system vendors having their own binaries of GRUB signed with some Microsoft key, so that they can boot it.

This means even big companies (say those who buy desktop/server hardware) aren't using their own keys instead of Microsoft's, they're just buying the machines with Microsoft keys pre-installed, and depending on Microsoft to sign their bootloaders for them (and that even RHEL and others depend on Microsoft to do so).

This means that Microsoft pretty much has full control over what OS can run on consumer hardware, servers etc. and a bunch of other stuff. And this doesn't bother people?

I could accept SecureBoot as security if atleast some people had the option of having hardware that didn't require Microsoft to approve of the OS being booted. But now it seems clear that SecureBoot is inextricably dependent on Microsoft not being evil and anti-competitive.

Are people really this naive?

[starshipeleven]

Well, preferably a grub-install parameter so that people don't have to recompile GRUB to get the behaviour they want.

I would prefer to remove that ability completely, it's plain bad for UEFI and most distros aren't using it either.

[starshipeleven]

Yeah, it took me a while to understand that they're talking about different OS and system vendors having their own binaries of GRUB signed with some Microsoft key, so that they can boot it.

They are using a common MS-signed shim that is then loading its own key database to check distro-specific keys to then authorize GRUB binary. https://www.suse.com/c/uefi-secure-boot-details/

Microsoft pretty much has full control over what OS can run on consumer hardware, servers etc. and a bunch of other stuff. And this doesn't bother people?

The only devices where Secureboot cannot be either turned off or enroll new keys are some tablets with crappy Atom x86 processors (that aren't really worth using anyway), because that's required by MS, but now they can be jailbroken because MS has accidentally released a master key for that.

Everything else must follow UEFI spec and provide a way to disable Secure Boot from UEFI settings, so MS isn't controlling anything.


I'm much more bothered by the fact that UEFI is a dumpster fire and HW manufacturers can't even be bothered enough to install a physical dip-switch to disable writing on the board flash chip (which is 100% possible, all SPI flash chips can be put in RO mode by pulling down or up one of the pins) and therefore there is no real way to ensure that I'm not booting malware bullshit that is stealing my disk encryption key, with or without secure boot.

[Slartifartblast]

Everything else must follow UEFI spec and provide a way to disable Secure Boot from UEFI settings, so MS isn't controlling anything.

Incorrect, as of Win 10 this is no longer required of manufacturers and it's up to them to allow secureboot to be disabled.

[tuxd3v]

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

yeah, the ESP partition is crazy stuff indeed..

Anyway,
The flex/bison DSL parser, detects the oversize of the string to load, but unfortunately it doesn't exit in that situation :/