Secure Boot in the Era of the T2
Today, the Duo Labs team is releasing an in-depth look at Apple’s new approach to secure boot as described in Apple’s recently released T2 Security Chip Overview.
Enabled by the T2 chipset, new generations of the Macbook Pro and the iMac Pro aim to mitigate many software and hardware-based attacks against the very first pieces of code executed during the initial boot process. By ditching the flash memory chip containing Unified Extensible Firmware Interface (UEFI) firmware and using chipset functionality typically reserved for server architectures, the T2 is able to dynamically provide and validate UEFI payload contents at runtime.
We have spent considerable time looking at the T2 and have written a paper that outlines the technical details of what actually happens when the power button is pressed. The T2 is a great first step in the right direction, but there is still room for improvement when it comes to the secure boot process on an Apple T2-enabled device.
UEFI firmware contains some of the earliest code executed by modern computers at power on. It is in charge of setting up and initializing low-level hardware components before locating the operating system and handing off control of the boot sequence to the operating system’s kernel. Whether through leveraging operating system OS vulnerabilities or through an ‘evil-maid attack,’ the attacker’s goal is to inject their code into this durable storage medium.
If this firmware can be modified by an attacker, it could subvert security subsystems in order to effectively backdoor the operating system. These types of attacks are commonly referred to as bootkits and can be extremely difficult to detect as they live outside of the OS installation and can even survive OS reinstallation and hard disk replacement.
The crux of UEFI firmware security is that the code to validate the firmware image itself lives in the UEFI firmware image. This leads to the classic chicken and egg problem: How can you trust the result of the firmware validation routine without trusting the routine itself? To address this, Apple took the approach of entirely removing the firmware containing the flash chip and outfitted the T2 with what is called Slave Attached Flash (SAF) capability. This allows the T2 to first validate firmware signatures before providing the UEFI firmware to the rest of the chipset for execution.
Using an immutable, signature-validated image for UEFI firmware would be a huge win in terms of platform security. However, reality gets in the way. The traditional flash chip not only contains UEFI firmware, it also contains all the system firmware that enables the Intel Management Engine (ME) to operate, which uses areas of the flash chip for non-volatile storage. What the T2 ends up doing during ‘first-boot’ scenarios is validating the signature on Apple-provided images and then copies them over to internal mutable flash storage. So while the image is known to have started out as good and trusted, it can theoretically degrade into an untrusted state through external writes.
This is compounded with the complexity of the T2. It is coupled with the host OS, exposing new attack surface. Much of its functionality can be interfaced with from userland without having root permissions. A bug in the Apple XNU common-kernel used in many Apple products could effectively create a shortcut for an attacker. That’s not to say there is no benefit to be gleaned from a unified codebase. Apple’s masked-ROM rooted chain-of-trust, through the efforts of Apple’s engineers and security researchers worldwide, has matured in to one of the hardest targets in existence. Apple should be lauded for trying to bring their laptop and desktop lines into the same defensive posture as their mobile offerings.