Secure Boot: this is not the protection we are looking for

Before being a technology, secure boot is an English expression. But, what does it mean to boot securely? What are we trying to achieve and to protect?

First, we want user data protection from a secure system. User data is really any piece of data a user might display or edit, including the obvious office documents but also configuration files, databases, downloaded files, log files, user commands, etc. These data must be protected in confidentiality. For this, the system must ensure that these data are protected at rest, when the system is shutdown. However, this is not enough, since access from unauthorized software could leak the data, for instance over the network or by copying it on an external removable drive. Hence, a secure system should only run authorized software.

Secure Boot, the technology

Secure Boot¹ helps running only authorized software on a machine. It does so by bootstrapping the security of the system at boot time, by verifying signatures on various software components, before giving way to other technologies to keep the system secure, later on. Secure boot works by authorizing only select executables to be run. Authorized executables are signed using public cryptography, and the keys used to verify those signatures are stored securely in UEFI “databases”.

UEFI is the successor of the now nearly defunct BIOS. It is an interface between the operating system and the manufacturer platform, a firmware, that runs very early on most modern systems. The platform is responsible of, among many other things, executing the bootloader (for instance, Grub or systemd-boot). Generally, the bootloader then starts an operating system. In the case of GNU/Systemd/Linux, the bootloader runs the Linux kernel, which shuts down all UEFI Boot Services, before dropping its privileges and then doing “Linux stuff” (like starting the userland part of the operating system). This privilege drop is very important because this is what ensures that no code past that point is able to tamper with the UEFI sensitive information, including UEFI variables, which contains sensitive data.

Secure Boot aims at securing “everything” that is executed prior to that privilege drop. Once the privileges are drop, Secure Boot is done and it is up to the operating system to extend that integrity/authenticity protection and ensure that only authorized software is run. Most Linux distros do not even try to do it, although there are notable exceptions (Chrome OS, Android, just to name a few). If we run one of the distros that do not leverage technologies such as dm-verity, fs-verity (with signatures) or Linux IMA (Integrity Management Architecture), then Secure Boot protected the boot integrity for basically nothing, because the security chain is broken by the operating system, and user data is at risk from possibly any tainted userland executable.

Nevertheless, ANSSI, the French Infosec Agency recommends in its GNU/Linux security guide² to enable Secure Boot (R3) for all systems requiring medium security level (level 2 out of 4, 1 being the minimal requirements and 4 being for highly secure systems). Meanwhile, using a Unified Kernel Image to bundle the Linux kernel with a initramfs into a single executable that can be verified by Secure Boot is only recommended³ for highly secure systems (security level 4 out of 4). No recommendation is ever done about using one of the aforementioned integrity features to ensure operating system integrity.

Interestingly, a poll on the fediverse⁴ revealed that 89% of the respondants thinks that Secure Boot is necessary for intermediate security level, and 45% even think that it should be a minimum requirement.

This article is a strong push-back against ANSSI “recommendation”, and it attempts to prove that it is not only useless but incoherent and misleading.

Signature verification and default public keys

