[personal profile] mjg59
Intel just announced a vulnerability in their Active Management Technology stack. Here's what we know so far.


Intel chipsets for some years have included a Management Engine, a small microprocessor that runs independently of the main CPU and operating system. Various pieces of software run on the ME, ranging from code to handle media DRM to an implementation of a TPM. AMT is another piece of software running on the ME, albeit one that takes advantage of a wide range of ME features.

Active Management Technology

AMT is intended to provide IT departments with a means to manage client systems. When AMT is enabled, any packets sent to the machine's wired network port on port 16992 or 16993 will be redirected to the ME and passed on to AMT - the OS never sees these packets. AMT provides a web UI that allows you to do things like reboot a machine, provide remote install media or even (if the OS is configured appropriately) get a remote console. Access to AMT requires a password - the implication of this vulnerability is that that password can be bypassed.

Remote management

AMT has two types of remote console: emulated serial and full graphical. The emulated serial console requires only that the operating system run a console on that serial port, while the graphical environment requires drivers on the OS side requires that the OS set a compatible video mode but is also otherwise OS-independent[2]. However, an attacker who enables emulated serial support may be able to use that to configure grub to enable serial console. Remote graphical console seems to be problematic under Linux but some people claim to have it working, so an attacker would be able to interact with your graphical console as if you were physically present. Yes, this is terrifying.

Remote media

AMT supports providing an ISO remotely. In older versions of AMT (before 11.0) this was in the form of an emulated IDE controller. In 11.0 and later, this takes the form of an emulated USB device. The nice thing about the latter is that any image provided that way will probably be automounted if there's a logged in user, which probably means it's possible to use a malformed filesystem to get arbitrary code execution in the kernel. Fun!

The other part of the remote media is that systems will happily boot off it. An attacker can reboot a system into their own OS and examine drive contents at their leisure. This doesn't let them bypass disk encryption in a straightforward way[1], so you should probably enable that.

How bad is this

That depends. Unless you've explicitly enabled AMT at any point, you're probably fine. The drivers that allow local users to provision the system would require administrative rights to install, so as long as you don't have them installed then the only local users who can do anything are the ones who are admins anyway. If you do have it enabled, though…

How do I know if I have it enabled?

Yeah this is way more annoying than it should be. First of all, does your system even support AMT? AMT requires a few things:

1) A supported CPU
2) A supported chipset
3) Supported network hardware
4) The ME firmware to contain the AMT firmware

Merely having a "vPRO" CPU and chipset isn't sufficient - your system vendor also needs to have licensed the AMT code. Under Linux, if lspci doesn't show a communication controller with "MEI" or "HECI" in the description, AMT isn't running and you're safe. If it does show an MEI controller, that still doesn't mean you're vulnerable - AMT may still not be provisioned. If you reboot you should see a brief firmware splash mentioning the ME. Hitting ctrl+p at this point should get you into a menu which should let you disable AMT.

How about over Wifi?

Turning on AMT doesn't automatically turn it on for wifi. AMT will also only connect itself to networks it's been explicitly told about. Where things get more confusing is that once the OS is running, responsibility for wifi is switched from the ME to the OS and it forwards packets to AMT. I haven't been able to find good documentation on whether having AMT enabled for wifi results in the OS forwarding packets to AMT on all wifi networks or only ones that are explicitly configured.

What do we not know?

We have zero information about the vulnerability, other than that it allows unauthenticated access to AMT. One big thing that's not clear at the moment is whether this affects all AMT setups, setups that are in Small Business Mode, or setups that are in Enterprise Mode. If the latter, the impact on individual end-users will be basically zero - Enterprise Mode involves a bunch of effort to configure and nobody's doing that for their home systems. If it affects all systems, or just systems in Small Business Mode, things are likely to be worse.
We now know that the vulnerability exists in all configurations.

What should I do?

Make sure AMT is disabled. If it's your own computer, you should then have nothing else to worry about. If you're a Windows admin with untrusted users, you should also disable or uninstall LMS by following these instructions.

Does this mean every Intel system built since 2008 can be taken over by hackers?

No. Most Intel systems don't ship with AMT. Most Intel systems with AMT don't have it turned on.

Does this allow persistent compromise of the system?

Not in any novel way. An attacker could disable Secure Boot and install a backdoored bootloader, just as they could with physical access.

But isn't the ME a giant backdoor with arbitrary access to RAM?

Yes, but there's no indication that this vulnerability allows execution of arbitrary code on the ME - it looks like it's just (ha ha) an authentication bypass for AMT.

Is this a big deal anyway?

