How to detect and mitigate the Intel escalation of privilege vulnerability on a Linux system (CVE-2017-5689)?

Question

According to the Intel security-center post dated May 1, 2017, there is a critical vulnerability on Intel processors which could allow an attacker to gain privilege (escalation of privilege) using AMT, ISM and SBT.

Because the AMT has direct access to the computer’s network hardware, this hardware vulnerability will allow an attacker to access any system.

There is an escalation of privilege vulnerability in Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology versions firmware versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 that can allow an unprivileged attacker to gain control of the manageability features provided by these products. This vulnerability does not exist on Intel-based consumer PCs.

Intel have released a detection tool available for Windows 7 and 10. I am using information from dmidecode -t 4 and by searching on the Intel website I found that my processor uses Intel® Active Management Technology (Intel® AMT) 8.0.

Affected products:

The issue has been observed in Intel manageability firmware versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 for Intel® Active Management Technology, Intel® Small Business Technology, and Intel® Standard Manageability. Versions before 6 or after 11.6 are not impacted.

The description:

An unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs: Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology (SBT)

How can I easily detect and mitigate the Intel escalation of privilege vulnerability on a Linux system?

Solution 1

The clearest post I’ve seen on this issue is Matthew Garrett’s (including the comments).

Matthew has now released a tool to check your system locally: build it, run it with

sudo ./mei-amt-check

and it will report whether AMT is enabled and provisioned, and if it is, the firmware versions (see below). The README has more details.

To scan your network for potentially vulnerable systems, scan ports 623, 624, and 16992 to 16993 (as described in Intel’s own mitigation document); for example

nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24

will scan the 192.168.1/24 network, and report the status of all hosts which respond. Being able to connect to port 623 might be a false positive (other IPMI systems use that port), but any open port from 16992 to 16995 is a very good indicator of enabled AMT (at least if they respond appropriately: with AMT, that means an HTTP response on 16992 and 16993, the latter with TLS).

If you see responses on ports 16992 or 16993, connecting to those and requesting / using HTTP will return a response with a Server line containing “Intel(R) Active Management Technology” on systems with AMT enabled; that same line will also contain the version of the AMT firmware in use, which can then be compared with the list given in Intel’s advisory to determine whether it’s vulnerable.

See CerberusSec’s answer for a link to a script automating the above.

There are two ways to fix the issue “properly”:

• upgrade the firmware, once your system’s manufacturer provides an update (if ever);
• avoid using the network port providing AMT, either by using a non-AMT-capable network interface on your system, or by using a USB adapter (many AMT workstations, such as C226 Xeon E3 systems with i210 network ports, have only one AMT-capable network interface — the rest are safe; note that AMT can work over wi-fi, at least on Windows, so using built-in wi-fi can also lead to compromission).

If neither of these options is available, you’re in mitigation territory. If your AMT-capable system has never been provisioned for AMT, then you’re reasonably safe; enabling AMT in that case can apparently only be done locally, and as far as I can tell requires using your system’s firmware or Windows software. If AMT is enabled, you can reboot and use the firmware to disable it (press CtrlP when the AMT message is displayed during boot).

Basically, while the privilege vulnerability is quite nasty, it seems most Intel systems aren’t actually affected. For your own systems running Linux or another Unix-like operating system, escalation probably requires physical access to the system to enable AMT in the first place. (Windows is another story.) On systems with multiple network interfaces, as pointed out by Rui F Ribeiro, you should treat AMT-capable interfaces in the same way as you’d treat any administrative interface (IPMI-capable, or the host interface for a VM hypervisor) and isolate it on an administrative network (physical or VLAN). You cannot rely on a host to protect itself: iptables etc. are ineffective here, because AMT sees packets before the operating system does (and keeps AMT packets to itself).

VMs can complicate matters, but only in the sense that they can confuse AMT and thus produce confusing scanning results if AMT is enabled. amt-howto(7) gives the example of Xen systems where AMT uses the address given to a DomU over DHCP, if any, which means a scan would show AMT active on the DomU, not the Dom0...

Solution 2

Simply detecting the open ports for this service is insufficient, it doesn't indicate if the version is affected or not. Our team has created a python script available at our github : CerberusSecurity/CVE-2017-5689 that detects if a target system is vulnerable to remote attack.

Sample usage:

python CVE_2017_5689_detector.py 10.100.33.252-255

This should allow you to be able to check if you are remotely exploitable. If you are interested, we also wrote a short blog post at http://cerberussec.org/ with our take on this vulnerability.

Solution 3

Intel has tools for linux at : Linux Detection and Mitigation Tools

there is a fork of it at GITHUB

Comments

[Rui F Ribeiro]

The case is further complicated when many of us are using VMs; for real machines would it be enough to scan for the presence of service at UDP 16992? +1

[Fox]

Preventative steps: use SPARC (I know, I know, not a feasible solution). Have a +1

[Rui F Ribeiro]

@Fox I have argued for long one of the security measures in Unix is to use non-Intel, maybe MIPs....ARM also has a lot of "dead-weight" silicon...and that is the reason I never believed in the purism project.

[Stephen Kitt]

@Fox amusingly enough the ME CPU in Intel processors is a SPARC nowadays ;-).

[Fox]

@StephenKitt Really? I might have to rethink my stance on Intel's chips! Almost all of my machines are PPC or SPARC, so I have to admit my bias is real

[Gilles 'SO- stop being evil']

See also Am I affected by the Intel AMT/ISM/SBT escalation of privilege vulnerability?

[comfreak]

Are you looking at the flags in the output of dmidecode where you can read 'Intel® Active Management Technology (Intel® AMT) 8.0'?

[fpmurphy]

@StephenKitt AFAIK, ME Gen 1 ( < 5.x) used 32-bit ARC instruction set. ME Gen 2 (6.x - 10.x) used 16/32-bit ARCompact instruction set. Later versions use SPARC

[dolmen]

Isn't there a local way to detect AMT from Linux on the machine? Using /proc/cpuinfo or dmidecode?

[comfreak]

Does that mean that if a system doesn't respond to any of these ports that it's safe from this vulnerability or can it still be exploited locally?

[Michael Mol]

Mitigation on laptops can take the form of using USB NICs instead of built-in.

[wurtel]

You write "note that AMT can work over wi-fi, at least on Windows". I thought that this vulnerability worked independently of the OS?

[Stephen Kitt]

@wurtel the vulnerability is OS-independent on wired interfaces, but on wi-fi AMT appears to need cooperation from the running OS’s driver: it doesn’t intercept packets, it relies on the OS forwarding appropriate packets to it (as I understand it — note that I haven’t tested this side of things).

[Stephen Kitt]

@dolmen Matthew Garrett has released a tool to check your local system, see my update.