quis custodiet ipsos custodes —

Microsoft’s new Secured-core PC initiative short circuits firmware attacks

Secured-core extends the root of trust past the boot environment itself.

Bar chart shows increasing number of firmware vulnerabilities
As recently as 2016, firmware vulnerabilities weren't being sought out and found very often. But starting in 2017, one or more has been discovered pretty much every day.

Microsoft on Tuesday announced a new hardware security initiative, dubbed Secured-core PC. The short version of what "Secured-core PC" really means is a defense against attacks at the firmware layer.

Although actual firmware-based attacks have been relatively uncommon in the field so far, they represent a particularly nasty avenue of exploitation for an advanced, persistent attacker. Once a machine's firmware is compromised, the exploit is persistent across reboots, operating-system re-installations, and even full hard drive replacement.

As operating systems themselves become more secure and difficult to compromise and keep compromised, the value of pivoting from a shell to the firmware layer in order to enhance persistence also increases. Even detection of compromised firmware is problematic, since Windows Defender and other antivirus applications run at the operating-system level and don't necessarily have direct access to the firmware.

From Secure Boot to System Guard Secure Launch

Microsoft's image of a laptop exploded into layers—which somehow includes a desktop motherboard—is pretty silly. But the list of technologies and what each protects against is useful.
Enlarge / Microsoft's image of a laptop exploded into layers—which somehow includes a desktop motherboard—is pretty silly. But the list of technologies and what each protects against is useful.
Microsoft

Beginning with Windows 8, Microsoft leveraged UEFI core capabilities to ensure that only trusted operating-system bootloaders could launch. Secure Boot verifies that the initial bootloader is signed with a key that's trusted by the firmware. This prevents the use of "rootkits," or malicious software that loads before the operating system itself. By loading before the operating system itself, a rootkit could ensure that it had the absolute highest level of system privilege, thus hiding it from detection efforts from within the operating system.

Secure Boot largely solved the rootkit problem, but since it runs on the already-trusted firmware itself, it can't help with compromises to that firmware. That's where System Guard Secure Launch comes in. SGSL allows the system to launch initially on untrusted code, but then it takes control of all CPUs and, Microsoft says, "forces them down a well-known and measured code path."

Unpacking the "well-known and measured code path" requires some deeper knowledge of the particular platform System Guard Secure Launch is being run on. Fortunately, AMD provided a pretty deep technical explainer for it. We also reached out to Intel, but its promotional material was vague and not much help on a technical level, so the rest of our coverage will focus on AMD's implementation of SGSL.

SKINIT and the dynamic root of trust measurement

In AMD CPUs, an instruction called SKINIT—a homophonous abbreviation of "secure init"—reinitializes the processor. This is sort of like hitting a "reset" button; it makes certain that the system state is effectively blanked out prior to the execution of the AMD Secure Loader. This instruction only accepts one parameter, which is the address of a 64KB block of RAM that contains the Secure Loader. SKINIT then marks the 64KB block of RAM containing the Secure Loader as the Secure Loader Block, which cannot be tampered with afterward. It also writes the address of the Secure Loader Block into the Trusted Platform Module (TPM) itself.

The Secure Loader then measures and authenticates the firmware and bootloader itself and gathers information such as physical memory map, APIC and IOMMU configuration, and more for future verification by the OS. It then validates, initializes, and transitions control to the Security Kernel, which is trusted code that controls access to system resources at the operating-system level.

The short version is this—UEFI Secure Boot prevents a bootloader from running if it wasn't signed with a trusted key; System Guard Secure Launch also prevents a compromised bootloader—or any later-executed code at the operating system level—from "cleaning up after itself." Since it's kept immutable in RAM at the device level and its address is readable from the TPM itself, the operating system can inspect the bootloader—and key system parameters that otherwise might be used to "hide" memory or functions from it—with assurance of validity later.

SKINIT is an AMD-specific term and instruction, but as Intel has also published its adherence to Microsoft's new System Guard Secure Launch and Secured-core PC initiative, we can assume its CPUs offer a very similar instruction to perform largely the same tasks.

System Management Mode

The remaining attack surface that must be protected is System Management Mode. SMM is a special x86 CPU mode that handles low-level tasks including power management, hardware configuration, and thermal monitoring. When one of these system operations is requested, an SMI interrupt calls and executes SMM code installed by the BIOS. This code executes in the highest privilege level, which makes it invisible to the operating system and grants it access across hypervisor memory barriers.

SMI handlers are generally provided by the motherboard manufacturer, not the operating-system manufacturer or CPU manufacturer. Since a handler runs at the very highest privilege level, it's an attractive target for attackers. To minimize the value of this attack surface, AMD uses a special security module called the SMM Supervisor. The SMM Supervisor executes immediately after the SMI interrupt, before control is transferred to SMM code itself, and prevents the SMM from doing things it has no business doing—like modifying hypervisor or OS memory (apart from a small coordinate communication buffer), introducing new SMM code at runtime, or accessing any DMA, I/O, or registers that might compromise the hypervisor or operating system.

Finding a Secured-core PC

A short-so-far list of Secured-core laptops, including entries from Lenovo, Panasonic, Dell, HP, and Microsoft itself, can be found at Microsoft's Secured-core partner page here.

Listing image by Microsoft

Channel Ars Technica