Yes. Fixing this requires a system firmware update in order to provide new ME firmware (including an updated copy of the AMT code). Many of the affected machines are no longer receiving firmware updates from their manufacturers, and so will probably never get a fix. Anyone who ever enables AMT on one of these devices will be vulnerable. That's ignoring the fact that firmware updates are rarely flagged as security critical (they don't generally come via Windows update), so even when updates are made available, users probably won't know about them or install them.

Avoiding this kind of thing in future

Users ought to have full control over what's running on their systems, including the ME. If a vendor is no longer providing updates then it should at least be possible for a sufficiently desperate user to pay someone else to do a firmware build with the appropriate fixes. Leaving firmware updates at the whims of hardware manufacturers who will only support systems for a fraction of their useful lifespan is inevitably going to end badly.

How certain are you about any of this?

Not hugely - the quality of public documentation on AMT isn't wonderful, and while I've spent some time playing with it (and related technologies) I'm not an expert. If anything above seems inaccurate, let me know and I'll fix it.

[1] Eh well. They could reboot into their own OS, modify your initramfs (because that's not signed even if you're using UEFI Secure Boot) such that it writes a copy of your disk passphrase to /boot before unlocking it, wait for you to type in your passphrase, reboot again and gain access. Sealing the encryption key to the TPM would avoid this.

[2] Updated after this comment - I thought I'd fixed this before publishing but left that claim in by accident.

(Updated to add the section on wifi)

(Updated to typo replace LSM with LMS)

(Updated to indicate that the vulnerability affects all configurations)

Date: 2017-05-01 11:08 pm (UTC)
From: (Anonymous)
>Not in any novel way. An attacker could disable Secure Boot and install a backdoored bootloader, just as they could with physical access.

I don't think this is actually possible with physical access — a properly configured system will at least require a supervisor password to disable Secure Boot.

>modify your initramfs (because that's not signed even if you're using UEFI Secure Boot)

This is not true if you've rolled your own Platform Keys and sign&boot plain kernel images (with initramfs bundled into them).

Date: 2017-05-02 12:30 am (UTC)
From: (Anonymous)
Are Apple Macs impacted by this at all?

Is a port scan good enough?

Date: 2017-05-02 01:36 am (UTC)
From: (Anonymous)
Is it enough to scan your entire subnet for TCP port 16992 listeners good enough to test for this? If not is there a good way to scan for it rather than looking for devices on each computer?


Date: 2017-05-02 07:20 am (UTC)
From: (Anonymous)
Hi Matthew,

best read so far on that Topic, thanx for this.

is it enough to have iptables enabled with a input-policy set to drop/reject or will the packages bypass this?

thanx in advance,


WiFi also affected

Date: 2017-05-02 11:15 am (UTC)
From: (Anonymous)
> any packets sent to the machine's wired network port on port 16992 or 16993

AMT isn't limited to wired networking hardware. If the machine has a supported Intel WiFi module, this will also work over wireless networks.

Does AMT require a different IP?

Date: 2017-05-02 12:04 pm (UTC)
From: (Anonymous)
I'm assuming that AMT acts like an iLO for the desktop. Would this mean that the IP address used would be different to that of the OS?

Looking in the intel management and security status utility, the Network information on the advancex tab shows which Im assuming means that AMT is not provisioned/configured.

Would this assumption be correct?

About graphical capabilities of AMT

Date: 2017-05-02 01:27 pm (UTC)
From: (Anonymous)
AMT has two types of remote console: emulated serial and full graphical. The emulated serial console requires only that the operating system run a console on that serial port, while the graphical environment requires drivers on the OS side.

Sadly this is incorrect. The full-blown graphical capability of AMT is providing a fully functional OS-independent VNC server that can be connected to by any proper VNC client. It is disabled by default and can be configured to require a simple (max. 8 char) VNC password.

Whether your AMT has this capability or not depends on the OEM. This feature is, along with many AMT functions, configurable in the factory. You can even put your AMT-capable motherboard into the manufacturing mode most of the time (it requires physical fiddling).

How do I know if I have it enabled

Date: 2017-05-02 01:56 pm (UTC)
From: (Anonymous)
I do have a Communication controller with HECI in the description but ctrl+p does not seem to do anything when booting.

I have also tried setting the "boot next" entry to "MEBx Hot Key" with efibootmgr and that also does nothing.

Scanning my laptop (from another machine) for open TCP ports 623,664,16992-16995 does not yield any results so I suppose I'm safe.

I do not recall if I have had access to MEBx at any point in time, I do remember permanently disabling computrace and I'm not sure if after disabling AMT it will become "unreachable".

