[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)

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?

Re: Is a port scan good enough?

Date: 2017-05-02 05:27 am (UTC)
From: (Anonymous)
You'll want to check 16993 as well. If you want to drill a little deeper, you'll want to look for servers responding with HTTP 200 status and "Server: Intel(R) Active Management Technology {version number}" or "Server: AMT".

Re: Is a port scan good enough?

Date: 2017-05-02 02:18 pm (UTC)
timmc: (Default)
From: [personal profile] timmc

I configured AMT on my work-provided Thinkpad T430s laptop (default password admin, new password must meet requirements) and connected it to ethernet.

When I scanned my home LAN with nmap -p16992,16993,16994,16995,623,664 I only found that one machine listening on any of the ports:

Nmap scan report for
Host is up (0.0036s latency).
623/tcp   open   oob-ws-http
664/tcp   closed secure-aux-bus
16992/tcp open   amt-soap-http
16993/tcp closed amt-soap-https
16994/tcp closed unknown
16995/tcp closed unknown

I also confirmed that AMT was the culprit:

$ curl -sS -i
HTTP/1.1 303 See Other
Location: /logon.htm
Content-Length: 0
Server: Intel(R) Active Management Technology 8.1.2

$ curl -sS -i
HTTP/1.1 303 See Other
Location: /logon.htm
Content-Length: 0
Server: Intel(R) Active Management Technology 8.1.2

The logon.htm page says "Web browser access to Intel® Active Management Technology is disabled on this computer, or the page in the address bar is unavailable."

Note that making those curl calls from the machine itself results in connection refused! (No matter whether I call via localhost or wlan0 or eth0 LAN IPs.) It has to be from another machine.

The machine in question is willing to try to listen on those ports at the OS level, but an attempt to connect and send data is intercepted by AMT. That's another way you could tell, I suppose.

I did not observe these behaviors when connected over WiFi instead of ethernet.

Edited (formatting) Date: 2017-05-02 02:29 pm (UTC)

Re: Is a port scan good enough?

Date: 2017-05-02 03:34 pm (UTC)
From: [personal profile] sketch242
I tried this and the only hosts on my network with port 623 open were servers with IPMI which also use this port for virtual media. All of the other TCP ports in the list were closed. However, then I tried the same scan with UDP, and found many desktops listen on some or all of these ports.
# nmap -sU -p16992,16993,16994,16995,623,664

Starting Nmap 6.40 ( http://nmap.org ) at 2017-05-02 10:34 CDT
Nmap scan report for test (
Host is up (0.00019s latency).
623/udp   open|filtered asf-rmcp
664/udp   open|filtered secure-aux-bus
16992/udp open|filtered unknown
16993/udp open|filtered unknown
16994/udp open|filtered unknown
16995/udp open|filtered unknown
MAC Address: A0:D3:C1:20:9F:11 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.28 seconds

I am not sure what open|filtered means, but I am able to establish a connection to them with nc -u. That doesn't happen on ports that show up in state closed.

Edited (add nmap scan results) Date: 2017-05-02 03:38 pm (UTC)

Re: Is a port scan good enough?

Date: 2017-05-02 03:42 pm (UTC)
timmc: (Default)
From: [personal profile] timmc
If I understand nmap's oddly formatted man page correctly, "open|filtered" means it couldn't tell whether the port was open or if something was blocking the port. Maybe throw a random port that shouldn't be open into that list (like 58166) as a sort of sentinel to see if you get the same result. If you do, a port scan won't cut it. (Maybe there's a firewall doing something odd?)

Re: Is a port scan good enough?

Date: 2017-05-17 08:45 am (UTC)
From: (Anonymous)
A recent nmap (>7.30, commit July 2016) will have a correctly formatted man page; https://github.com/nmap/nmap/issues/463

Most distros will properly have an older release packaged and won't bother updating just for the man page; https://bugs.launchpad.net/ubuntu/+source/nmap/+bug/1684304


Re: Is a port scan good enough?

Date: 2017-05-02 06:47 pm (UTC)
leo_sosnine: (Default)
From: [personal profile] leo_sosnine
There's no easy way to prove that there's no any service running behind a UDP port because it's connectionless. The scanner has to have an idea on what service could be behind the port and talk to it in its language to get some response, otherwise UDP is considered to be in unknown state as there's no handshake on transport layer => no way to prove on transport layer

Re: Is a port scan good enough?

Date: 2017-05-02 08:42 pm (UTC)
From: (Anonymous)
You can prove a UDP port isn't open: you send out a packet and the operating system returns a suitable "unreachable" ICMP message. You can prove that a UDP port is open: you send out a packet and get a data packet in return.

The problem with UDP lies in the case where you send out a packet and nothing happens. Is a firewall dropping the packets? Is the port open, and you just haven't figured out how to get a response? Are you having bad luck with network congestion? Since UDP is connectionless, you can't tell these cases apart.

Re: Is a port scan good enough?

Date: 2017-05-02 09:40 pm (UTC)
leo_sosnine: (Default)
From: [personal profile] leo_sosnine
You can prove a UDP port isn't open: you send out a packet and the operating system returns a suitable "unreachable" ICMP message.

Yeah, that's how non-microsoft ping (and/or traceroute) works, sorry I didn't mention that, I was assuming that it is firewalled for some reason, probably because their nmap output was saying that...
Edited Date: 2017-05-02 09:41 pm (UTC)

Re: Is a port scan good enough?

Date: 2017-05-02 09:23 pm (UTC)
From: (Anonymous)
open|filtered means no UDP reply was received. The ports in question are all TCP.

Re: Is a port scan good enough?

Date: 2017-05-03 03:39 pm (UTC)
From: [personal profile] sketch242
Whoever added the entries to the /etc/services file seems to disagree.
amt-soap-http   16992/tcp               # Intel(R) AMT SOAP/HTTP
amt-soap-http   16992/udp               # Intel(R) AMT SOAP/HTTP
amt-soap-https  16993/tcp               # Intel(R) AMT SOAP/HTTPS
amt-soap-https  16993/udp               # Intel(R) AMT SOAP/HTTPS
amt-redir-tcp   16994/tcp               # Intel(R) AMT Redirection/TCP
amt-redir-tcp   16994/udp               # Intel(R) AMT Redirection/TCP
amt-redir-tls   16995/tcp               # Intel(R) AMT Redirection/TLS
amt-redir-tls   16995/udp               # Intel(R) AMT Redirection/TLS


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