Intel AMT vulnerability

Read the mjg59 summary first

taggart notes

“The easiest way to programmatically determine if a machine has AMT available would be to look for the presence of the MEI device in the PCI config space. If the system has a device at Bus:0, Device:3, Func:0; then the system is a vPro system. If that device is all FFs, then the system is a non-vPro system.” <- probably system specific, I couldn’t repeat

debian packages that might be interesting

amtterm – Serial-over-lan (sol) client for Intel AMT, console version NOTE: replaced by wsmancli (see
gamt – Serial-over-lan (sol) client for Intel AMT, gtk version NOTE: replaced by wsmancli (see
nvramtool – Read/write coreboot-related NVRAM/CMOS information
iucode-tool – Intel processor microcode tool
inteltool – Dump Intel CPU / chipset configuration parameters NOTE: only helps determine north/southbridge, no help
intel-microcode – Processor microcode firmware for Intel CPUs

Debian versions as of May 1, 2017:

 intel-microcode | 1.20140913.1~bpo60+1       | squeeze-backports/non-free
 intel-microcode | 1.20150121.1               | wheezy/non-free
 intel-microcode | 3.20161104.1~deb8u1~bpo7+1 | wheezy-backports/non-free
 intel-microcode | 3.20161104.1~deb8u1        | jessie/non-free
 intel-microcode | 3.20161104.1~bpo8+1        | jessie-backports/non-free
 intel-microcode | 3.20161104.1               | stretch/non-free
 intel-microcode | 3.20161104.1               | sid/non-free

Upstream is currently here and is version 20161104


From the mitigation document, the list of ports is as follows:

16992, 16993, 16994, 16995, 623, and 664.

We can easily see if those are open anywhere.


This page was started when the first major AMT vuln came out in May 2017. I determined that none of our systems were vulnerable here. Then there were more AMT vulnerabilities, mjg59 has a good summary. Because we don’t have it enabled, we’re still OK. But this is probably a good reason to avoid all newer Intel hardware, way too much secret code running in the CPU.