In the previous article , the course of researching the safety of firmware industrial switches was described. We have shown that the detected architectural flaws make it easy to fake firmware images, update switches with them and execute their code on them (and in some cases on clients connecting to switches). In addition, we have described the possibilities of pinning injected code on devices. They stressed the low quality of the firmware code and the lack of protection mechanisms against exploitation of binary vulnerabilities.
We promised to give a real example of a strong security model for firmware, where modifying executable code is a very nontrivial task for a potential attacker.

Meet the Intel Management Engine subsystem , the most mysterious component of the architecture of modern x86 platforms.
')

Introduction

For a start, thoroughly investigate the subject area. What is it, where did it come from and why?

In 2005, Intel introduced Active Management Technology (AMT) version 1.0 - a solution for remote administration (management, inventory, updating, diagnostics, troubleshooting, etc.) and the protection of destructive computer systems, a kind of analogue technology Intelligent Platform Management Interface (IPMI) used in servers.


[drawing taken from here ]

The architecture of AMT 1.0 is based on the microcontroller (Management Engine) integrated into the chipset and endowed with very impressive features, for example:

• out-of-band access to the network interface (Ethernet), which it shares with the main CPU, but with its own data link controller, monitors all incoming network traffic from which it cuts (using Packet Filter) packets intended for him. For the OS (the presence and state of which, by the way, does not affect the work of AMT) this traffic is no longer visible;
• internal web server with TLS encryption;
• access to peripheral equipment, receiving and storing in non-volatile memory (in the same place as its firmware) information about it.

And this microcontroller starts working when power is applied to the motherboard of the computer system (i.e. when the computer is connected to the electrical network, even before the user presses the Power button).


So, the Management Engine is always enabled, but using the AMT capabilities requires activation (implies setting a password, network parameters, ...) in the BIOS setup, or rather in the MEBx setup:


[screenshot taken from here ]

It is commendable that the default password (“admin”) when you first log in must be changed to a new one that meets certain requirements: at least 8 characters, among which must be at least one digit, one capital letter and one special. symbol.

After setting up an AMT-compatible computer system, remote administrator
network functions become available (to use them, you must enter a login and password):

• hardware inventory;
• web interface (via HTTP over port 16992);
• Serial Over LAN (SOL) - virtual COM-port through the network, which allows you to turn on / restart / turn off the computer, access the setup menu BIOS;
• IDE-Redirection (IDE-R) - option to redirect downloads from a local boot device to a remote (pre-prepared system image).

AMT 1.0 was implemented on the Intel 82573E series Gigabit Ethernet Controller network module integrated into the South Bridge (Input / Output Controller Hub, ICH).

Then, in 2006, starting with AMT version 2.0, the microcontroller was transferred to the north bridge of the chipset (Graphics and Memory Controller Hub, GMCH). It was then that the subsystem was named in the Intel Management Engine (ME) version 2.0.


[drawing taken from here ]

At the same time, the Intel vPro brand appeared, which denoted a complex of technologies implemented on the basis of Intel ME: AMT, Trusted Execution Technology (TXT) and Virtualization Technology (VT). Later this list includes Identity Protection Technology (IPT) and Anti-Theft (AT).

At the same time, Intel ME was provided with even more impressive features, including full access to all the contents of the computer’s internal memory via an internal DMA controller, and later it became possible to monitor the video stream displayed on the monitor (though only when using the integrated graphics core) .

Gradually, more and more various system functions were added to this subsystem (some were previously used by the BIOS) to ensure the operability of the computer platform:

1. part of the functions of the Advanced Control and Power Interface (ACPI) and Alert Standard Format (ASF);
2. Quiet System Technology (QST);
3. Integrated Clock Control (ICC);
4. Trusted Platform Module (TPM);
5. ...

and other technologies.

AMT also did not stand still and was actively developing: the composition of the protocols used was changed (for example, HTTPS support was added via port 16993), in version 6.0, Remote Desktop feature appeared for the remote administrator, also known as KVM (Keyboard Video Mouse), and so on.

You can read more about the development of Intel AMT here .


However, due to the high cost of implementation, this subsystem was present, with a few exceptions, only on motherboards with Intel Q chipsets:

GMCH	Ich	ME / AMT version
Q965	ICH8	ME 2.x (AMT 2.x)
GM965 / GME965 / GL960 / GLE960 / PM965	ICH8M	ME 2.5.x (AMT 2.5.x) <- first appearance on laptops
Q35	ICH9	ME 3.x (AMT 3.x)
GM45 / PM45	ICH9M	ME 4.x (AMT 4.x) <- only on laptops
Q45	ICH10	ME 5.x (AMT 5.x)

Then why all this specific hardware with a vPro nameplate, which few (in the Russian Federation) acquired because of the high cost (and other reasons)?

The fact is that, starting in 2010, together with the transfer of part of the functional blocks of the north bridge (graphics core, memory controller, ...) into the CPU case, the Intel ME subsystem was built into all Intel-made chipsets. At the same time, the ME controller remained in the chipset case - in the Platform Controller Hub (PCH). These are chipsets 5 series and higher.

So, the chronology of subsequent versions for desktops and laptops:

PCH	ME / AMT version
5 series chipset	ME 6.x (AMT 6.x)
6 series chipset	ME 7.x (AMT 7.x)
7 series chipset	ME 8.x (AMT 8.x)
8 series chipset	ME 9.x (AMT 9.x)
9 series chipset	ME 9.5.x / 10.x (AMT 9.5.x / 10.x)
100 series chipset	ME 11.x (AMT 11.x)

Note: AMT functionality remains available only on Q chipsets, i.e. only on equipment with a vPro nameplate.


Think only desktops and laptops? No, Intel is the answer!

The same fate befell the server platforms from Intel: the subsystem is built into them, but under a different name - Intel Server Platform Services (SPS). There was an appearance in the SoC (System-on-a-Chip) under the name Intel Trusted Execution Engine (TXE).


As a result, the architecture of each modern mobile / laptop / desktop / server computer platform with Intel's chipset / SoC includes the most secretive (from the system user) and the preferred execution environment - the Intel ME subsystem. Not surprisingly, developing this architecture, Intel was forced to seriously work on its protection against compromise.

Let us take a breath and consider the architecture of this subsystem in order to understand the applied security model. Suddenly it will help calm down?

Intel ME Architecture

The Intel Management Engine (ME) is a subsystem built into computer platforms that provides hardware and software support for various Intel technologies.

As already mentioned, the first versions of this subsystem were based on Intel's two-case chipsets. Then the ARCtangent-A4 was used as the base model of the ME controller with the standard ARC32 command system.


[picture taken from book 1]


ARCtangent-A5 / ARC600 with a compact ARCompact command system (ARC16 / 32) has already been used in single-chip chipsets.


[picture taken from book 1]


In the Intel SoC (where this subsystem is called Intel TXE), SPARC is used as the base model for the ME controller.


ARC, SPARC, and some, yes? Reversion will be uncomfortable!

It's okay, Intel took care of this: in the latest platforms (Skylake, 100 series chipsets, Intel ME 11.x), the ME controller has an ... x86 architecture!
Yes, yes, there is another x86 in the chipsets.


However, the composition of the components of the Intel ME subsystem (since version 2.0) has not changed. It:

1. ME controller - built-in chipset 32-bit microcontroller type RISC, having internal ROM and SRAM;
2. The ME region in the SPI flash memory , which stores the ME controller firmware developed and signed by Intel (therefore, it is the Intel ME firmware );
3. ME UMA - hidden from everyone except the ME controller area (16 - 32 MB) in the computer’s RAM, which it uses as a runtime-memory for locating and launching the firmware;
4. Management Engine Interface (MEI) , formerly known as the Host Embedded Controller Interface (HECI) , is a set of registers in the PCI configuration space and an area in the MMIO, which is an interface for exchanging information with the ME controller (in fact, the only communication channel of software running on CPU, with Intel ME subsystem);
5. Separate MAC -channel controller, providing the out-of-band ME controller with access to a common physical network interface for remote administration of a computer system;
6. Some modules in the BIOS that are responsible for platform initialization and report the results of their work to the ME controller via the MEI.

In the case of the Intel vPro nameplate, the Intel ME subsystem also includes the BIOS BIOS BIOS Extenstion Module (MEBx) , providing a graphical interface (shown above), as well as enabling and configuring AMT via MEI.


Thus, we have the execution environment ring -3 (as it is conventionally called) - 1 piece. Its privilege is due to the abilities with which the ME controller is endowed (described above), and the secrecy is completely lacking the ability to control software (and even hardware, in production versions of the boards) by means.

ME controller architecture

Inside the ME controller, in addition to the ARC / SPARC / x86 microprocessor:

• ME ROM - non-volatile write once memory in which the start code of the ME controller is stored;
• ME SRAM - RAM used by a ME controller when ME UMA is unavailable, for example, in the early stages of work;
• code cache and data cache to improve performance when working with memory;
• C-Link (Controller Link) - bus that allows the ME-controller to interact with peripheral hardware in S5 (System shutdown) / S3 (Sleep mode);
• Various hardware blocks:
• • high precision timer and WDT;
  • interrupt controller;
  • memory controllers and DMA;
  • HECI / MEI interface;
  • RNG, accelerator of cryptographic functions and compression functions.

