flothrone April 18, 2017 at 09:27

Schrödinger Trusted Boot. Intel Boot Guard

We propose to go down to the low level again and talk about the security of the firmware of x86-compatible computer platforms. This time, the main ingredient of the study is the Intel Boot Guard (not to be confused with the Intel BIOS Guard!) - a hardware-supported technology for trusted BIOS boot, which the computer system vendor can permanently turn on or off at the production stage. Well, we already know the recipe for the study: thinly cut the implementation of this technology by reverse engineering, describe its architecture, filling it with undocumented details, season it to taste with attack vectors and mix it. Let’s add fire to the story of how, over the years, a cloned mistake in the production of several vendors allows a potential attacker to use this technology to create a hidden rootkit in a system that cannot be deleted (even by a programmer).

By the way, the article is based on the reports “Guardian of rootkits: Intel BootGuard” from the ZeroNights 2016 conference and the 29th meeting of DefCon Russia (both presentations are here ).

Firmware upgrade for Intel 64 architecture platform

First, let's answer the question: what is the firmware of a modern computer platform with Intel 64 architecture? Of course, the UEFI BIOS. But such an answer will not be accurate. Let's take a look at the drawing, which depicts a desktop (laptop) version of this architecture.

The basis is a bunch:

A processor (CPU, Central Processing Unit), in which, in addition to the main cores, a graphics core is built in (not on all models) and a memory controller (IMC, Integrated Memory Controller) is introduced;
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 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 other things. 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 shared SPI flash memory. So that users of this memory do not get confused where whose 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 from the Skylake processor microarchitecture (2015), but in-the-wild we have not yet seen examples of its use, so the firmware of the integrated controller is still part of the UEFI BIOS);
Intel ME firmware;
configuration (MAC address, etc.) of the built-in GbE network adapter (Gigabit Ethernet);
flash descriptors (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 given permissions) is handled by the SPI master bus - an SPI controller built into the chipset through which this memory is accessed. If the permissions are set to the recommended values (for security reasons) by Intel, then each user of the SPI flash memory has full access (read / write) only to his region. And 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 there is no access to the Intel ME region at all. Why at many, but not at all? What is recommended is optional. We will tell in more detail later in the article.

Mechanisms for protecting the firmware of a computer platform from modification

Obviously, the firmware of the computer platform should be protected from possible compromise, which would allow a potential attacker to gain a foothold in it (to survive updates / reinstallations of the OS), execute its code in the most privileged modes, etc. And delimiting access to the SPI regions of flash memory, of course, is not enough. Therefore, to protect the firmware from modifications, various mechanisms are used that are specific to each execution environment.

So, Intel ME firmware is signed for integrity and authenticity control, and is checked by the ME-controller each time it is loaded into ME UMA memory. This verification process was already considered by us in one of the articles devoted to the Intel ME subsystem.

And ACPI EC firmware, as a rule, is checked only for integrity. However, due to the fact that this binar is included in the UEFI BIOS, it is almost always subject to the same protection mechanisms that the UEFI BIOS uses. We’ll talk about them.

These mechanisms can be divided into two categories.

Write protection to the UEFI BIOS region

Physical protection of the contents of the SPI flash write-protect jumper;
Protection of the projection of the UEFI BIOS region in the address space of the CPU using PRx registers of the chipset;
Blocking attempts to write to the UEFI BIOS 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 the Intel BIOS Guard (PFAT).

In addition to these mechanisms, vendors can develop and apply 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, may not be applied at all, but may be vulnerablely implemented. You can read more about these mechanisms and the situation with their implementation in this article . For those who are interested, we recommend that you read the entire series of CodeRush UEFI BIOS security articles .

UEFI BIOS Authentication

When we talk about trusted boot technologies, the first thing that comes to mind is Secure Boot. However, it is architecturally designed to authenticate external (with respect to the UEFI BIOS) components (drivers, boot loaders, etc.), and not the firmware itself.

Therefore, Intel in SoCs with Bay Trail microarchitecture (2012) implemented a hardware non-disconnectable Secure Boot (Verified Boot), which has nothing to do with the aforementioned Secure Boot technology. Later (2013), this mechanism was improved and released under the name Intel Boot Guard for desktops with Haswell microarchitecture.

Before describing the Intel Boot Guard, we’ll deal with Intel 64 runtime environments, 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 the root of trust? It turns out that possessing the following elements makes it that way:

