We propose to go down to the low level again and talk about the security of firmware x86-compatible computer platforms. This time, the main ingredient of the research is Intel Boot Guard (not to be confused with Intel BIOS Guard!) - a hardware-supported BIOS trusted boot technology that a computer system vendor can permanently enable or disable at the production stage. Well, we already know the research recipe: thinly cut the implementation of this technology by reverse engineering, describe its architecture, filling it with undocumented details, season it with attack vectors to taste and mix it up. Let's add fire with a story about how a cloned bug in the production of several vendors for years allows a potential attacker to use this technology to create a hidden rootkit that cannot be removed (even by a programmer) in the system.
By the way, the article is based on the reports “On Guard for Rootkits: Intel BootGuard” from the conference and 29th meeting (both presentations ).
Firmware for a computer platform with Intel 64 architecture
To begin with, let's answer the question: what is the firmware of a modern computer platform with the Intel 64 architecture? Of course, UEFI BIOS. But this answer will not be accurate. Let's take a look at the figure, which shows the desktop (laptop) version of this architecture.
The basis is the link:
- Processor (CPU, Central Processing Unit), which, in addition to the main cores, has a built-in graphics core (not in all models) and a memory controller (IMC, Integrated Memory Controller);
- Chipset (PCH, Platform Controller Hub), containing various controllers for interacting with peripheral devices and managing subsystems. Among them is the notorious Intel Management Engine (ME), which also has a firmware (Intel ME firmware).
Laptops, in addition to the above, require an integrated controller (ACPI EC, Advanced Control and Power Interface Embedded Controller), which is responsible for the operation of the power subsystem, touchpad, keyboard, Fn keys (screen brightness, sound volume, keyboard backlight, etc. ) and more. And he also has his own firmware.
So, the combination of the above firmware is the firmware of the computer platform (system firmware), which is stored on a common SPI flash memory. So that users of this memory do not get confused where someone lies, the contents of this memory are divided into the following regions (as shown in the figure):
- UEFI BIOS;
- ACPI EC firmware (a separate region appeared with the Skylake processor microarchitecture (2015), but in-the-wild we have not yet seen examples of its use, so the embedded controller firmware is still part of the UEFI BIOS);
- Intel ME firmware;
- configuration (MAC address, etc.) of the built-in GbE (Gigabit Ethernet) network adapter;
- flash descriptors - the main region of flash memory, which contains pointers to other regions, as well as permissions to access them.
Differentiation of access to regions (in accordance with the specified permissions) is handled by the SPI bus master - the SPI controller built into the chipset, through which this memory is accessed. If the permissions are set to the values recommended (for security reasons) by Intel, then each SPI flash user has full access (read / write) only to his region. The rest are either read-only or inaccessible. Known fact: on many systems, the CPU has full access to the UEFI BIOS and GbE, read access only to flash descriptors, and no access to the Intel ME region at all. Why many and not all? What is recommended is optional. We will tell you more later in the article.
Mechanisms for protecting the firmware of a computer platform from modification
Obviously, the firmware of a computer platform should be protected from possible compromise, which would allow a potential attacker to gain a foothold in it (survive OS updates / reinstallations), execute their code in the most privileged modes, etc. And delimiting access to SPI flash memory regions, of course, is not enough. Therefore, various mechanisms specific to each execution environment are used to protect the firmware from modifications.
So, the Intel ME firmware is signed for integrity and authenticity control, and is checked by the ME controller each time it is loaded into the ME UMA memory. This verification process has already been discussed by us in one of the dedicated to the Intel ME subsystem.
And ACPI EC firmware, as a rule, is checked only for integrity. However, due to the fact that this binary is included in the UEFI BIOS, it is almost always subject to the same protection mechanisms that the UEFI BIOS uses. Let's talk about them.
These mechanisms can be divided into two categories.
Write protection to UEFI BIOS region
- Physical protection of the contents of the SPI flash memory with a write-protect jumper;
- Protection of the projection of the UEFI BIOS region in the CPU address space using the chipset's PRx registers;
- Blocking attempts to write to the UEFI BIOS region by generating and processing the corresponding SMI interrupt by setting the BIOS_WE / BLE and SMM_BWP bits in the chipset registers;
- A more advanced version of this protection is Intel BIOS Guard (PFAT).
In addition to these mechanisms, vendors can develop and implement their own security measures (for example, signing capsules with UEFI BIOS updates).
It is important to note that on a specific system (depending on the vendor), not all of the above protection mechanisms may be applied, they may not be applied at all, or they may be implemented in a vulnerable way. You can read more about these mechanisms and the situation with their implementation in . For those interested, we recommend that you read the entire series of articles on UEFI BIOS security from .
UEFI BIOS Authentication Verification
When we talk about trusted boot technologies, the first thing that comes to mind is Secure Boot. However, architecturally, it is designed to authenticate components external to the UEFI BIOS (drivers, loaders, etc.), and not the firmware itself.
Therefore, Intel in SoCs with the Bay Trail microarchitecture (2012) implemented a hardware non-switchable Secure Boot (Verified Boot), which has nothing to do with the aforementioned Secure Boot technology. Later (2013), this mechanism was improved and, under the name Intel Boot Guard, was released for desktops with the Haswell microarchitecture.
Before describing Intel Boot Guard, let's look at runtimes in the Intel 64 architecture, which, in combination, are the roots of trust for this trusted boot technology.
Intel CPU
Cap suggests that the processor is the main execution environment in the Intel 64 architecture. Why is it also the root of trust? It turns out that it is the possession of the following elements that makes it so:
- Microcode ROM is a non-volatile, non-rewritable memory for storing microcode. It is believed that microcode is the implementation of the processor instruction system on the simplest instructions. Happens in microcode too . So in the BIOS you can find binaries with microcode updates (they are superimposed at boot time, because the ROM cannot be overwritten). The content of these binaries is encrypted, which greatly complicates analysis (therefore, the specific content of the microcode is known only to those who develop it), and signed to control the integrity and authenticity;
- AES key to decrypt the contents of microcode updates;
- a hash of the RSA public key that verifies the signature of microcode updates;
- RSA public key hash, which checks the signature of Intel-developed ACM (Authenticated Code Module) code modules, which the CPU can run before the BIOS starts (hello microcode) or during its operation, when some events occur.
Intel ME
This subsystem in our blog was devoted to . Recall that this executable environment is based on the microcontroller built into the chipset and is the most hidden and privileged in the system.
Despite the stealth, Intel ME is also the root of trust, because it has:
- ME ROM - non-volatile, non-rewritable memory (no update method provided), containing the start code, as well as the SHA256 hash of the RSA public key, which checks the signature of the Intel ME firmware;
- AES key for storing secret information;
- access to a set of fuses (FPFs, Field Programmable Fuses) integrated into the chipset for permanent storage of some information, including information specified by the computer system vendor.
Intel Boot Guard 1.x
Small disclaimer. The version numbers of Intel Boot Guard technology that we use in this article are arbitrary and may not have anything to do with the numbering used in internal Intel documentation. In addition, the information about the implementation of this technology given here was obtained during reverse engineering, and may contain inaccuracies compared to the specification for Intel Boot Guard, which is unlikely to ever be published.
So, Intel Boot Guard (BG) is a hardware-supported UEFI BIOS authentication technology. Judging by its small description in the book [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot], it works as a trusted boot chain. And the first link in it is the boot code (microcode) inside the CPU, which is triggered by the RESET event (not to be confused with the RESET vector in the BIOS!). The CPU finds a code module (Intel BG startup ACM) developed and signed by Intel on the SPI flash memory, loads it into its cache, verifies it (it was already noted above that the CPU has a public key hash that verifies the ACM signature) and starts.
This code module is responsible for verifying a small starting part of the UEFI BIOS - Initial Boot Block (IBB), which, in turn, contains the functionality for verifying the main part of the UEFI BIOS. Thus, Intel BG allows you to verify the authenticity of the BIOS before booting the OS (which can be performed under the supervision of Secure Boot technology).
Intel BG technology provides two modes of operation (and one does not interfere with the other, i.e. both modes can be enabled on the system, and both can be disabled).
Measured Boot
In Measured Boot (MB) mode, each boot component (starting with the CPU boot ROM) "measures" the next one using the capabilities of the Trusted Platform Module (TPM). For those who don't know, let me explain.
TPM has PCRs (Platform Configuration Registers), which record the result of the hashing operation according to the formula:
Those. the current PCR value depends on the previous one, and these registers are reset only when the system is RESET.
Thus, in MB mode, at some point in time, PCRs reflect a unique (within the capabilities of the hash operation) identifier of the code or data that was "measured". The PCR values can be used in the encryption of some data (TPM_Seal) operation. After that, their decryption (TPM_Unseal) will be possible only if the PCR values have not changed as a result of loading (i.e., not a single “measured” component has been modified).
Verified Boot
The scariest thing for those who like to modify the UEFI BIOS is the Verified Boot (VB) mode, in which each boot component cryptographically verifies the integrity and authenticity of the next one. And in case of a verification error, (one of the following) occurs:
- shutdown by timeout from 1 minute to 30 minutes (so that the user has time to understand why his computer does not boot, and, if possible, would try to restore the BIOS);
- immediate shutdown (so that the user does not have time to understand and, moreover, to do);
- continuation of work with a straight face (the case when there is no time for safety, because there are more important things to do).
The choice of action depends on the specified Intel BG configuration (namely, on the so-called enforcement policy), which is permanently recorded by the computer platform vendor in a specially designed storage - chipset fuses (FPFs). We will dwell on this point in more detail later.
In addition to the configuration, the vendor generates two RSA 2048 keys and creates two data structures (shown in the figure):
- The vendor root key manifest (KEYM, OEM Root Key Manifest), which puts the SVN (Security Version Number) of this manifest, the SHA256 hash of the public key of the next manifest, the RSA public key (i.e. the public part of the vendor root key) to verify the signature of this manifest and the signature itself;
- The IBB Manifest (IBBM, Initial Boot Block Manifest), which puts the SVN of this manifest, the SHA256 hash of the IBB, the public key for verifying the signature of this manifest, and the signature itself.
The SHA256 hash of the OEM Root Key is permanently written to chipset fuses (FPFs), just like the Intel BG configuration. If the Intel BG configuration provides for the inclusion of this technology, then from now on on this system only the owner of the private part of the OEM Root Key can update the BIOS (i.e. be able to recalculate these manifests), i.e. vendor.
When you look at the picture, doubts immediately arise about the need for such a long verification chain - you could have used one manifest. Why complicate?
In fact, Intel thus provides the vendor with the opportunity to use different IBB keys for different product lines and one as the root. If the private part of the IBB key (which signs the second manifest) is leaked, the incident will affect only one product line and only until the vendor generates a new pair and enables the recalculated manifests in the next BIOS update.
But if the root key is compromised (with which the first manifest is signed), it will not be possible to replace it, the revocation procedure is not provided. the hash of the public part of this key is programmed into FPFs once and for all.
Intel Boot Guard Configuration
Now let's take a closer look at the Intel BG configuration and the process of its creation. If you look at the corresponding tab in the GUI of the Flash Image Tool from the Intel System Tool Kit (STK), you will notice that the Intel BG configuration includes a hash of the public part of the vendor root key, a couple of obscure values, and so on. Intel BG profile.
The structure of this profile:
typedef struct BG_PROFILE
{
unsigned long Force_Boot_Guard_ACM : 1;
unsigned long Verified_Boot : 1;
unsigned long Measured_Boot : 1;
unsigned long Protect_BIOS_Environment : 1;
unsigned long Enforcement_Policy : 2; // 00b – do nothing
// 01b – shutdown with timeout
// 11b – immediate shutdown
unsigned long : 26;
};In general, the Intel BG configuration is a very flexible entity. Consider, for example, the Force_Boot_Guard_ACM flag. When it is cleared, if the BG startup ACM module on the SPI flash is not found, no trusted boot will occur. It will be untrustworthy.
We already wrote above that the enforcement policy for the VB mode can be configured so that if verification fails, again, an untrusted download will occur.
Leave things like this up to the vendors...
The GUI of the utility provides the following "ready-made" profiles:
room
Mode
Description
0
No_FVME
Intel BG technology disabled
1
VE
VB mode enabled, shutdown by timeout
2
VME
both modes are enabled (VB and MB), shutdown by timeout
3
VM
both modes are enabled, without turning off the system
4
FVE
VB mode enabled, immediate shutdown
5
FVME
both modes enabled, immediate shutdown
As already mentioned, the Intel BG configuration must be written once and for all by the system vendor into chipset fuses (FPFs) - a small (according to unverified information, only 256 bytes) hardware information storage inside the chipset, which can be programmed outside of Intel's production facilities (so that's why Field Programmable fuses).
It is great for storing configuration because:
- has a one-time-programmable data storage area (just where the Intel BG configuration is written);
- only Intel ME can read and program it.
So, in order to set the configuration for Intel BG technology on a specific system, the vendor does the following during production:
- Using the Flash Image Tool (from Intel STK), creates a firmware image with a given Intel BG configuration as variables inside the Intel ME region (the so-called temporary mirror for FPFs);
- Using the Flash Programming Tool (from Intel STK), writes this image to the SPI flash memory of the system and closes the so-called. manufacturing mode (in this case, the corresponding command is sent to Intel ME).
As a result of these operations, Intel ME will commit to FPFs the given values from the mirror for FPFs in the ME region, set the permissions in SPI flash descriptors to the values recommended by Intel (described at the beginning of the article) and perform a system RESET.
Intel Boot Guard Implementation Analysis
In order to analyze the implementation of this technology on a specific example, we checked the following systems for traces of Intel BG technology:
System
Note
Gigabyte GA-H170-D3H
Skylake, there is support
Gigabyte GA-Q170-D3H
Skylake, there is support
Gigabyte GA-B150-HD3
Skylake, there is support
MSI H170A Gaming Pro
Skylake, no support
Lenovo ThinkPad 460
Skylake, support available, technology enabled
Lenovo Yoga Pro 2
Haswell, no support
Lenovo U330p
Haswell, no support
"Support" means the presence of the Intel BG startup ACM module, the manifests mentioned above and the corresponding code in the BIOS, i.e. implementations for analysis.
As an example, let's take the one downloaded from the office. vendor site image of SPI flash memory for Gigabyte GA-H170-D3H (version F4).
Intel CPU boot ROM
First of all, let's talk about the actions of the processor if Intel BG technology is enabled.
It was not possible to find samples of the decrypted microcode, therefore, how the actions described below are implemented (in microcode or in hardware) is an open question. Nevertheless, the fact that modern Intel processors "can" perform these actions is a fact.
After exiting the RESET state, the processor (in whose address space the contents of the flash memory is already mapped) finds the FIT (Firmware Interface Table). Finding it is easy, the pointer to it is written at the address FFFF FFC0h.
In this example, this address contains the value FFD6 9500h. Turning to this address, the processor sees the FIT table, the contents of which are divided into records. The first entry is the heading of the following structure:
typedef struct FIT_HEADER
{
char Tag[8]; // ‘_FIT_ ’
unsigned long NumEntries; // including FIT header entry
unsigned short Version; // 1.0
unsigned char EntryType; // 0
unsigned char Checksum;
};
For some unknown reason, the checksum is not always calculated in these tables (the field is left null).
The remaining entries point to various binaries that need to be parsed / executed before the BIOS is executed, i.e. before switching to the legacy RESET vector (FFFF FFF0h). The structure of each such entry is as follows:
typedef struct FIT_ENTRY
{
unsigned long BaseAddress;
unsigned long : 32;
unsigned long Size;
unsigned short Version; // 1.0
unsigned char EntryType;
unsigned char Checksum;
};
The EntryType field indicates the type of block this entry points to. We know of several types:
enum FIT_ENTRY_TYPES
{
FIT_HEADER = 0,
MICROCODE_UPDATE,
BG_ACM,
BIOS_INIT = 7,
TPM_POLICY,
BIOS_POLICY,
TXT_POLICY,
BG_KEYM,
BG_IBBM
};Now it is obvious that one of the entries points to the location of the Intel BG startup ACM binary. The header structure of this binary is typical for code modules developed by Intel (ACMs, microcode updates, Intel ME code sections, ...).
typedef struct BG_ACM_HEADER
{
unsigned short ModuleType; // 2
unsigned short ModuleSubType; // 3
unsigned long HeaderLength; // in dwords
unsigned long : 32;
unsigned long : 32;
unsigned long ModuleVendor; // 8086h
unsigned long Date; // in BCD format
unsigned long TotalSize; // in dwords
unsigned long unknown1[6];
unsigned long EntryPoint;
unsigned long unknown2[16];
unsigned long RsaKeySize; // in dwords
unsigned long ScratchSize; // in dwords
unsigned char RsaPubMod[256];
unsigned long RsaPubExp;
unsigned char RsaSig[256];
};
The processor loads this binary into its cache, verifies and launches.
Intel BG startup ACM
As a result of the analysis of the work of this ACM, it became clear that it does the following:
- receives from Intel ME the Intel BG configuration written to the chipset fuses (FPFs);
- finds KEYM and IBBM manifests, verifies them.
To find these manifests, ACM also uses the FIT table, which has two types of entries to point to these structures (see FIT_ENTRY_TYPES above).
Let's take a closer look at the manifestos. In the structure of the first manifest, we see a few obscure constants, a hash of the public key from the second manifest, and a public OEM Root Key signed as a nested structure:
typedef struct KEY_MANIFEST
{
char Tag[8]; // ‘__KEYM__’
unsigned char : 8; // 10h
unsigned char : 8; // 10h
unsigned char : 8; // 0
unsigned char : 8; // 1
unsigned short : 16; // 0Bh
unsigned short : 16; // 20h == hash size?
unsigned char IbbmKeyHash[32]; // SHA256 of an IBBM public key
BG_RSA_ENTRY OemRootKey;
};
typedef struct BG_RSA_ENTRY
{
unsigned char : 8; // 10h
unsigned short : 16; // 1
unsigned char : 8; // 10h
unsigned short RsaPubKeySize; // 800h
unsigned long RsaPubExp;
unsigned char RsaPubKey[256];
unsigned short : 16; // 14
unsigned char : 8; // 10h
unsigned short RsaSigSize; // 800h
unsigned short : 16; // 0Bh
unsigned char RsaSig[256];
};
To verify the public key of the OEM Root Key, we recall that the SHA256 hash from the fuses is used, which at this moment has already been received from Intel ME.
Let's move on to the second manifesto. It consists of three structures:
typedef struct IBB_MANIFEST
{
ACBP Acbp; // Boot policies
IBBS Ibbs; // IBB description
IBB_DESCRIPTORS[];
PMSG Pmsg; // IBBM signature
};The first one contains some constants:
typedef struct ACBP
{
char Tag[8]; // ‘__ACBP__’
unsigned char : 8; // 10h
unsigned char : 8; // 1
unsigned char : 8; // 10h
unsigned char : 8; // 0
unsigned short : 16; // x & F0h = 0
unsigned short : 16; // 0 < x <= 400h
};The second contains the SHA256 hash of the IBB and the number of descriptors that describe the contents of the IBB (i.e. what the hash is calculated from):
typedef struct IBBS
{
char Tag[8]; // ‘__IBBS__’
unsigned char : 8; // 10h
unsigned char : 8; // 0
unsigned char : 8; // 0
unsigned char : 8; // x <= 0Fh
unsigned long : 32; // x & FFFFFFF8h = 0
unsigned long Unknown[20];
unsigned short : 16; // 0Bh
unsigned short : 16; // 20h == hash size ?
unsigned char IbbHash[32]; // SHA256 of an IBB
unsigned char NumIbbDescriptors;
};The IBB descriptors follow this structure, one after the other. Their content has the following format:
typedef struct IBB_DESCRIPTOR
{
unsigned long : 32;
unsigned long BaseAddress;
unsigned long Size;
};It's simple: each descriptor contains the address/size of an IBB chunk. Thus, the concatenation of the blocks pointed to by these descriptors (in the order of the descriptors themselves) is IBB. And, as a rule, IBB is a combination of all modules of the SEC and PEI phases.
The second manifest ends with a structure containing the IBB public key (verified by the SHA256 hash from the first manifest) and the signature of this manifest:
typedef struct PMSG
{
char Tag[8]; // ‘__PMSG__’
unsigned char : 8; // 10h
BG_RSA_ENTRY IbbKey;
};
So, even before the start of the UEFI BIOS execution, the processor will launch ACM, which will verify the authenticity of the contents of sections with the SEC and PEI phase code. Next, the processor exits the ACM, moves along the RESET vector, and starts executing the BIOS.
The PEI verified partition must contain a module that will check the rest of the BIOS (DXE code). This module is already being developed by IBV (Independent BIOS Vendor) or the system vendor itself. Because Only Lenovo and Gigabyte systems turned out to be at our disposal and having Intel BG support, let's consider the code extracted from these systems.
UEFI BIOS module LenovoVerifiedBootPei
In the case of Lenovo, it turned out to be the LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} module, developed by Lenovo.
Its job is to look up (by GUID) a hash table for the DXE and verify the DXE.
if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
if (!FindHashTable())
return EFI_NOT_FOUND;
if (!VerifyDxe())
return EFI_SECURITY_VIOLATION;
}Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:
typedef struct HASH_TABLE
{
char Tag[8]; // ‘$HASHTBL’
unsigned long NumDxeDescriptors;
DXE_DESCRIPTORS[];
};typedef struct DXE_DESCRIPTOR
{
unsigned char BlockHash[32]; // SHA256
unsigned long Offset;
unsigned long Size;
};UEFI BIOS module BootGuardPei
In the case of Gigabyte, it turned out to be the BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} module, developed by AMI, and therefore present in any AMI BIOS with Intel BG support.
Its algorithm of operation is somewhat different, however, it boils down to the same:
int bootMode = EFI_PEI_SERVICES->GetBootMode();
if (bootMode != BOOT_ON_S3_RESUME &&
bootMode != BOOT_ON_FLASH_UPDATE &&
bootMode != BOOT_IN_RECOVERY_MODE)
{
HOB* h = CreateHob();
if (!FindHashTable())
return EFI_NOT_FOUND;
WriteHob(&h, VerifyDxe());
return h;
}The hash table {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} it looks up has the following format:
typedef HASH_TABLE DXE_DESCRIPTORS[];
typedef struct DXE_DESCRIPTOR
{
unsigned char BlockHash[32]; // SHA256
unsigned long BaseAddress;
unsigned long Size;
};Intel Boot Guard 2.x
Let's briefly talk about another implementation of Intel Boot Guard, which was found in a newer system based on Intel SoC with Apollo Lake microarchitecture - ASRock J4205-IT.
Although this version will only be used in SoCs (new systems with Kaby Lake processor microarchitecture continue to use Intel Boot Guard 1.x), it is of great interest in exploring a new architecture option for platforms based on Intel SoCs, which has seen tangible changes, for example :
- BIOS and Intel ME regions (or rather Intel TXE, according to Intel SoC terminology) are now one IFWI region;
- although Intel BG was enabled on the platform, structures such as FIT, KEYM, IBBM were not found in flash memory;
- in addition to TXE and ISH cores (x86), a third core (again ARC, by the way) was added to the chipset - PMC (Power Management Controller), associated with ensuring the operability of the power subsystem and performance monitoring.
The content of the new IFWI region is a set of the following modules:
Bias
First name
Description
0000 2000h
SMIP
some platform configuration, signed by the vendor
0000 6000h
RBEP
Intel TXE firmware code section, x86, signed by Intel
0001 0000h
PMCP
firmware code section Intel PMC, ARC, signed by Intel
0002 0000h
FTPR
Intel TXE firmware code section, x86, signed by Intel
0007B000h
UCOD
CPU microcode updates signed by Intel
0008 0000h
IBBP
UEFI BIOS, SEC/PEI phases, x86, vendor signed
0021 8000h
ISHC
code section of the Intel ISH firmware, x86, signed by the vendor
0025 8000h
FTP
Intel TXE firmware code section, x86, signed by Intel
0036 1000h
IUNP
unknown
0038 1000h
OBBP
UEFI BIOS, DXE phase, x86, unsigned
During the analysis of the TXE firmware, it became obvious that after RESET, TXE keeps the processor in this state until it prepares the basic contents of the address space for the CPU (FIT, ACM, RESET vector ...). Moreover, TXE places this data in its SRAM, after which it temporarily provides the processor with access there and “releases” it from RESET.
On guard of rootkits
Well, now let's move on to the "hot". We once discovered that on many systems SPI flash descriptors have permissions to access regions of SPI flash memory so that all users of this memory can both write and read any region. Those. no way.
After checking with the MEinfo utility (from Intel STK), we saw that the manufacturing mode on these systems was not closed, therefore, the chipset fuses (FPFs) were left in an indeterminate state. Yes, Intel BG is neither enabled nor disabled in such cases.
We are talking about the following systems (regarding Intel BG and what will be described later in the article, we will talk about systems with Haswell processor microarchitecture and higher):
- all Gigabyte products;
- all MSI products;
- 21 Lenovo laptop models and 4 Lenovo server models.
Of course, we reported the find to these vendors, as well as to Intel.
Adequate response followed only from Lenovowho acknowledged the problem and .
Gigabyte It seems that they accepted information about the vulnerability, but did not comment in any way.
Communication with MSI completely stalled at our request to send our public PGP key (in order to send them an encrypted security advisory). They stated that they "are a hardware manufacturer and do not manufacture PGP keys."
But more to the point. Since the fuses are left in an undefined state, the user (or attacker) can program them himself (the most difficult is ). This requires the following steps.
1. Boot into Windows OS (in general, the steps described below can also be done from under Linux, if you develop an analogue of Intel STK for the desired OS). Using the MEinfo utility, make sure that the fuses on this system are not programmed.
2. Read the contents of flash memory using the Flash Programming Tool.
3. Open the read image using any UEFI BIOS editing tool, make the necessary changes (implement a rootkit, for example), create / edit the existing KEYM and IBBM structures in the ME region.
The public part of the RSA key is highlighted in the picture, the hash of which will be programmed into the chipset fuses along with the rest of the Intel BG configuration.
4. Using the Flash Image Tool, build a new firmware image (by setting the Intel BG configuration).
5. Write a new image to flash using the Flash Programming Tool, verify using MEinfo that the ME region now contains the Intel BG configuration.
6. Use the Flash Programming Tool to close the manufacturing mode.
7. The system will reboot, after which, using MEinfo, you can verify that the FPFs are now programmed.
These actions forever enable Intel BG on this system. It will be impossible to undo the action, which means:
- only the owner of the private part of the root key (i.e. the one who enabled Intel BG) will be able to update the UEFI BIOS on this system;
- if you return the original firmware to this system, for example, using a programmer, it will not even turn on (a consequence of enforcement policy in the event of a verification error);
- to get rid of such a UEFI BIOS, you need to replace the chipset with programmed FPFs with a “clean” one (i.e. resolder the chipset if you have access to an infrared soldering station at the price of a car, or just replace the motherboard).
To understand what such a rootkit can do, you need to evaluate what makes it possible to execute your code in a UEFI BIOS environment. Say, in the most privileged mode of the processor - SMM. Such a rootkit may have the following properties:
- be executed in parallel with the OS (you can configure processing by generating an SMI interrupt, which will be triggered by a timer);
- have all the advantages of being in SMM mode (full access to the contents of RAM and hardware resources, secrecy from the OS);
- The rootkit code can be encrypted and decrypted when launched in SMM mode. Any data available only in SMM mode can be used as an encryption key. For example, a hash from a set of addresses in SMRAM. To get this key, you will need to climb into the SMM. And this can be done in two ways. Find the RCE in the SMM code and exploit it, or add your own SMM module to the BIOS, which is impossible, since we enabled Boot Guard.
Thus, this vulnerability allows an attacker to:
- create a hidden, unremovable rootkit of unknown purpose in the system;
- execute your code on one of the chipset cores inside the Intel SoC, namely, on the Intel ISH (take a closer look at the picture).
Although the capabilities of the Intel ISH subsystem have not yet been explored, it seems to be an interesting attack vector against Intel ME.
Conclusions
- The study provided a technical description of how Intel Boot Guard technology works. Minus a couple of secrets in Intel's security through obscurity model.
- An attack scenario is presented that allows creating an unremovable rootkit in the system.
- We have seen that modern Intel processors are able to execute a lot of proprietary code even before the BIOS starts.
- Platforms with Intel 64 architecture are becoming less and less suitable for running free software: hardware verification, an increasing number of proprietary technologies and subsystems (three cores in the SoC chipset: x86 ME, x86 ISH and ARC PMC).
mitigation
Vendors that intentionally leave manufacturing mode open should definitely close it. So far, they are only closing their eyes and the new Kaby Lake systems show this.
Users can disable Intel BG on their systems (which are affected by the described vulnerability) by running the Flash Programming Tool with the -closemnf option. First, you should make sure (using MEinfo) that the configuration of Intel BG in the ME region provides for exactly turning off this technology after programming in FPFs.
Source: habr.com