secure boot fails after upgrade to grub2-common 2.04-1ubuntu26.2

[Kyle Larose]

I've been using https://github.com/donbowman/ubuntu-secure-boot on my 18.04 system for secure boot for just over two years. It worked quite well. This morning I did a dist-upgrade. Upon reboot, the system complained that my kernel wasn't signed (something along the lines of "$KERNEL has invalid signature.").

I was fairly sure my kernel was signed, and signed properly, so I was somewhat confused. In the past, when I had messed this up, I was able to use `set check_signatures=no` to get the system to boot into the OS. This no longer worked; it is as though that flag is now being ignored. I had to disable secure boot in the bios to proceed and debug the problem.

I upgraded to 20.04 in the hopes that that would fix my problem. I had no success there either.

Searching around, I found this patch, which exists in a grub2 version published recently in both 18.04 and 20.04:

+ [ Dimitri John Ledkov ]
+ * SECURITY UPDATE: Grub does not enforce kernel signature validation
+ when the shim protocol isn't present.
+ - 0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch:
+ Fail kernel validation if the shim protocol isn't available
+ - CVE-2020-15705

...

diff -Nru grub2-2.04/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch grub2-2.04/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch
--- grub2-2.04/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch 1970-01-01 00:00:00.000000000 +0000
+++ grub2-2.04/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch 2020-07-20 18:19:08.000000000 +0000
@@ -0,0 +1,90 @@
+From 67508ab68e6a5be869e049a0e6474f4b717d3ab9 Mon Sep 17 00:00:00 2001
+From: Dimitri John Ledkov <email address hidden>
+Date: Wed, 22 Jul 2020 11:31:43 +0100
+Subject: linuxefi: fail kernel validation without shim protocol.
+
+If certificates that signed grub are installed into db, grub can be
+booted directly. It will then boot any kernel without signature
+validation. The booted kernel will think it was booted in secureboot
+mode and will implement lockdown, yet it could have been tampered.
+
+CVE-2020-15705
+
+Reported-by: Mathieu Trudel-Lapierre <email address hidden>
+Signed-off-by: Dimitri John Ledkov <email address hidden>
+---

<Main contents omitted>

See the following for the full diff http://launchpadlibrarian.net/490699204/grub2_2.04-1ubuntu26_2.04-1ubuntu26.1.diff.gz

The same can be seen in 18.04: http://launchpadlibrarian.net/490699210/grub2_2.02-2ubuntu8.15_2.02-2ubuntu8.16.diff.gz

I downgraded my grub to the version prior to this change (2.04-1ubuntu26) and I can now boot using secure boot.

Given that the patch I pasted above logs the same error I was seeing, and given that the change in 2.04-1ubuntu26.2 (the most recent) only touches the post install, I'm fairly confident in saying that the patch I pasted introduced my problem.