Microcode ROM - non-volatile, non-rewritable memory for storing microcode. It is believed that the microcode is the implementation of the processor instruction system on the simplest instructions. The microcode also occur bugs . So in the BIOS you can find binaries with microcode updates (overlap during boot, because ROM cannot be overwritten). The contents of these binaries are encrypted, which greatly complicates the analysis (therefore, the specific content of the microcode is known only to those who develop it) and signed, to control integrity and authenticity;
AES key for decrypting the contents of microcode updates;
RSA public key hash, which checks the signature of microcode updates;
RSA public key hash, which verifies the signature of the Intel-developed ACM (Authenticated Code Module) code modules that the CPU can run before the BIOS starts executing (hi microcode) or during its operation, if some events occur.

Intel ME

This subsystem in our blog has been devoted already two articles . Recall that this executable environment is based on a microcontroller built into the chipset and is the most hidden and privileged in the system.

Despite the secrecy, Intel ME is also the root of confidence, because it has:

ME ROM - non-volatile, non-rewritable memory (no update method is 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 to store sensitive information;
access to the set of fuses integrated into the chipset (FPFs, Field Programmable Fuses) for permanent storage of some information, including the one specified by the vendor of the computer system.

Intel Boot Guard 1.x

A small disclaimer. The version numbers of Intel Boot Guard technology that we are operating in this article are conditional, and may have nothing to do with the numbering used in Intel's internal documentation. In addition, the information on the implementation of this technology presented 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 her brief 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 on the SPI flash memory a code module developed and signed by Intel (Intel BG startup ACM), loads it into its cache, verifies (it has already been noted that the CPU has a public key hash that verifies the ACM signature) and starts it.

This code module is responsible for verifying the small start-up part of the UEFI BIOS - the Initial Boot Block (IBB), which, in turn, contains 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 run 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 turned on on the system, or both can be turned off).

Measured boot

In Measured Boot (MB) mode, each bootable component (starting with the CPU boot ROM) “measures” the next one using the capabilities of TPM (Trusted Platform Module). For those who are not in the know, let’s explain.

TPMs have PCRs (Platform Configuration Registers), in which the result of the hash operation is written according to the formula:

$display$

Those. the current PCR value depends on the previous one, while these registers are reset to zero only with RESET systems.

Thus, in the MB mode, at some point in time, the PCRs reflect a unique (within the limits of the hashing operation) identifier of the code or data that was “measured”. PCR values can be used in the encryption operation of some data (TPM_Seal). After that, their decryption (TPM_Unseal) will be possible only if the PCR values have not changed as a result of loading (ie, no “measured” component has been modified).

Verified boot

The worst thing for fans to modify the UEFI BIOS is the Verified Boot (VB) mode, in which each boot component cryptographically checks the integrity and authenticity of the next. And in case of 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 the computer is not loading, and, if possible, would try to restore the BIOS);
immediate shutdown (so that the user does not have time to understand and, moreover, do);
continued work with a straight face (the case when it is not up to safety, because there are more important things to do).

The choice of action depends on the configured Intel BG configuration (namely, the so-called enforcement policy), which the vendor of the computer platform permanently writes to the 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 Security Version Number (SVN) of this manifest, 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 signature itself;
The IBB manifest (IBBM, Initial Boot Block Manifest), which puts the SVN of this manifest, the SHA256 IBB hash, the public key to verify the signature of this manifest and the signature itself.

The SHA256 public key hash of the OEM Root Key is permanently written to the chipset fuses (FPFs), like the Intel BG configuration. If the Intel BG configuration provides for the inclusion of this technology, then from this moment on the system to update the BIOS (i.e. be able to recount these manifests) can only the owner of the private part of the OEM Root Key, i.e. vendor.

When looking at a picture, doubts immediately arise about the need for such a long verification chain - it was possible to use one manifest. Why complicate it?

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 is leaked (by which the second manifest is signed), the incident will affect only one product line and only until the vendor generates a new pair and includes recounted manifests in the next BIOS update.

But if the root key (by which the first manifest is signed) is compromised, it will not be possible to replace it, the revocation procedure is not provided because the hash of the public part of this key is programmed in FPFs once and for all.

Intel Boot Guard Configuration

Now let's dwell on the configuration of Intel BG and the process of its creation. If you look at the corresponding tab in the GUI of the Flash Image Tool utility from the Intel System Tool Kit (STK), you can see that the Intel BG configuration includes a hash of the public part of the vendor’s 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 configuration of Intel BG - the essence is very flexible. Consider, for example, the flag Force_Boot_Guard_ACM. When it is removed, if the BG startup ACM module on the SPI flash memory is not found, there will be no trusted boot. It will be untrusted.

We already wrote above that the enforcement policy for VB mode can be configured so that, if a verification error occurs, again, an untrusted download will occur.

Leave such things at the discretion of the vendors ... The

