Intel’s CPUs have another Intel inside.

Since 2008, most of Intel’s chipsets have contained a tiny homunculus computer called the “Management Engine” (ME). The ME is a largely undocumented master controller for your CPU: it works with system firmware during boot and has direct access to system memory, the screen, keyboard, and network. All of the code inside the ME is secret, signed, and tightly controlled by Intel. Last week, vulnerabilities in the Active Management (AMT) module in some Management Engines have caused lots of machines with Intel CPUs to be disastrously vulnerable to remote and local attackers. While AMT can be disabled, there is presently no way to disable or limit the Management Engine in general. Intel urgently needs to provide one.

This post will describe the nature of the vulnerabilities (thanks to Matthew Garrett for documenting them well), and the potential for similar bugs in the future. EFF believes that Intel needs to provide a minimum level of transparency and user control of the Management Engines inside our computers, in order to prevent this cybersecurity disaster from recurring. Unless that happens, we are concerned that it may not be appropriate to use Intel CPUs in many kinds of critical infrastructure systems.

What is AMT? How is it vulnerable?

On many Intel chips, the Management Engine is shipped with the AMT module installed. It is intended to allow system administrators to remotely control the machines used by an organization and its employees. A vulnerability announced on May 1 allows an attacker to bypass password authentication for this remote management module, meaning that in many situations remote attackers can acquire the same capabilities as an organization’s IT team, if active management was enabled and provisioned.1

Once they have AMT access, attackers can interact with the screen or console as if the user were doing so themselves. Attackers can also boot arbitrary OSes, install a new OS, and (with some work) steal disk encryption passwords.2

Not every machine is susceptible to the attack. For it to work, AMT has to have been both enabled and provisioned (commonly AMT is enabled but not provisioned by default). Once provisioned, AMT has a password set, and is listening for network packets and will control the system in response to those.3 It can be provisioned by default if vendors used a feature called “Remote Configuration” with OEM Setup, by a user with administrative access, interactively or with a USB stick during system boot, or (via the LMS vulnerability) by unprivileged users on Windows systems with LMS. Macs have MEs, but don’t ship with AMT at all. The password protection is crucial for machines with AMT provisioned, but this week’s vulnerability allowed it to be bypassed.

How can users protect themselves?

Many organizations will need to take steps to protect themselves by ensuring that AMT is disabled in their BIOS and LMS is not installed, or by updating Intel firmware.
Unfortunately, even if AMT is currently disabled, that doesn’t mean an attack was never possible—an attacker might have disabled AMT after concluding the attack, to close the door on their way out.

But troublingly, AMT is only one of many services/modules that come preinstalled on Management Engines. The best recommendation we can make for addressing this vulnerability today is to disable that specific AMT module, because Intel doesn’t provide any way to generally limit the power of the ME. But vulnerabilities in any of the other modules could be as bad, if not worse, for security. Some of the other modules include hardware-based authentication code and a system for location tracking and remote wiping of laptops for anti-theft purposes. While these may be useful to some people, it should be up to hardware owners to decide if this code will be installed in their computers or not. Perhaps most alarmingly, there is also reportedly a DRM module that is actively working against the user’s interests, and should never be installed in an ME by default.

For expert users on machines without Verified Boot, a Github project called ME cleaner exists and can be used to disable a Management Engine. But be warned: using this tool has the potential to brick hardware, and interested parties should exercise caution before attempting to protect their systems. A real solution is going to require assistance from Intel.

What Intel needs to do fix this mess

Users need the freedom to choose what they want running on their system, and the ability to remove code that might contain vulnerabilities. Because the Management Engine only runs code modules signed by Intel, this means having a way to disable the ME or reflash it with minimal, auditable firmware. While Intel may put a lot of effort into hunting for security bugs, vulnerabilities will inevitably exist, and having them lurking in a highly privileged, low level component with no OS visibility or reliable logging is a nightmare for defensive cybersecurity. The design choice of putting a secretive, unmodifiable management chip in every computer was terrible, and leaving their customers exposed to these risks without an opt-out is an act of extreme irresponsibility.

What would be best for users and for the public’s ability to control machines that they have purchased would be for Intel to provide official support for reducing the attack surface to limit the potential harm of the ME.

So we call upon Intel to:

• Provide clear documentation for the software modules that are preinstalled on various Management Engines. What HECI commands provide a full list of the installed modules/services? What are the interfaces to those services?
• Provide a way for their customers to audit ME code for vulnerabilities. That is presently impossible because the code is kept secret.
• Offer a supported way to disable the ME. If that’s literally impossible, users should be able to flash an absolutely minimal, community-auditable ME firmware image.
• On systems where the ME is an essential requirement for other security features that are important to some users (like Boot Guard), offer an additional option of a near-minimal, community-auditable ME firmware image that performs these security functions, and nothing else. Or alternatively, a supported way to build and flash firmware images where the user can inspect and control which services/modules are present, in order to manage security risks from those modules.

Until Intel takes these steps, we have reason to fear that the undocumented master controller inside our Intel chips could continue to be a source of serious vulnerabilities in personal computers, servers, and critical cybersecurity and physical infrastructure. Intel needs to act quickly to provide the community with an auditable solution to these threats.

Correction 2017-05-12: Intel has contacted us with two corrections to the details of this post. (1) Management Engines are not physically located on the CPU die itself, but in other parts of Intel's chipsets; (2) the LMS-based local privilege escalation was a second consequence of the first code vulnerability, rather than a second vulnerability or bug of its own. We have accordingly edited the language of this post in a couple of places, but do not believe these updates affect its conclusions.

• 1. A second consequence of this vulnerability allowed local, non-administrator users of Windows systems to provision AMT, if a Windows component called Local Manageability Service (LMS) is installed (whether LMS is installed is typically up to the hardware manufacturer — for instance Lenovo would decide whether or not to include LMS on a Thinkpad by default). This second consequence allows non-admin users or compromised accounts to take complete control of those machines by provisioning AMT with settings of their choice.
• 2. AMT access is not the same as running arbitrary ME code, so attackers can’t access system memory directly; they have to use the console, VNC, or boot OS images to accomplish their goals.
• 3. If provisioned, AMT listens on ports 16992 and 16993. Often this would only be on a physical Ethernet connection, but provisioning can also enable AMT over WiFi (once an OS is running, AMT over WiFi requires OS support).