🦊

Secure Boot

Overview

Secure Boot is a UEFI feature which ensures that only trusted software is loaded during boot.

UEFI supports four key databases:

This Chain of Trust extendeds past UEFI.

shim signing

The aim [of shim] was to ensure that it would remain possible to install free operating systems on UEFI Secure Boot platforms while still allowing machine owners to replace their bootloaders and kernels, and it’s achieved this goal.

However, a legitimate criticism has been that there’s very little transparency in Microsoft’s signing process. Some people have waited for significant periods of time before being receiving a response. A large part of this is simply that demand has been greater than expected, and Microsoft aren’t in the best position to review code that they didn’t write in the first place.

To that end, we’re adopting a new model. A mailing list has been created at [email protected], and members of this list will review submissions and provide a recommendation to Microsoft on whether these should be signed or not. The current set of expectations around binaries to be signed documented here and the current process here - it is expected that this will evolve slightly as we get used to the process, and we’ll provide a more formal set of documentation once things have settled down. - mjg59

Signing currenty takes place on rhboot/shim-reivew.

SBAT (UEFI Secure Boot Advanced Targeting)

SBAT allows vendors to set and revoke (“ratchet”) ephemeral keys so that revocations through the dbx are not needed

mokutil can be used to set/upgrade/downgrade sbat

mokutil --set-sbat-policy

SBATLevel policy defines the minimum SBAT level of each binary that shim should trust. Default policy is previous. mokutil can request latest policy.

Used for vendor revocations, so industry wide DBX coordination is not required.

Working with Keys

List Key Databases

mokutil --pk
mokutil --kek
mokutil --dbx
mokutil --db
mokutil --list-enrolled
mokutil --list-enrolled --mokx

Convert a CRT to DER:

openssl x509 -outform der -in uefi.crt -out uefi.der

Create and enroll a MOK keyring:

# verify secure boot is enabled
mokutil --sb-state
# generate private key
# nb: UEFI requires RSA2048
openssl req -new -x509 -newkey rsa:2048 -keyout mok.priv outform -out mok.der
# create public key
openssl x509 -inform der -in mok.der -out mok.pem
# set MOKManager password
sudo mokutil --password
# enroll key
sudo mokutil --import uefi.der
# verify enrollment
mokutil --list-new
reboot
# MOKManager will load on reboot
# use menu to add custom MOK
# re-enter linux and verify enrollment
mokutil --list-enrolled
# binaries can now be signed and used, e.g.
sudo sbsign --key mok.priv --cert mok.pem /boot/vmlinuz-6.5.0-15-generic \
  --output /boot/vmlinuz-6.5.0-15-generic.signed
sudo mv /boot/vmlinuz-6.5.0-15-generic.signed /boot/vmlinuz-6.5.0-15-generic
# for kernel modules see kmodsign
# check module with modinfo -F signer <module>

For automated MOK generation and signing see update-secureboot-policy and kmodsign.

Get Microsoft’s Keys

git clone [email protected]:microsoft/secureboot_objects.git

Secure Boot on Ubuntu

Maintained by Ubuntu UEFI Team.

PK comes from hardware vendor. KEK, DBX, and DB are based on Microsoft’s databases. DBX is distributed by secureboot-db, but can also be updated with fwupd. Microsoft’s DB signs our shim. shim sets ephemeral MOK keys. Latest SBAT level must be requested by the user.

grub2 package is not used for Secure Boot. The grub2 package is copied to grub2-unsigned on release initialization. All further updates go to grub2 -unsigned. This package is signed, by the X from MOK, to generate grub2-signed which is actually used by Secure Boot.

Vulnerabilities

BootHole

Mickey Shkatov and Jesse Michael from Eclypsium discovered a heap-based buffer overflow in the configuration parser of GRUB2 which allowed arbitrary code execution (ACE) and ultimately Secure Boot bypass (CVE-2020-10713). Reporter’s analysis: There’s a Hole in the Boot.

All signed versions of GRUB2 were affected by BootHole. To mitigate BootHole 153 signatures needed to be added to the DBX–a third of available UEFI space. Until this mass revocation occured, a local attacker could elevate their privlege to machine owner by using a vulnerable, but valid, GRUB2. Poorly handled revocation can soft-brick production servers. Industry wide mass revocation stalled in coordination. BootHole prompted the creation of SBAT (releaesd in shim 15.7).

BlackLotus

BlackLotus was made infamous in 2022 for being sold on hacking forums as a Secure Boot bypass rootkit. See Martin Smolár’s analysis in BlackLotus UEFI bootkit: Myth confirmed and Microsoft’s Incident Response. An initial stage of BlackLotus re-implements Baton Drop (CVE-2022-21894) to posion MOK. This was possibly since vulnerable Microsoft Window Boot Managers had valid signatures, similar to BootHole. On 2023-05-09 Microsoft released an updated DBX to prevent Baton Drop. Perhaps through foresight, NSA’s mitigation guide recommends removing Microsoft’s CA all together (see NSA’s UEFI Secure Boot Customization).

References