GUI utility provides the following "ready-made" profiles:

room	Mode	Description
0	No_FVME	Intel BG Technology Off
1	Ve	VB mode enabled, timeout shutdown
2	VME	both modes are turned on (VB and MB), timeout shutdown
3	VM	both modes are on, without turning off the system
4	Fve	VB mode on, immediate shutdown
5	Fvme	both modes are on, immediate shutdown

As already mentioned, the configuration of Intel BG should be written once and for all by the system vendor into the chipset fusion (FPFs) - a small (according to unverified reports, only 256 bytes) hardware storage of information inside the chipset, which can be programmed outside the Intel production facilities (therefore, it is Field Programmable Fuses).

It is great for storing configurations because:

has a one-time-programmable area for storing data (just where the Intel BG configuration is written to);
Only Intel ME can read and program it.

So, in order to configure Intel BG technology on a specific system, the vendor does the following during production:

Using the Flash Image Tool (from Intel STK), it creates a firmware image with the specified configuration of Intel BG in the form of variables within the Intel ME region (the so-called temporary mirror for FPFs);
Using the Flash Programming Tool (from Intel STK), it 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 commits FPFs to the specified values from the mirror for FPFs in the ME region, sets the permissions in the SPI flash descriptors to the values recommended by Intel (described at the beginning of the article) and performs RESET systems.

Intel Boot Guard Implementation Analysis

In order to analyze the implementation of this technology using a specific example, we checked the following systems for signs 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, there is support, technology is included
Lenovo Yoga 2 Pro	Haswell, no support
Lenovo U330p	Haswell, no support

By "support" is meant the presence of Intel BG startup ACM module, the above manifests and the corresponding code in the BIOS, i.e. implementation for analysis.

As an example, take the downloaded from of. vendor site image 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.

Samples of the decrypted microcode could not be found, therefore, the way the actions described below are implemented (in microcode or in hardware) is an open question. Nevertheless, the fact that modern Intel processors are “able” to perform these actions is a fact.

After exiting the RESET state, the processor (in the address space of which the contents of the flash memory is already mapped) finds the FIT (Firmware Interface Table) table. It's easy to find it, the pointer to it is written at FFFF FFC0h.

In this example, at this address lies the value of 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 header 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 an unknown reason, the check sum is far from always calculated in these tables (the field is left zero).

The remaining entries indicate various binaries that need to be paired / executed before the BIOS is executed, i.e. before switching to legacy RESET-vector (FFFF FFF0h). The structure of each such record 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 record 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’s obvious that one of the entries points to the location of the Intel BG startup ACM binar. The header structure of this binar is typical for Intel-developed code modules (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 binar into its cache, verifies and launches.

Intel BG startup ACM

As a result of the analysis of the operation of this ACM, it became clear that he was doing the following:

receives from Intel ME the configuration of Intel BG recorded in the chipset fuses (FPFs);
finds KEYM and IBBM manifests, verifies them.

To find these manifests, ACM also uses the FIT table, in which two types of records are allocated to indicate the structure data (see FIT_ENTRY_TYPES above).

Let us dwell on the manifestos. In the structure of the first manifest, we see several obscure constants, a hash of the public key from the second manifest, and a public OEM Root Key with a signature in the form of 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 OEM Root Key public key, recall, we use the SHA256 fuse hash, which at that moment has already been received from Intel ME.

Let's move on to the second manifest. It consists of three structures:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

In the first - 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 is the SHA256 IBB hash and the number of descriptors that describe the contents of the IBB (i.e. what the hash is considered 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;
};

IBB descriptors follow this structure, one after the other. Their contents have 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 the 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 SEC and PEI phase modules.

The second manifest is completed by the 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, the processor will launch ACM, which will verify the authenticity of the contents of the sections with the phase code SEC and PEI. Next, the processor exits ACM, goes over the RESET vector, and starts executing the BIOS.

The verified PEI partition should 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 we found ourselves and having support for Intel BG only turned out to be Lenovo and Gigabyte systems, let’s take a look at the code extracted from these systems.

UEFI BIOS module LenovoVerifiedBootPei

In the case of Lenovo, this turned out to be the LenovoVerifiedBootPei {B9F2AC77-54C7-4075-B42E-C36325A9468D} module developed by Lenovo.

His job is to search (by GUID) a hash table for DXE and verify DXE.

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

The hash table {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} has the following format:

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 module {B41956E1-7CA2-42DB-9562-168389F0F066}, developed by AMI, therefore, it is present in any AMI BIOS with Intel BG support.

Its operation algorithm is slightly different, however, comes 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} that he is looking for 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

