Force firmware code to be measured and attested by Secure Launch on Windows 10
You cannot build something great on a weak foundation – and security is no exception.
Windows is filled with important security features like Hypervisor-protected code integrity (HVCI) and Windows Defender Credential Guard that protect users from advanced hardware and firmware attacks. For these features to properly do their jobs, the platform’s firmware and hardware must be trustworthy and healthy, otherwise the chain of trust that verifies the integrity of the system by validating that every component in the boot process is cryptographically signed by a trusted source could be tampered with maliciously, thereby compromising the security of operating system features that use the firmware and hardware as a fundamental building block.
Without these detection and prevention capabilities, the system won’t be able to detect and block malicious software that runs before the operating system initialized, or during the boot process itself. The malicious software could then grant itself elevated privileges, expand foothold, and persist on the system undetected. In the case of Secured-core PCs, Secure Launch, which leverages the principle of Dynamic Root of Trust for Measurement (DRTM), is a technology that is built-in and enabled by default to greatly increase protection from these sophisticated boot attacks. By leveraging built-in silicon instructions or firmware enclaves, Secure Launch allows a system to freely boot untrusted code initially, but shortly after launches the system into a trusted state by taking control of the CPUs and forcing any untrusted code down a well-known and measured code path to verify it isn’t malicious. This removes early Unified Extensible Firmware Interface (UEFI) code from the trust boundary, meaning systems are better protected against bugs or exploits in UEFI after the Secure Launch, combating an entire class of threat.
For some time, Windows devices have been able to leverage a hardware-based root of trust to help ensure unauthorized firmware or software does not take root before the Windows bootloader launches. This root of trust comes from a UEFI feature called Secure Boot. Secure Boot leverages a Trusted Platform Module (TPM) to take cryptographic measurements of each piece of firmware or software during the early boot process. This technique of measuring these static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).
As there are thousands of PC vendors that produce numerous models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements at startup. There are two techniques that can be used to establish trust here —either maintain a list of known ‘bad’ SRTM measurements (a block list), or a list of known ‘good’ SRTM measurements (an allow list). Each option has a drawback:
- A list of known ‘bad’ SRTM measurements allows a hacker to change just 1 bit in a component to create an entirely new SRTM hash that needs to be listed. This means that the SRTM flow is inherently brittle – a minor change can invalidate the chain of trust.
- A list of known ‘good’ SRTM measurements requires each new BIOS/PC combination measurement to be carefully added, which can be slow. In addition, a bug fix for UEFI code can take a long time to design, build, retest, validate, and redeploy.
As Windows relies on the Hypervisor being secure, trusted, and unmodified to implement numerous security technologies, it is important to protect it from any potential threats that can arise from these issues. System Guard Secure Launch was designed and introduced in Windows 10 version 1809 to address these drawbacks.
Leveraging a Dynamic Root of Trust to measure code integrity
Secure Launch is the first line of defense against exploits and vulnerabilities that try to take advantage of early-boot flaws or bugs. Firmware enclaves and built-in silicon instructions allow systems to boot into a trusted state by forcing untrusted, exploitable code down a specific and measured path before launching into a trusted state.
To achieve a security boundary between the UEFI/ firmware and later OS code, the Windows boot environment is divided into two phases. The first phase runs with UEFI and leverages boot services that are considered untrusted for Secure Launch, and the second phase is the trusted portion that runs without firmware services after the DRTM event. This trusted phase is referred to as the Trusted Computing Base (TCB) launch phase. The Trusted Computing Base includes the minimally scoped firmware enclave and hardware necessary to perform a DRTM event.
The phase with firmware support utilizes the traditional boot binaries Boot Manager and Winload. In this model, Winload no longer prepares the OS and its data structures but acts to prepare enough data in memory for the TCB phase of the boot environment to be able to operate without firmware. This includes loading all unexpanded binaries needed for the OS in memory, as well as staging other firmware or disk sourced information. All data, binaries, and associated storage structures are validated by the TCB before use.
The TCB phase of the boot environment is started by the new TCB Launch application. This binary is measured into the DRTM TPM registers and starts the chain of trust for the launched OS. TCB Launch ensures the security of the system, and then prepares the OS for execution by loading and validating all binaries as well as building data structures for OS launch.
Although all OS data is sourced from disk by Winload and firmware, the TCB phase validates all signatures and code integrity before use. TCB Launch itself is not directly code integrity checked by this phase, but the root of trust measurement provided by the DRTM event is used to attest the authenticity of the binary. For the TCB phase of boot to continue to be secure, the following state must be verified by the DRTM event and TCB Launch:
- Continuous protection against Direct Memory Access (DMA) of TCB Launch and OS memory
- Hardware description of RAM is accurate
- Security critical hardware description must be validated, such as IOMMU structures
- Memory will be cleared upon an unexpected reset from the TCB
After TCB Launch, control of the DRTM environment and associated controls are transferred to the Hypervisor. The Hypervisor is then responsible for managing DMA protections, memory clearing protections, and other DRTM- related state control.
DRTM allows the platform to mitigate real-world attacks that attempt to modify the hypervisor or perform other malicious actions during early boot/hibernate. For example, an S3 boot script exploit that attempts to tamper the hypervisor across suspend/resume would be mitigated by DRTM.
Another common tool used to perform DMA style read/writes over PCIe, frequently leveraged by attackers, is PCILeech. While Kernel DMA protections help ensure that malicious, unauthorised peripherals cannot access memory, even if an attacker does gain a foothold in early-boot, pre-DRTM firmware, the DRTM event insulates the Windows environment from these exploits.
System Management Mode isolation protections can help enforce conditional access
Another dimension of protection that comes with Secured-core PCs is System Management Mode (SMM) protection. System Management Mode (SMM) is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful. If an attacker can exploit SMM, they could attempt to bypass some of the checks in Secure Launch or exploit the runtime operating system. By leveraging new hardware-based supervision and attestation, Secured-core PCs can measure and detect when SMM is trying to access a platform resource (like memory, IO, or certain CPU registers) which violates our policy. This adds an additional layer of hardening to the Secure Launch event and an additional layer of hardening to Secured-core PCs.
SMM execution takes place in the form of System Management Interrupt (SMI) handlers. During the DRTM event, SMIs will be suspended to allow the DRTM event and beginning of the TCB to execute without SMM interference. A system’s SMM isolation is based on an access policy provided by the platform firmware stating what SMM does or does not require access to. This policy will then be enforced on SMM by the silicon vendor specific mechanism, and a copy of this policy will be provided to the boot loader for evaluation. TCB Launch will check that the provided isolation policy being enforced on the system meets the minimum Windows requirements. If the policy is not compliant, say for being able to access OS memory, then TCB Launch may destroy DRTM state and clear OS secrets. TCB Launch will resume SMIs after it has completed its evaluation and has taken any necessary precautions.
Exploits that previously looked to leverage SMM vulnerabilities to read/write these sensitive resources like memory, IO, or certain CPU registers to access secrets, or potentially modify the Hypervisor, are no longer permitted access as part of the policy evaluation. A detected violation upon boot will destroy the DRTM state and prevent access from previously sealed OS secrets and keys. Microsoft has worked with silicon partners and OEMs to ensure that capable Secured-core devices have SMM authored in such a way that meets the SMM policy described, hardening them against this class of attacks. The strength of the ecosystem partnership between Microsoft, silicon vendors and OEMs helps take the security burden of protecting SMM off of security operations teams and recent attacks leveraging SMI handler vulnerabilities are examples of the types of scenarios mitigated by the described SMM protections. When the exploit attempts to leverage a bug in the system management interrupt handler to gain code execution privileges in SMM and modify OS memory, the attempted OS memory access would fall outside our policy boundary and be flagged in the attestation report. The state of DRTM and the SMM protections can be used to help strengthen conditional access strategies in organizations by gating access to sensitive resources based on the health of these hardware and firmware security features.
AMD’s SMM protection component also leverages an SMM supervisor running at a higher processor privilege level (CPL0) to execute SMI handler logic at a lower processor privilege level (CPL3) to isolate and protect resources from SMI handler access and even itself from tampering. Fault handlers are used to protect IO ports & MSRs and enforces CR3 lockdown to protect memory & MMIO components. SMM Supervisor is cryptographically signed and authenticated as well as measured into PCR[17] during SKINIT launch. OEMs include support for SKINIT and AMD’s SMM protections by including the necessary packages in the OS images that are applied to Secured-core PCs.
Getting started with Secure Launch and SMM Protections
Enabling System Guard Secure Launch on a platform may be achieved when the following support is present:
- Intel, AMD, or ARM virtualization extensions
- Trusted Platform Module (TPM) 2.0
- On Intel: TXT support in the BIOS
- On AMD: SKINIT package must be integrated in the Windows system image
- On Qualcomm: Implements DRTM TrustZone application and supports SMC memory protections.
- Kernel DMA Protection
Further configuration information and requirements can be found here. On secured-core PCs, virtualization-based security is supported and hardware-backed security features like System Guard Secure Launch with SMM Protections are enabled by default. Learn more about the line of secured-core PCs available today.
Nazmus Sakib, Alexander Dale, and Chris Fernald
Enterprise and OS Security
READ MORE HERE
