[shasheene]

> With the sole exception of one bootable tool vendor who added custom code to perform a signature verification of the grub.cfg config file in addition to the signature verification performed on the GRUB2 executable, all versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable.

Perhaps the ability to sign grub.cfg should be added to GRUB2, and this feature should be enabled by default.

Though this would mean rather than allowing users to enter arbitrary kernel boot options (and being able to leverage buffer overflow exploits), a bunch of preset menu items would have to be present. Alternatively, this signed grub.cfg can have its boot menu password-protected. (If I recall correctly individual menu items cannot be password protected.)

Lowering the GRUB2 attack surface area is a good idea, so hopefully these suggestions get deeply considered.

[mjg59]

How would that work? If the public key is baked into the signed grub, the only person who can sign the config is whoever built grub. If the keypair is generated locally and the public half put on the ESP, an attacker can just replace it. Signed config works if you never need to modify the config, but for a general purpose OS you need to be able to modify the config.

[shasheene]

Sorry, I forgot that typical grub.cfg contains the root partition's UUID (and at least historically, the partition device node). While it is possible to configure GRUB to scan for a root partition rather than using a UUID, this is less secure (eg, GRUB residing on your hard drive could then accidentally select your root partition residing on a USB stick containing Linux live media).

Good point that in general, the operating system vendor does not know the grub.cfg on an installed system, and that an attacker with direct access to the ESP can modify the files that are present there.

A static grub.cfg that selects "the Linux root partition is the first partition on the device on which this GRUB bootloader is installed on" would work. I don't believe GRUB supports this kind of behavior (maybe it should). It seems worthwhile and possible to design a mechanism where a simple grub.cfg can be signed by the operating system vendor. Disabling the ability to arbitrarily modify kernel boot options on a general purpose operating system is not a big deal, and could be mitigated with extra GRUB boot menu items.