We will 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 for platforms on Intel SoC, in which significant changes have occurred, for example :

BIOS and Intel ME regions (or rather Intel TXE, according to the terminology for Intel SoC) are now one IFWI region;
even though Intel BG was enabled on the platform, such structures as FIT, KEYM, IBBM were not found in flash memory;
in addition to TXE and ISH cores (x86), a third core was added to the chipset (again ARC, by the way) - PMC (Power Management Controller), which is related to ensuring the performance of the power subsystem and monitoring performance.

The content of the new IFWI region is a collection of the following modules:

Bias	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	Intel PMC firmware code section, ARC, signed by Intel
0002 0000h	FTPR	Intel TXE firmware code section, x86, signed by Intel
0007 B000h	UCOD	firmware update for CPU, signed by Intel
0008 0000h	IBBP	UEFI BIOS, SEC / PEI phases, x86, signed by the vendor
0021 8000h	ISHC	Intel ISH firmware code section, x86, signed by the vendor
0025 8000h	NFTP	Intel TXE firmware code section, x86, signed by Intel
0036 1000h	IUNP	is unknown
0038 1000h	OBBP	UEFI BIOS, DXE phase, x86, not signed

During the analysis of the TXE firmware, it became apparent that after the RESET, the 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 gives the processor access there and “releases” it from the RESET.

Rootkit Guard

Well, now let's move on to the hot. Once we found that on many systems in the SPI flash descriptors are written permissions to access the regions of the SPI flash memory so that all users of this memory can 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 undefined state. Yes, Intel BG is neither turned on nor off in such cases.

We are talking about the following systems (with regards to 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 Intel.

An adequate response came only from Lenovo , who recognized the problem and released the patch .

Gigabyte seemed to accept information about the vulnerability, but did not comment on it at all.

Communication with MSI was completely stalled on our request to send our public PGP key (in order to send them an encrypted security advisory). They stated that "they are a manufacturer of equipment, and PGP keys do not produce."

But closer to the point. Since the fuses are left in an undefined state, the user (or an attacker) can program them themselves (the most difficult is to find the Intel STK) To do this, follow these steps:

1. Boot into Windows (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 fuses are not programmed on this system.

2. Read the contents of the flash memory using the Flash Programming Tool.

3. Open the read image using any means for editing the UEFI BIOS, make the necessary changes (introduce 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 to assemble a new firmware image (setting the configuration of Intel BG).

5. Write a new image to flash memory using the Flash Programming Tool, make sure with MEinfo that the ME region now contains Intel BG configuration.

6. Using the Flash Programming Tool, close the manufacturing mode.

7. The system will reboot, after which, using MEinfo, you can verify that the FPFs are now programmed.

These steps will permanently enable Intel BG on this system. The action cannot be undone, which means:

Only the owner of the private part of the root key (i.e., the one who turned on Intel BG) can update the UEFI BIOS on this system;
if you return the original firmware to this system, for example, using the programmer, it will not even turn on (a consequence of the enforcement policy in case of verification error);
To get rid of such a UEFI BIOS, you need to replace the chipset with the programmed FPFs with “clean” (that is, re-solder the chipset if you have access to an infrared soldering station at the cost 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 the UEFI BIOS environment. Say, in the most privileged processor mode - SMM. Such a rootkit may have the following properties:

run parallel to the OS (you can configure the workout to generate 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 program code can be encrypted and decrypted when launched in SMM mode. As a key for encryption, you can use any data that is available only in SMM mode. For example, a hash from a set of addresses in SMRAM. To get this key, you need to get into SMM. And this can be done in two ways. Find RCE in the SMM code and run it, or add your SMM module to the BIOS, which is impossible, since we turned on 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, Intel ISH (take a close look at the picture).

Although the capabilities of the Intel ISH subsystem have not yet been explored, it appears to be an interesting attack vector on Intel ME.

conclusions

The study provided a technical description of Intel Boot Guard technology. Less than a couple of secrets in the Intel's security through obscurity model.
An attack scenario is presented that allows you to create an undeletable rootkit in the system.
We saw that modern Intel processors are capable of executing a lot of proprietary code even before the BIOS starts working.
Platforms with Intel 64 architecture are becoming 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).

Mitigations

Vendors who intentionally leave manufacturing mode open should definitely close it. So far, only eyes are being shut and the new Kaby Lake systems show this.

Users can turn off Intel BG on their systems (which are subject to the described vulnerability) by running the Flash Programming Tool with the -closemnf parameter. First, you should make sure (using MEinfo) that the configuration of Intel BG in the ME region provides for the shutdown of this technology after programming in FPFs.

Tags: