Intel x86s hide another CPU that can take over your machine (you can't audit it)
Damien Zammit 5:48 am Wed Jun 15, 2016



Recent Intel x86 processors implement a secret, powerful control mechanism that runs on a separate chip that no one is allowed to audit or examine. When these are eventually compromised, they'll expose all affected systems to nearly unkillable, undetectable rootkit attacks. I've made it my mission to open up this system and make free, open replacements, before it's too late.

The Intel Management Engine (ME) is a subsystem composed of a special 32-bit ARC microprocessor that's physically located inside the chipset. It is an extra general purpose computer running a firmware blob that is sold as a management system for big enterprise deployments.

When you purchase your system with a mainboard and Intel x86 CPU, you are also buying this hardware add-on: an extra computer that controls the main CPU. This extra computer runs completely out-of-band with the main x86 CPU meaning that it can function totally independently even when your main CPU is in a low power state like S3 (suspend).

On some chipsets, the firmware running on the ME implements a system called Intel's Active Management Technology (AMT). This is entirely transparent to the operating system, which means that this extra computer can do its job regardless of which operating system is installed and running on the main CPU.

The purpose of AMT is to provide a way to manage computers remotely (this is similar to an older system called "Intelligent Platform Management Interface" or IPMI, but more powerful). To achieve this task, the ME is capable of accessing any memory region without the main x86 CPU knowing about the existence of these accesses. It also runs a TCP/IP server on your network interface and packets entering and leaving your machine on certain ports bypass any firewall running on your system.

While AMT can be a great value-add, it has several troubling disadvantages. ME is classified by security researchers as "Ring -3". Rings of security can be defined as layers of security that affect particular parts of a system, with a smaller ring number corresponding to an area closer to the hardware. For example, Ring 3 threats are defined as security threats that manifest in "userspace" mode. Ring 0 threats occur in "kernel" level, Ring -1 threats occur in a "hypervisor" level, one level lower than the kernel, while Ring -2 threats occur in a special CPU mode called "SMM" mode. SMM stands for System-Management-Mode, a special mode that Intel CPUs can be put into that runs a separately defined chunk of code. If attackers can modify the SMM code and trigger the mode, they can get arbitrary execution of code on a CPU.

Although the ME firmware is cryptographically protected with RSA 2048, researchers have been able to exploit weaknesses in the ME firmware and take partial control of the ME on early models. This makes ME a huge security loophole, and it has been called a very powerful rootkit mechanism. Once a system is compromised by a rootkit, attackers can gain administration access and undetectably attack the computer.

On systems newer than the Core2 series, the ME cannot be disabled. Intel systems that are designed to have ME but lack ME firmware (or whose ME firmware is corrupted) will refuse to boot, or will shut-down shortly after booting.

There is no way for the x86 firmware or operating system to disable ME permanently. Intel keeps most details about ME absolutely secret. There is absolutely no way for the main CPU to tell if the ME on a system has been compromised, and no way to "heal" a compromised ME. There is also no way to know if malicious entities have been able to compromise ME and infect systems.

A large portion of ME's security model is "security through obscurity", a practice that many researchers view as the worst type of security. If ME's secrets are compromised (and they will eventually be compromised by either researchers or malicious entities), then the entire ME security model will crumble, exposing every recent Intel system to the worst rootkits imaginable.

Around 2013, we figured out some of the nitty-gritty details regarding how the ME firmware was packaged up into a blob. The ME firmware is verified by a secret boot ROM embedded in the chipset that first checks that the SHA256 checksum of the public key matches the one from the factory, and then verifies the RSA signature of the firmware payload by recalculating it and comparing to the stored signature. This means that there is no obvious way to bypass the signature checking, since the checking is done by code stored in a ROM buried in silicon, even though we have the public key and signature. However, there still might be an exploitable bug in the ROM bootloader.

We also discovered that the critical parts of the ME firmware are stored in a non-standard compressed format, which gets decompressed by a special hardware decompressor. My initial attempts to brute-force the decompression scheme failed miserably. Another group had better success and they have now completed a working decompression routine for all versions of ME up to but not including version 11. Kudos to them!

Our goal is to implement a completely libre software replacement for ME. When the implementation of such a security-critical component is available for scrutiny, it will be peer-reviewed and audited by persons around the world. This generally results in stronger security.

Our goal isn't to replace Intel's ME, but to provide a minimal libre alternative firmware for users who choose to use it. Unfortunately, since the firmware is protected by RSA 2048, we currently have no way to execute our own code on the ME hardware because it fails validation. We have no way to move forward, even if we wanted to.

This is scary. Most digital handcuffs are so easy to break that it's not an issue how to break it, more so an issue of the penalty one might face for actually breaking it. In this case, it is impossible to break unless you have a way to factorize semi-primes with approximately 600 decimal digits in a reasonable time. (At the time of writing this article, pretty much impossible in one human lifetime for anyone with the biggest supercomputer).

So in conclusion, Intel has so far stopped anyone from tinkering with ME firmware in practice, and there is no way to trust the code running on your ME because it's proprietary. So we are back to the days of the Sony Playstation, but for general purpose computers based on Intel x86. Matters only get worse now that Intel has squeezed a whole system into a chip, SoCs. We have no physical separation between the components that we can trust and the untrusted ME components, so we can't even cut them off the mainboard anymore. 