What I do know is that lenovo issued a firmware update for this machine not too long ago and if I recall correctly it was described as critical on their website (they have since issued another update and the page for the previous update seem to be gone). The changelog had this to say about the update:

[Important updates]
1. [Important] Update includes a security fix.
(Note) If the UEFI BIOS has been updated to version 1.25 or higher, it is no longer able to roll back to the version before 1.25 for security improvement.

[New functions or enhancements]

[Problem fixes]


Date: 2017-05-02 03:53 pm (UTC)
From: (Anonymous)
Good thing that Purism actively avoids the problem (https://puri.sm/learn/avoiding-intel-amt/)... short of Intel changing its mind on AMT and the ME, it's pretty much the best solution.

Intel ark vPro=No still MEI available

Date: 2017-05-02 06:38 pm (UTC)
From: (Anonymous)
If you are curious too: Thinkpad x230 without vPro CPU (According to Intel, see i5-3230M (https://ark.intel.com/products/72164/Intel-Core-i5-3230M-Processor-3M-Cache-up-to-3_20-GHz-rPGA#tab-blade-1-0-7)) still have a MEI controller built in. Anyone knows what's the difference?

$ lspci | grep MEI
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)

Date: 2017-05-02 06:42 pm (UTC)
leo_sosnine: (Default)
From: [personal profile] leo_sosnine
Just scanned my subnet and noone seems to have these ports open, I guess it's not enabled even if supported

I wonder what's the percentage of active computers that have AMT enabled & configured, it could be a rather small number

AMT Vulnerability

Date: 2017-05-02 07:59 pm (UTC)
From: (Anonymous)
We are getting connections to the ports specified with ncat -u. Is that a reliable test? We can't connect with any other method.

Date: 2017-05-02 11:40 pm (UTC)
From: (Anonymous)
What about remote provisioning?

What would prevent an attacker on the local network(For instance in a WiFi cafe) from:
- Buy a certificate to do remote provisioning
- Running a DHCP server that responds faster than the WiFi cafe's DHCP server
- Remote provision the laptop they want
- Then bypassing that remote provisioning

Would this work on recent AMT versions?, or is it only a concern for GM45 as this was the chipset used by Vassilios Ververis in his research?

Is it possible to gain code execution from AMT, in a programable way, to the machine trough either:
- Remote storage
- The keyboard

I've only old GM45 laptops that can have AMT, so I've no way to check that.

If both assumptions are correct, then worms can be a grave concern.

In the long term, I see no other way than having completely free software computers to avoid such issues. This would permit people to still benefit from security updates.


saw this coming

Date: 2017-05-03 12:26 am (UTC)
From: (Anonymous)
The current state of boot security:
and the Management Engine is in a position to just do whatever it wants and fuck all of you.


A little mystake in your article

Date: 2017-05-03 10:15 am (UTC)
From: (Anonymous)
Hi Guys , in linux do this :
-> sudo su
-> lspci | grep EHCI

In the article says that is HECI but the correct is EHCI.

graphical console in linux

Date: 2017-05-03 03:29 pm (UTC)
From: (Anonymous)
> Remote graphical console seems to be problematic under Linux but some people claim to have it working

You can add me to the list of people who claim to have it working :)

If someone wishes to fiddle with it, install node and http://www.meshcommander.com/meshcentral2 . Start it and point your browser at it (I think it defaults to port 1024). You'll have to add a device, enable KVM in its properties page, and then you can open the graphical console.

Note that the version I downloaded, at least, restricts AMT passwords more than the AMT firmware does - I patched meshcentral but in hindsight it's probably easier to change the device's password.
From: (Anonymous)
SemiAccurate have addressed the discrepancy between their initial announcement (https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/) and Intel's advisory (https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr):



Date: 2017-05-04 07:22 pm (UTC)
From: (Anonymous)
I've worked with AMT before. When AMT is enabled, the OS will forward packets when connected to any WiFi network. Explicit network configuration is only required for AMT to connect to WiFi while the OS is not running. Furthermore, by default AMT will only connect to known WiFi networks when the machine is plugged in to external power, but that can by configured to listen while on battery power too.

If you ping a machine, you can usually tell if it's the OS or AMT ME responding to the ping based on the ttl, as AMT ME will use a 255 ttl, as opposed to other OSes that respond with a ttl of 64.

Network indicator lights

Date: 2017-05-06 03:12 pm (UTC)
From: (Anonymous)
When the PC is not running but is plugged in and AMT is communicating over Ethernet, do the blinkenlights on the NIC flash or not?

Are exploits known to disable these LEDs, as with the Apple iSeeYou vulnerability?


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags