2

First some definitions and common understanding.

The premise of secure boot is that each binary get's verified before it is loaded. This starts with the firmware in ROM verifying the EFI application.

For the case of a Linux boot that EFI application is shim which is signed with a Microsoft key embedded in most x86/64 hardware. The rom verifies and runs shim.

Shim verifies and runs grub (the most commonly used bootloader for Linux in x86).

Grub then verifies and runs the kernel, which verifies and mounts the rootfs and handles control to user-space apps.

The problem is grub usually has a config file grub.cfg which is accessible from user-space. By allowing user-space to modify this file the chain of trust gets broken and a malicious user-space app can now enable installation of a compromised kernel.

It is true that the userspace loaded will initially be coming from a verified kernel, but userspace has a much larger attack surface then just the boot process. So a compromised userspace allows for installation of a compromised kernel and an even more compromised userspace.

How is grub.cfg usually protected?

  • 1
    Did you overlook "Grub then **verifies** and runs the kernel". Modifying the config can only load a properly signed kernel binary. The chain depends on the attacker not having the correct key to sign his compromised kernel. – Ben Voigt Sep 30 '21 at 15:55
  • Now, failure to verify the config file could be used for other attacks, such as a downgrade attack by loading an older legitimate kernel created prior to patches for known vulnerabilities. But can't load an arbitrary kernel created by the attacker. – Ben Voigt Sep 30 '21 at 15:56
  • Updated with new context. – TheMeaningfulEngineer Oct 01 '21 at 07:50
  • Compromised user-space can copy a new kernel to the filesystem, and can modify grub.cfg to point to it, but it won't boot because it is not properly signed. That is the protection, stated in the very first sentence you quoted. – Ben Voigt Oct 01 '21 at 15:10

0 Answers0