Secure boot relies on a set of public keys to verify authorized software authenticity. By default, most vendors ship Microsoft public keys. These keys sign all Microsoft Windows version, of course, but to avoid a monopoly, other executables were signed. The list is ought to be short (and unfortunately, it is not) because with each signature and authorized software, the attack surface grows and the probability of a vulnerability raises. Several were already found in the recent past (e.g. CVE-2020-10713⁵, CVE-2022-34301⁶, CVE-2022-34302⁷, CVE-2022-34303⁸.

For this reason, many software still require that Secure Boot be deactivated, including firmware updates by some manufacturers, including Intel⁹ or Lenovo¹⁰.

Grub and the kernels are not directly authorized by Microsoft, as it would require for each and every single version to be signed individually by Microsoft. Instead, a binary called Shim¹¹ was developed. This rather small, auditable, innocuous-looking program is signed by Microsoft. Its role is basically that of a trojan horse (or a security pivot, depending on the way you look at it). Indeed, its only purpose is to cryptographically verify the authenticity of any executable. However, this time, the list of public keys used to verify these executables is not directly under the control of Microsoft. These public keys are either built in Shim itself or stored in a EFI variable serving as a database.

Additionally, shim public key list can be altered by any user able to prove “presence”. This is the case of any user using the local console or using a BMC for remote console access. Once a new public key enrolled, all executables verifiable by that key can run in the UEFI privileged mode, and for instance create a persistent backdoor in the bootstrapping code of the machine.

If this was not enough, users able to prove “presence” can also disable shim verification of authorized software. This means that shim can be used to have the system believe that Secure Boot was used to bootstrap security, while untrusted code was ultimately run within the UEFI privileged mode.

Hence, thanks to shim, just about any signed or unsigned, trusted or untrusted executable can be validated by proxy by Secure Boot using Microsoft keys.

And this conclusion signs (pun intended) the second incoherence in ANSSI recommendations. Indeed, they recommend replacing Microsoft keys by our own set of keys only for highly secure security level (R4). This means that all systems with intermediate (2/4) and enhanced (3/4) security levels will have the false sense of security of running Secure Boot while exposing themselves to attackers capable of proving “presence”.

For what it is worth, shim does provide a way secure all operations, including disabling verification or enrolling new keys by setting a password on shim’s MOK (Machine Owner Keys) Manager¹². However, the feature is mostly unused because no Linux distro enables it (it requires user interaction during the boot procedure) and system administrators often mistake the MOK Manager password, which secures the access to the MOK Manager as a whole, with the password that is asked when running mokutil commands (including --import and --disable-verification), which is just a password used to confirm the will of the user in the MOK Manager. The author of this article failed to find a single tutorial or article discussing the necessity of setting a MOK Manager for a Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a MOK Manager password is recommended even for Windows administrators that have no intention of ever running Linux, because MOK Manager is one of the executables signed by the Microsoft keys.

Using our own set of Secure Boot keys (PK and KEK)

Since replacing the Microsoft keys and signing only authorized binaries (i.e. our own Unified Kernel Image and specifically not shim) is an option, why not do that? It just requires that the system administrators replace the Secure Boot keys. The question of who controls the private key and the signature process is entirely up to whether the signed executable is altered or not by the system administrator. Distros could ship public keys and Unified Kernel Images instead of relying on Shim. If we run our own kernel, as recommended by ANSSI (R15 to R27), then we need to handle the private key and the signature process ourselves.

With a Unified Kernel Image signed and verified by Secure Boot, we are now sure that only our code is executed, and we can safely ask for the user passphrase to unlock the LUKS container. This way, user data is protected at rest, and accessed only by authorized software. Cool. Except it is not.

First, as mentioned earlier, the only thing that we verified is that the Unified Kernel Image is authentic. That kernel must then verify the operating system to ensure that only verified software is run. This requires cryptographic verification of every single executable (binaries, scripts and executable configuration files (because… yeah… that’s a thing)) in the operating system. This can be achieved if we, at minimum, do the following:

• use a read-only filesystem for our partitions containing executable code, enforced using dm-verity, or fs-verity with file signature or Linux IMA, or something similar;

• use the noexec mount option on data partitions;

• modify command interpreters to ensure they do not execute scripts from mount points with noexec nor from STDIN;

• prevent writable memory from ever getting executed, by patching the kernel;

• ensure that no executable configuration file is writable.

Welcome in Wonderland, Alice.

Ok, but let’s assume we go down that rabbit hole… are we secure yet?

No. No, we are not.

Because there is no way of telling if our Secure Boot implementation is tainted by an attacker or not. Indeed, someone could have flashed our UEFI firmware before we enabled Secure Boot. Or they could have disabled it, flashed and reenabled it, if we did not have a UEFI administration password at some point. Or they could have abused shim when we were using the default keys to flash UEFI.

Nirvana Fallacy much?

So, if Secure Boot is not a good answer, especially against an attacker capable of physical access or remote access through a BMC, what is? Is there a better solution?

Well, to the best of the author knowledge, there is one: using a TPM. Using a TPM will not necessarily prevent an attacker from tainting the firmware. It will not necessarily prevent booting untrusted and unverified executables. What a TPM can give us is the ability to unseal a LUKS passphrase and get access to user data if and only if the cryptographically verified right version of UEFI firmware, Unified Kernel Image and operating system image have been booted. This is based on PCR policies, that ties the sealed passphrase to a particular signed set of executables measured by the TPM. This approach ensures user data confidentiality at rest and the authenticity of the executables that are on disk during boot. Of course, it does not prevent executing writable memory, nor user data flagged as executable, including scripts, and executable configuration files. And of course, having a signed set of policies means handling a private key and designing a signature procedure. There is no free lunch. Sorry.

However, using a TPM offers the same security level against attackers with physical access, attackers with remote access through a BMC, and a rogue system administrator, and that is something that Secure Boot cannot brag about.

Conclusion

So there you have it: recommending idly Secure Boot for all systems requiring intermediate security level accomplishes nothing, except maybe giving more work to system administrators that are recompiling their kernel, while offering exactly no measurable security against many threats if UEFI Administrative password and MOK Manager passwords are not set. This is especially true for laptop systems where physical access cannot be prevented for obvious reasons. For servers in colocation, the risk of physical access is not null. And finally for many servers, the risk of a rogue employee somewhere in the supply chain, or the maintenance chain cannot be easily ruled out.