Why Bother with Measured Boot?
Real system security is only effective with a measured boot design. (No, this is not a blog entry about footwear…)
Although a lot of attention is placed on Operating System (OS) protections (SELinux, ASLR, etc.), these protections mean little if an attacker tampers with the OS early in the boot process. For example, although SELinux is a powerful access-control mechanism, it can be disabled with a single boot argument passed via a bootloader. OS runtime protections also mean little if an attacker can just remove the hard drive and edit configuration files offline without restriction. A measured boot design can handle this attack too.
What is a Measured Boot?
The first step is to detect if a system has been compromised. One might think, “I’ll just use an application and/or kernel driver to make sure the OS files and/or memory-image haven’t been altered/compromised”. However, what if the system is already compromised, and THAT integrity check has been (maliciously) modified to always report “all good”?
Compared to the difficulty in exploiting application vulnerabilities, tampering with the OS boot process is both easy and practical -- this is a realm NOT limited to fictional spy thriller movie plots.
The boot process of a typical x86 computer involves many software components from a variety of sources.
UEFI/BIOS initializes memory, CPU, and other hardware
PCIe card option ROMs execute (network, storage, video, etc.)
A bootloader (usually GRUB2) loads OS kernel from disk
OS kernel boots
applications are launched
Which ones can an attacker target? All of the above!
Two Approaches for Measurement
With a measured boot solution, the basic idea is to measure each component before it has a chance to execute. Of course, this is only meaningful if measurements are done with the system in a trustworthy state. Additionally, it is also necessary that measurements cannot be altered once taken (it would be of little use if malware can “fudge” a measurement back to its correct value). A Trusted Platform Module (TPM) is often used to hold measurements since it is relatively isolated from the rest of the system. These measurements are stored in Platform Configuration Registers (PCRs) using a chain of cryptographic hashes not unlike the design of Git source control and blockchain technologies. The starting point for measurements is known as the “root of trust”.
Static Root of Trust for Measurement (SRTM)
By starting measurements as early as possible (e.g., at system power-on), a measurement trail can be established to prove that a system has not been altered (or to reliably detect tampering). This often begins with some sort of hardware-based mechanism (such as booting from an immutable ROM). This can guard against attacks such as modification of the UEFI/BIOS ROM flash content . The remainder of the measurements are typically performed using firmware / software. This scheme is known as a Static Root of Trust for Measurement (SRTM), since it begins at fixed point in the boot process (such as immutable early firmware / hardware, etc.). One of the most well-known implementations of SRTM is UEFI Secure Boot.
In the beginning...are the weakest links...
However, due to the complex nature of modern computing systems, each component is measured at runtime in a slightly different way. Furthermore, if any component has an exploitable vulnerability, then the entire root of trust can be broken. For example, in [1], the authors broke SRTM and forged PCR0 measurement on a Dell Latitude laptop due to BIOS implementation flaws that failed to ensure the firmware integrity in flash.
In addition, BIOS/UEFI firmware is not as simple as it once was. Rather than a few kilobytes of carefully crafted code, it now contains TCP/IP network stacks, device drivers, graphic subsystem, file system drivers, and a USB stack. The code size and complexity vastly exceed entire OSs from just a couple of decades ago. Consequently, the potential attack surface is enormous, without even considering that of third-party Option ROMs. Rather than a thing of the past, UEFI vulnerabilities are a major issue in current times. Just in 2022, Binarly found 23 high-impact vulnerabilities, many of which could be used to fully defeat UEFI Secure Boot [4]. The same year, ESET Research published [5] findings in Lenovo laptops, where UEFI Secure Boot could be disabled and/or defeated due to an accidental release of a “manufacturing process” feature shipped in end-user firmware in numerous products. These problems are not confined to a single vendor/supplier, but rather a consequence of system complexity.
Et tu, bootloader?
Even the GRUB bootloader is not what it appears. Too easily, one could assume it just loads the OS kernel from the disk and boots it. In the early days, Linux was booted using the LILO bootloader, a mere 8 kilobytes in size. Today, the GRUB2 bootloader contains a network stack, graphics system, filesystem/RAID drivers, and more. Its code size exceeds that of Windows 3.1. GRUB2 has almost 30 CVEs, including several integer/buffer-overflow vulnerabilities. For over 5 years, the GRUB2 password authentication mechanism could be bypassed by pressing backspace 28 times to trigger an out-of-bounds memory write (see [2]). Even in 2020, GRUB2 was vulnerable to an arbitrary-code execution vulnerability stemming from its configuration file parsing (see [3]). This vulnerability was successfully used to defeat UEFI Secure Boot!
Avoiding the bootloader is not enough!
Let’s cut out the middleman!
One might consider avoiding the need for the GRUB2 bootloader by utilizing the “EFI Stub” feature of the Linux kernel which allows directly booting the kernel from UEFI firmware. But even such alternatives are riddled with pitfalls. As shown on many popular “how-to” articles, directly booting the Linux kernel as an EFI image (and using an initramfs via the “initrd=” command-line argument) results in a UEFI Secure Boot system in which the initramfs is NOT measured! Tampering with such a system is trivial …
Although the recently developed Unified Kernel Image (UKI) provides a solution to the initramfs measurement issue, it is not a complete solution. For example, it provides no assurance that UEFI Secure Boot is even enabled! Moreover, creating a highly secure system with such a design requires a high degree of expertise in the UEFI Boot process and that of PCR usage. Lastly, UEFI key deployment/management is complex and involves a significant learning curve.
Dynamic Root of Trust for Measurement (DRTM)
A superior solution is to not entirely rely on BIOS/UEFI firmware and bootloaders and instead achieve a root of trust with a smaller set of components. This can both reduce the attack surface and reduce deployment complexity. This is a Dynamic Root of Trust Measurement (DRTM) in the sense that it begins at a later point in the boot process (of the designer’s choosing), not a pre-defined (static) location.
Such a scheme would normally be impossible since the components being excluded are the same ones which potentially may be compromised and actively attack the boot process. For example, malware running on one CPU core (perhaps loaded by a bootloader) could be attacking the normal boot process (via shared system memory) executed by the other cores. However, by using specific features of modern CPUs with specialized hardware and microcode design, a secure DRTM can be realized on both Intel and AMD CPUs. Furthermore, these designs also provide boot-time DMA-protection against malicious PCIe devices so that they cannot attack the boot process. Such a consideration is generally omitted from UEFI Secure Boot solutions.
Clearly, a secured boot process is not something that should be taken for granted. It becomes even more challenging to allow software updates without compromising security. At Star Lab, we have deep expertise in this area and unparalleled products that facilitate deployment of highly secure solutions – which go far beyond UEFI Secure Boot. For more information, please see our whitepaper at [6].
Stay tuned! In our next post in this series, we’ll be discussing best practices for making use of these measurements!