Intel ME

A backdoor bonanza?

Ever since around 2008, Intel processors have included something called the Intel Management Engine (ME) - a subsystem which is completely independent from the user's main CPU, but which has unrestricted access to all system resources. This includes access to the host OS, RAM, and cryptography engine.

Intel ME runs on a dedicated processor, and it can be active even when the computer is hibernating or is turned off. It also has its own dedicated network connection, as it intercepts packages from the integrated network interface controller.

There is also a software component called Intel Active Management Technology (AMT), which allows remote control on the ME, which Intel claims is usually disabled by default on "consumer hardware" (as it is only a part of the vPro collection).

This technology entails some fairly obvious risks and issues, as pointed out in critiques by TechRepublic, the Free Software Foundation, the coreboot project.

While ME has been widely discussed for quite some time amongst security- and/or privacy-minded technologists, it's reasonable to assume that most end-users have litte to no knowledge of the technology.

The good

This technology allows large organizations to remotely control/manage their fleet of computing devices.

Typical legitimate use cases for Intel ME and AMT includes provisioning, configuring, monitoring, installing and upgrading. The technology also includes anti-theft functionality like locking down the machine and encrypting hard drives.

It enables this even on remote devices (as ME manages its own network connection), e.g. via company VPN (making the device available on the company network).

The bad

Intel ME cannot be disabled, though there are several projects with limited success and/or limited support for different processor architectures.

Anyone with access to it can access the computer in question - even when it's powered off (in the case of workstations) or hibernating - provided it is connected to a power source, like a mains or a laptop battery.

Unsurprisingly, Intel ME's firmware is closed source, and its software is encrypted on the device. As a consequence, users have no idea what their device is up to - they arguably do not have control over their own computer. The only insight people have as to how the technology actually works comes from reverse-engineering efforts like those described by Igor Skochinsky in these slides (PDF available here).

All of this introduces several layers of trust that users just have to accept - all of which, of course, could theoretically be misused by any malignity in the hierarchy or possibly be breached (e.g. via hacking or social engineering):

  • State actors (some of which have a track record of intercepting and tampering with hardware and software)
  • Intel
  • The technology behind the solution
  • Hardware manufacturers
  • OEMs/Resellers
  • Retailers and vendors
  • (Employers)

In addition to this, versions since ME 7.1 has included a Dynamic Application Loader (an embedded JVM), which enables uploading and running software (applets) on ME dynamically.

While there is no way to completely disable ME, Intel claims users can disable AMT features via BIOS settings - but these features are implemented differently by different OEMs, and some BIOS settings may be inaccessible or hard to find. In reality, though, there is really no way to know for certain if and to what extent the software is truly disabled, as users have no way of inspecting what goes on in the ME.

The ugly

Not only is this a problem of principles, nor only a theoretical threat or an act of user-hostility;

On May 1st, Intel revealed that AMT contains a critical security vulnerability (technical document detailing the escalation of privilege vulnerability courtesy of Embedi Security available here). It concerns CPUs with Intel ME, on motherboards that support Intel VPro. This means that a huge number of computers are wide open for attack by adversaries that posess some modicum of technical sophistication. But the bar - let's face it - really isn't that high any more, what with Metasploit and other, more specialiced pre-packaged exploits. In fact, there is already a module for Metasploit that attempts to bypass AMT authentication.

Intel claims the exploit doesn’t affect consumer chips - only machines with vPro present and AMT enabled and provisioned. However, Charlie Demerjian of SemiAccurate claims that there also exists a local exploit, through which attackers could provision and enable AMT over the network - though he admits this would be very hard (as in on the level of state/nation actors).

Even worse, the guys over at SemiAccurate claim to have told Intel about this vulnerability years ago, in addition to a second, less severe, local exploit in Intel's Local Manageability Service (LMS), which also runs on the ME.

This remotely exploitable security hole affects all Intel processors from Nehalem (2008) to Kaby Lake (2017). The vulnerability can only be mitigated via a firmware-update, which manufacturers have to develop (HP, Dell, Fujitsu and others have already done this).

Many of the affected machines are no longer supported (as they are out of warranty), and will thus not be receiving firmware updates from their manufacturers. Supported machines will need some manual intervention both when updates are available and in the mean time, though.

Additionally, this may also affect firewalls, servers, other embedded devices, and medical equipment - the latter of which really don't need more trouble after the recent WannaCry ransomware attack.

In practice, an attacker would only need to gain access to a network that a device of interest is connected to in order to use the exploit. One must also assume that the vulnerability has been exploited in the wild by now.

Of course, critics of the technology have been warning about this sort of thing for years - and are saying the same things yet again.


To sum it all up: Intel provides a backdoor to its products by default - and now it's been hacked.

Some may argue that these technologies are great since they enable easier IT-administration - but others may argue that the way they are currently implemented carries with it huge implications for security and privacy. And in all fairness, it shouldn't be a big deal to allow customers and users to make a choice themselves as to whether they want the engine itself enabled or not.

In case you were wondering, AMD and ARM have similar subsystems in the form of Platform Security Processor (PSP) and TrustZone, respectively.

Also worth noting is that this sort of thing is (and always has been) the case with every cellphone as well.

Two things are for certain, though:

  1. This is all pretty dumb, considering the obvious dangers of the implementation (and all the critique it has been the subject of)
  2. It plays right into the narrative of the tinfoil hat brigade


If you don't have

  • An Intel CPU from between 2008 and 2017
  • A motherboard that supports Intel VPro
  • Intel AMT-enabled network hardware
  • A computer with Intel AMT enabled and provisioned

you should be fine.

The basics are beautifully summed up by Matthew Garrett here.


There are some reasonable objections to raise with regards to Intel ME, though.

Also: Betteridge's law of headlines.


Newer post
Platinum Chip
Older post
GPL ruled enforcable in the U.S.