[picture taken from book 2]


It's time to figure out how the code that manages all this wealth is protected from modifications.

Intel ME Firmware

Intel ME firmware, depending on the content, are of two types:

• 1.5 MB, trimmed versions;
• 5 MB full versions.

The type of firmware determines the composition of the application modules that implement certain technologies (for example, AMT, IPT, etc.). Although there is a basic part, the same for different firmware:

1. Bring Up, the first module launched from the firmware;
2. Kernel, ThreadX RTOS Core;
3. Some drivers and services.

A general description of the contents of the Intel ME firmware can be found in book 2 from the list of references, but more detailed information about the structures (analyzed analytically) can be found, for example, in this script to unpack the Intel ME firmware.

Let's go in order.


There are several regions in SPI flash:

1. Flash Descriptors, which stores pointers to all other regions, as well as read / write privileges for users of this memory. Note that usually these descriptors do not allow the ME region to be overwritten by everyone except the ME controller itself;
2. GbE (Gigabit Ethernet);
3. ME, ME controller firmware is stored here;
4. BIOS;
5. 3PDS (Third Party Data Storage), optional region.

[picture taken from here ]


Now take a look at the ME region itself, here is an example of the content from its beginning:



This is the Flash Partition Table (FPT) - a table of ME firmware sections. It stores pointers to various types (code, data, virtual area, ...) sections and their parameters. The integrity of this table is controlled by one byte of the checkum at an offset of 1Bh.

We are interested in executable partitions, i.e. those that store executable code. There are usually several of them, consider one of them:



At the beginning of the code section is the manifest, which consists of a header (with service data and EDS) and a table of modules.
In the given dump you can see a 2048-bit public RSA key (module at offset 80h relative to the beginning of the section and exponent at offset 180h). This is followed by a 256 byte signature.

With its private key, Intel signs part of the manifest header and module table (see the following dump), applying the received signature and public key for verification.

And here is a fragment of the module table of the section in question:



This table contains the headers of the modules, where some parameters and the SHA256 hash sum (at offset 14h inside the header) are indicated.


Generating your own RSA-2048 key pair and signing the partition with them will not work, since the integrity of the attached public key is verified by the start code in the ME ROM, which stores the SHA256 hash sum of the Intel public key.


As a result, the verification scheme of the ME firmware code section can be summarized in the figure:



Each code section is verified by this scheme.

This is more than enough to protect the firmware from counterfeiting. It is impossible to overwrite the ME region of the SPI flash memory programmatically (remember the permissions in Flash Descriptors), the hardware will of course allow to bypass this limitation, but the authentication control cannot be turned off.


Finally, we will look at protecting against binary vulnerabilities.

We saw that all the executable ME firmware code is divided into modules for different purposes:


[picture taken from book 1]

The ME controller has two modes of operation: privileged and user (analogous to kernel mode and user mode for the CPU). Privileged mode distinguishes, first of all, the ability to access hardware resources and the ability to access addresses outside the allocated memory range for this module.

Each module starts and runs in the specified (in the header of this module) mode.


[picture taken from book 1]

After parsing the entire ME region, you can see that the privileged mode is used by the RTOS core and some drivers. Services and application modules, as expected, are given only user mode.

Conclusion

We showed that the Intel ME subsystem is an integral part of the architecture of modern computer platforms (based on Intel chipsets / SoC). Obviously, its compromise provides a potential attacker with unlimited control over the platform: access to all the contents of the RAM (system memory, hypervisor memory, SMRAM, ACRAM, allocated memory for the graphics core - GFX UMA), out-of-band access to the network interface (monitoring of all network traffic), remote control as part of the standard AMT functionality, overwriting any SPI flash memory regions. A bonus to this is the complete lack of detection capabilities.

This is a good reason for having Intel ME serious security. We believe that vendors of any embedded network equipment should strive for the described security model. It is characterized by the following principles:

• a ban on the use of a default password, forcing to set a strong password (corresponding to certain requirements);
• use of encryption functions in network protocols;
• control of the integrity and authenticity of the entire executable firmware code;
• protection mechanisms against exploitation of binary vulnerabilities.

I will comment in advance on possible calls to use computer platforms based on CPUs and AMD chipsets: they have a very similar technology, called the Platform Security Processor (PSP). Presented not long ago, in 2013. Not much is known about it so far, but something can be read here .

---

Bibliography

1. A. Kumar, "Active Platform Management Demystified: Unleashing the Power of Intel VPro (TM) Technology", 2009, Intel Press.

2. Xiaoyu Ruan, "Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine", 2014, APress.