Now, perhaps there is a problem with how the secure boot package I am using working. I'd love to know what we should be doing differently if so. However, given the check_signatures=no isn't working any more, and it is in the official grub documentation (https://www.gnu.org/software/grub/manual/grub/html_node/check_005fsignatures.html) I think there's at least one bug here.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.6
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Aug 6 15:55:17 2020
InstallationDate: Installed on 2018-05-10 (818 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: grub2
UpgradeStatus: Upgraded to focal on 2020-08-06 (0 days ago)

[Julian Andres Klode (juliank)]

That set check_signatures=no does not work seems correct, you don't want to be able to circumvent secure boot just by editing
grub.cfg

Given that you vastly modified your boot configuration, I don't think this is actionable. I'd suggest you remove that package and maybe reinstall in case it does not fully get rid of it. Not only does it break your boot, it also makes it less secure by replacing trusted binaries with binaries you can sign just by gaining root access, completely circumventing the idea of secure boot preventing rootkits etc.

[Julian Andres Klode (juliank)]

Also make sure to reinstall shim, as we do not support secure boot without shim.

Note that what the repo says is not true anymore: We verify the kernels we load, and bootloader, and the entire boot path. And these kernels are signed outside your machine, which means you can't modify them, giving you the assurance that they are not tampered with - if you self-sign, you can just be self-signing your tampered kernel (even offline, if you do not use FDE).

[Don Bowman (donbowman)]

I'm the author of that secure boot package.
I think you might misunderstand... what it does is put all the grub config etc into a signed initramfs. So you cannot change the grub.cfg.
Also, to sign the binaries you need the GPG keyring and the passphrase.

The objective is to *not* use the shipped trusted microsoft key. The only key in the UEFI keystore is our own chain of trust. So The goal is to *not* use shim.

It is used in conjunction w/ full disk encryption. The only file unencrypted is a single grub w/ the ininitramfs, and that is in turn signed. The kernel, etc, are all on the encrypted disk. Thus they cannot be tampered with by e.g. removing the disk etc.

Installing shim means adding someone else trust, which I don't accept.

I'm not sure what "don't support secure boot without shim" means, but I don't think that can or should be true. It doesn't support booting the Microsoft signed keys w/o shim, but, its certainly legal to remove the Microsoft keys from the BIOS and still use secureboot.

as for the check_signatures=no, I'm ok if that is removed as a feature I guess, but it would need to be removed from the documentation. In my case its not a reduction in security (since you cannot change the grub.cfg w/o having the trust chain anyway).

so tldr:
* no, shim is not required to support secureboot
* yes, you can self sign securely
* no, merely having an option in grub.cfg or grub cmdline to disable subsequent checks need not reduce the security, as long as it is gated by being in a signed initramfs (and grub password is as strong as bios password)

[Reiner (rschulz-gmail)]

Thank you Don for setting the record straight re shim!

I too installed my own secure boot keys following this tutorial: https://wiki.gentoo.org/wiki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot . And upon the grub upgrade from 2.04-1ubuntu26 to 2.04-1ubuntu26.2, my machine failed to boot as well with the same invalid signature message. The complete message read:

Loading Linux 5.4.0-42-generic ...
error: /boot/vmlinuz-5.4.0-42-generic has invalid signature.
Loading initial ramdisk ...
error: you need to load the kernel first.

I do not have shim installed, precisely because I did not want to use the Microsoft keys.
My setup (full disk encryption and secure boot) worked since May 2019. I could have done without the adrenaline buzz when it suddenly stopped working. Downgrading all installed grub packages to 2.04-1ubuntu26 made the system work again. Thank you Kyle for documenting that!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dimitri John Ledkov (xnox)]

> I've been using https://github.com/donbowman/ubuntu-secure-boot on my 18.04 system for secure boot for just over two years.

Hi,

If you are still using above, your systems are still susceptible to the Boot Hole attack.

You must rotate all of your signing keys, and only sign grub & kernels with Boot Hole mitigation present going forward.

Grub alone, is insufficient to guarantee that under secureboot your systems are not susceptible to attacks.
*Even with integration that above repository claims to provide*

In the spirit of what software from the above repository does, specifically distrust any public signatures and use private key infrastructure please do the following:
* Install shim-signed
* optionally strip signatures from shim
* UEFI secureboot sign shim / mokmanager / fallback using your own private key
* Enroll the Canonical Master Certificate Authority into MOKX to distrust it, i.e. using `mokkutil --mokx --import`
* update boot entries to boot shim -> grub

Note that by default, over the years Ubuntu shim/grub/kernel have signfinicantly improved and provide far stronger out of the bux, security & lockdown guarantees in more recent releases than what the above repository alludes to. I strongly recommend you to stop using that github repo. Using above git repository opens up a much larger bootloader attack surface than otherwise available with stock Ubuntu 20.04 LTS.

The last unique feature that above github repository provides is automated initrd signing, which currently is not integrated out of the box on Ubuntu classic systems, but is being worked on and already available on Ubuntu Core for the embedded use case.

[Dimitri John Ledkov (xnox)]

Shim provides a lot more than just a chain of trust. It is also the protocol to perform TPM2 measurements, for local and remote attestation.

For ultimate security, whilst using custom chain of trust, one must use shim and ensure that vendor certificate is excluded from trust either via dbx or mokx. When desired to skip signature validation, there is ability to request shim to disable-validation, but that requires reboot and access to mokmanager, such that tpm measurements are affected. This prevents installing rootkits or accessing TPM sealed secrets unauthorized (prefix attacks).

Not using shim, results in insecure systems susceptible to Boot Hole and TPM measurements prefix attacks.

It seems that you are asking us to lower our security standards for our bootloader. If stock Ubuntu bootloader is too secure for your insecure usecases, please build your own grub images. By policy we will no longer sign grub bootloaders that allow bypass of validation without affecting TPM measurements.

[Julian Andres Klode (juliank)]

> I think you might misunderstand... what it does is put all the grub config etc into a signed initramfs. So you cannot change the grub.cfg.

I think grub's name for that is not initramfs, but something different? Anyway:

I suggest you look at my secureboot project, you'll see I understand what you're trying to achieve - I did the same thing with systemd-boot.

Now - this is a _very special_ use case, and not what secure boot is designed for (it was designed against systems installing rootkits, not local users fiddling with your FDE). I think shim even allowed you to boot unsigned stuff by pressing a key at some point, because local users are trusted.

Optimally, what you want to do on new kernels and stuff is to take them to a separate offline machine with the key, sign them and transfer them back to reduce the rootkit risk.

The repository makes no mention of that special use case, potentially causing people to install it who do not have FDE or do not need the additional properties of signed early userspace. It only says "Ubuntu is not checking signatures at all, this does", and that's not helpful. If users come along and install it, thinking they make their system more secure, and don't know the tradeoff they make, that's bad.

> I'm not sure what "don't support secure boot without shim" means

You forgot the "we". Shim is part of our secure boot process, and we do not test or work on or support booting without it.

[Julian Andres Klode (juliank)]

Also, we use EFI signing, not gpg signing for kernels, and hence cannot make any guarantees about non-EFI-signed binaries.

[Steve Langasek (vorlon)]

This is definitively not a bug in the Ubuntu grub2 package. You have installed a third-party tool, on which the Ubuntu developers have never been consulted, that redirects the grub installation and claims to be more secure, but has not tracked the evolution of SecureBoot support in Ubuntu over the past 5 years.

Use of custom SecureBoot key databases and self-signed binaries is fine, but where this is incompatible with the Ubuntu grub2 package, this is not supported.

[Don Bowman (donbowman)]

ok, can i at least assume that shim is not required? that was my main issue.
i wanted a single unencrypted file (grub + initramfs by another name:), and, my chain of trust.

that is the key for me, if there is a requirement to only use shim and the microsoft keys, i'm in trouble.

if its simply that canonical doesn't test w/o shim, that's ok. But it seems empirically that shim is now a hard requirement since the valid signed kernel no longer validates w/ this patch of grub.

i guess also to the original bug from the original author here, perhaps removing the no-longer-supported option from grub doc would be good? the set check_signatures=no

[Dimitri John Ledkov (xnox)]

using shim does not require using microsoft keys.

you can use shim, signed with your own key and empty db, and distrusted canonical ca as I have pointed out above, or like configure shim to disable validation altogether.

I repeat _microsoft keys are not required_.

What is required is for shim apis to be available to grub.

This way grub can assert that it is enforcing whatever policies you want to be enforced, including skipping signature validations via shim, even when booted under secureboot when configured using `mokutil --disable-validation`.

We must check that shim api is present to ensure that shim set policies are enforced and honored (which for you deployment will mean, to ensure that shim validation is _not trusted_).