Something is rotten in the state of Intel. Over the last decade or so, Intel has dedicated enormous efforts to the security of their microcontrollers. For Intel, this is the only logical thing to do; you really, really want to know if the firmware running on a device is the firmware you want to run on a device. Anything else, and the device is wide open to balaclava-wearing hackers.

Intel’s first efforts toward cryptographically signed firmware began in the early 2000s with embedded security subsystems using Trusted Platform Modules (TPM). These small crypto chips, along with the BIOS, form the root of trust for modern computers. If the TPM is secure, the rest of the computer can be secure, or so the theory goes.

The TPM model has been shown to be vulnerable to attack, though. Intel’s solution was to add another layer of security: the (Intel) Management Engine (ME). Extremely little is known about the ME, except for some of its capabilities. The ME has complete access to all of a computer’s memory, its network connections, and every peripheral connected to a computer. It runs when the computer is hibernating, and can intercept TCP/IP traffic. Own the ME and you own the computer.

There are no known vulnerabilities in the ME to exploit right now: we’re all locked out of the ME. But that is security through obscurity. Once the ME falls, everything with an Intel chip will fall. It is, by far, the scariest security threat today, and it’s one that’s made even worse by our own ignorance of how the ME works.

The Beginning of Intel’s Management Engine

In her talk at last month’s CCC, [Joanna Rutkowska] talked about the chain of trust found in the modern x86 computer. Trust is a necessary evil for security, and [Joanna] contrasts it with the normal meaning of the word, for which she uses “trustworthy”. If you can see the source code for your application, you can verify that it’s trustworthy. But since the application runs on top of the operating system, you have to trust the OS. Even if the OS is verified and trustworthy, it still has to trust the BIOS and firmware. As you keep digging down like this, verifying each layer, you eventually get to some part of the system that you can’t verify and just have to trust, and this root of trust is the role that the ME is trying to play.

This root of trust on the modern computer is, quite simply, untrustworthy. Instead of a proper BIOS that can trace its origins to the first x86 computers, computers today have UEFI and Secure Boot, a measure designed to only allow signed software to run on the device. Secure Boot can be disabled from the manufacturer, and security isn’t secure if it’s optional, and even less so if there are exploits for specific implementations of UEFI.

[Joanna]’s plan for truly trustworthy computing is a simple USB thumb drive. Instead of holding data, this thumb drive contains security keys. The idea behind this ‘trusted stick’ is that the root of trust can be built from this stick, and these keys are something that you own and control and can presumably keep secret. Everything else above that is verifiable, and thus doesn’t need to be trusted. It’s an interesting idea, but right now it’s just an idea. And it stands in contrast to the current situation where Intel somehow bakes the trust into the chip for you.

What the Management Engine Is

The best description of what the Management Engine is and does doesn’t come from Intel. Instead, we rely on [Igor Skochinsky] and a talk he gave at REcon 2014. This is currently the best information we have about the ME.

The Intel ME has a few specific functions, and although most of these could be seen as the best tool you could give the IT guy in charge of deploying thousands of workstations in a corporate environment, there are some tools that would be very interesting avenues for an exploit. These functions include Active Managment Technology, with the ability for remote administration, provisioning, and repair, as well as functioning as a KVM. The System Defense function is the lowest-level firewall available on an Intel machine. IDE Redirection and Serial-Over-LAN allows a computer to boot over a remote drive or fix an infected OS, and the Identity Protection has an embedded one-time password for two-factor authentication. There are also functions for an ‘anti-theft’ function that disables a PC if it fails to check in to a server at some predetermined interval or if a ‘poison pill’ was delivered through the network. This anti-theft function can kill a computer, or notify the disk encryption to erase a drive’s encryption keys.

These are all extremely powerful features that would be very interesting to anyone who wants or needs to completely own a computer, and their sheer breadth makes the attack surface fairly large. Finding an exploit for the Intel ME will be difficult, though. While most of the firmware for the ME also resides in the Flash chip used by the BIOS, the firmware isn’t readily readable; some common functions are in an on-chip ROM and cannot be found by simply dumping the data from the Flash chip.

This means that if you’re trying to figure out the ME, a lot of the code is seemingly missing. Adding to the problem, a lot of the code itself is compressed with either LZMA or Huffman encoding. There are multiple versions of the Intel ME, as well, all using completely different instruction sets: ARC, ARCompact, and SPARC V8. In short, it’s a reverse-engineer’s worst nightmare.

The Future of ME

With a trusted processor connected directly to the memory, network, and BIOS of a computer, the ME could be like a rootkit on steroids in the wrong hands. Thus, an exploit for the ME is what all the balaclava-wearing hackers want, but so far it seems that they’ve all come up empty.

The best efforts that we know of again come from [Igor Skochinsky]. After finding a few confidential Intel documents a company left on an FTP server, he was able to take a look at some of the code for the ME that isn’t in the on-chip ROM and isn’t compressed by an unknown algorithm. It uses the JEFF file format, a standard from the defunct J Consortium that is basically un-Googlable. (You can blame Jeff for that.) To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that’s used in the firmware remains an unsolved problem.

But unsolved doesn’t mean that people aren’t working on it. There are efforts to break the ME’s Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now.

There are many researchers trying to unlock the secrets of Intel’s Management Engine, and for good reason: it’s a microcontroller that has direct access to everything in a computer. Every computer with an Intel chip made in the last few years has one, and if you’re looking for the perfect vector for an attack, you won’t find anything better than the ME. It is the scariest thing in your computer, and this fear is compounded by our ignorance: no one knows what the ME can actually do. And without being able to audit the code running on the ME, no one knows exactly what will happen when it is broken open.

The first person to find an exploit for Intel’s Management Engine will become one of the greatest security researchers of the decade. Until that happens, we’re all left in the dark, wondering what that exploit will be.