Bypassing Intel Boot Guard
In recent years, there is an increasing attention to the UEFI BIOS security. As a result, there are more advanced technologies created to protect UEFI BIOS from illegal modifications. One of such technologies is Intel Boot Guard (BG) – a hardware-assisted BIOS integrity verification mechanism available since Haswell microarchitecture (2013). So-called «UEFI rootkits killer» this technology is designed to create a trusted boot chain (where a current boot component cryptographically measures/verifies the integrity of the next one) with Root-of-Trust locked into hardware.
How is that possible? Let’s take a look at the figure:
The first boot component (the Root of Trust) in this chain is Intel CPU with the microcode (located inside the CPU boot ROM). It loads into the protected internal CPU memory called Authenticated Code RAM (ACRAM), verifies and executes an Intel-signed BG startup Authenticated Code Module (ACM). The hash of the RSA public key (which is used to verify the signature of the ACM) is hard-coded inside the CPU. This is an Intel-developed part of the technology implementation. Intel BG ACM acts before the execution of BIOS and is responsible for verifying its initial part called the Initial Boot Block (IBB). Usually, the IBB represents the contents of SEC/PEI volumes of UEFI BIOS.
The IBB must contain the final part of the technology implementation, which is developed by BIOS vendor (or the OEM): the code for verifying the remaining BIOS contents (usually the DXE volumes are the remaining part).
Intel BG technology is designed to be permanently configured (the configuration is to be written to one-time-programmable Intel chipset fuses) by the OEM during the manufacturing process. So turning this technology on makes it almost impossible to modify BIOS without knowing the private part of the OEM Root Key (Intel BG configuration includes the hash of the public part). However, the flexibility of the configuration allows setting Intel Boot Guard vulnerable making this technology easy to bypass in some cases.
Such a strong protection mechanism without any bugs?
Technical details describing how the CPU bootcode starts the BG ACM, and how the BG ACM verifies the IBB prior to allowing the CPU to execute it have been reverse-engineered and originally published here:
The referenced research also mentions that a few OEMs produced (and some of them are still producing) computer systems with Intel BG configuration not set properly (with chipset fuses left in an undefined state). This brings an amazing opportunity for an attacker with capabilities to inject program code into BIOS: to turn Intel BG technology on manually making any modifications in BIOS permanent. It only requires configuring Intel BG by programming the chipset fuses (via pure software way) after the modification is done.
Our experimental research revealed that the verification of IBB is not performed upon every boot. For example, if the PC, once powered on and is never shut down, so only the Sleep (S3) mode is used, the verification is done only once every 12 times a device is powered up.
However, the most interesting thing here is a set of a few logical mistakes, made by the BIOS vendor and OEMs enabling an attacker to bypass the technology and make any changes to a huge part of BIOS. Alex Matrosov discovered a few vulnerabilities (not only in Intel BG but also in Intel BIOS Guard):
The following text describes another one that we have discovered.
Killing the killer
To slice and dice it, let’s take a look at the IBB on Gigabyte GA-H170-D3H motherboard with UEFI BIOS version F04. Though it does not have Intel BG enabled, the components of this technology are present: BG ACM, BG key manifests, IBB (SEC/PEI) with a verification routines for DXE. An important notice: the motherboard’s firmware is based on AMI Aptio UEFI BIOS – a very popular product used by many OEMs (for example, Gigabyte, MSI, Asus, Acer, Dell, HP, ASRock). Therefore, the part of code we are going to talk about can be found in any system (produced since 2013) with BIOS based on that codebase (because it is written by AMI).
The present IBB should contain the code for verifying the integrity of the remaining part of BIOS, and it does: the BootGuardPei module (GUID: B41956E1-7CA2-42DB-9562-168389F0F066).
Firstly, the BootGuardPei entrypoint routine checks the compatibility with Intel BG (through the MSRs) and registers the notification callback procedure (Start) for EFI_END_OF_PEI_PHASE_PPI to be called in the end of PEI phase when the operating memory will be available to use.
Therefore, the Start routine is called further, which does the following.
1. Check the booting mode.
It is quite obvious that the DXE code will never be verified while booting from the Sleep (S3) mode. However, that is not the point; this aspect is reasonable enough (to minimize the impact on system performance). Let’s go ahead.
2. Create HOB with only one byte of data (which will represent the result of verification routine).
3. Search the hash container (which holds the hash of DXE code) inside the PEI volumes (by GUID: 389CC6F2-1EA8-467B-AB8A-78E769AE2A15) and verify the first block of DXE pointed by this container.
The hash container format is as follows:
4. After that verify the second block (if it is described by the hash container like the first one).
In case the verification was not successful (for example, because the DXE code was illegally modified), the zero value will be written into HOB. If the DXE were not modified, the positive value (1) would be written. So, the illegal modification of the DXE code will be detected by the BootGuardPei (the hash of the DXE code would not fit one in the hash container).
Good! However, the funny thing is, instead of immediately applying the Intel BG enforcement policy (usually it is an immediate shutdown), this module still allows further execution of BIOS, hence running the modified DXE code. Why?
Inside the DXE volume there is another BG-related module: the BootGuardDxe (GUID: 1DB43EC9-DF5F-4CF5-AAF0-0E85DB4E149A). It is responsible for analyzing the results (previously saved in HOB by BootGuardPei) and shutting down the system if the DXE code does not pass the integrity check (if HOB contains the zero value, as we have already discovered).
Here it is entrypoint routine:
It calls the BootGuardCheck routine, which gains access to the HOB list, then searches for BootGuardPeiHob.
By the way, if BootGuardDxe fails to find it, this routine does nothing but returns an error :) Therefore, any physical memory remote access attack (for example, via IEEE 1394 FireWire) would allow to delete this HOB from the list and allow bypassing the DXE code integrity check.
However, if there was found a HOB (created by BootGuardPei) which holds the zero value, the PrintFailMessageAndResetSystem will be called.
You might have already guessed, that if an attacker manages to delete the BootGuardDxe from the DXE volume, the protection of the DXE part will not work at all (there will be no code to check the results of the verification done by the IBB).
This vulnerability was experimentally confirmed on the Dell XPS 13 9350 system with UEFI BIOS versions 1.4.4 – 1.4.10 that has the turned on Intel Boot Guard technology. As for Dell systems, this vulnerability is not dangerous as long as these systems have another BIOS protection mechanisms applied (PRx, SMM protection, verifying the integrity of UEFI BIOS updates, etc.). Therefore, for these systems the exploitation requires a hardware SPI flash programmer or an RCE/LPE vulnerability in SMM code (allowing to bypass the applied protections), to modify the BIOS.
However, there are still many systems having no additional protection mechanisms turned on which makes this vulnerability more dangerous.
Dell’s vulnerability research team confirmed this security issue on their systems after some checking. We would like to thank them for the fruitful cooperation that made it possible to enhance the security level on Dell systems. The adequate and professional reaction to the reported security issues is still an incredibly rare commodity when it comes to computer system OEMs updating.
After some cooperation with us, Dell has patched out the vulnerability in the following way (found in UEFI BIOS version 1.4.18). The BootGuardPei module, if the verification fails just brings the system into the Recovery mode, so the DXE phase will not be executed.
Of course, we had notified AMI about this issue and learned that they had already mitigated this vulnerability and notified their customers (which are the OEMs) on how to mitigate the same. Also, AMI assured us that the latest AMI BIOS codebase available for their customers does not have this vulnerability.
This allows OEMs to release BIOS updates (fixing the vulnerability) for the end-users.
However, how exactly did they patched this issue? Let’s take a look at the latest Gigabyte GA-H170-D3H motherboard’s BIOS.
You better be kidding me…
That is how:
In case of unsuccessful verification, they put the positive value inside the BootGuardPei HOB, allowing to bypass Intel BG protection for the DXE volumes without the need to delete the BootGuardDxe module because it resets the system only if the HOB stores the zero!
No protection mechanism works – no troubles with fixing bugs in it!