In regards to the 2017-11-20 Intel MEI/AMT vulnerability can someone explain the specifics of this terminology: "allows attacker with remote Admin access to the system to execute arbitrary code"? Does this mean to exclude any kind of remote exploit such as using specially crafted network packets?

I've seen this CVE marked as a remote exploit on some websites, but looking at the explanation it actually seems like this requires local access (as root/Administrator) to exploit. I realize something like a Windows Domain Admin would fit the bill as "remote Admin" with local access but how does this apply to a Linux system where there is no root (Admin) access allowed remotely?

  • I believe it means admin privileges for AMT. The ones that require local access are labeled as "local" (whether or not it needs ring 0 or ring 3, I don't know).
    – guest
    Nov 25, 2017 at 9:24

1 Answer 1


In the context of Linux, if one obtains root via a privilege escalation exploit, they may deploy a rootkit via AMT or make other system modifications that one won't be able to evidence/remove by trivial OS fixes.

The scenario is:

  1. An attacker gains remote code execution within the context of your web server (e.g. www-data or a user Apache runs at, or pick your favorite web server). At this point you should be able to identify these events in your logs and figure out how did they access the system, and potentially recover/patch/remove backdoors.

  2. Via a privilege escalation vulnerability, they gain root/UID=0 privilege. Still, logs may be available, and you may be able to patch/recover.

  3. They exploit the AMT/IMT vulnerability and gain AMT execution. At this point you lose any regular visibility to as what have they done at AMT level, and they may use this access to install a backdoor or rootkit that may be really difficult to discover/detect or eradicate.

The temporal score for you may not be the same as a unauthenticated RCE, depending on the context of the system, so I'd say it is a medium criticality vulnerability.

Case #3 applies also to authenticated attackers that may want to gain persistent access or mask their activities in a way that would not be visible to you via a SIEM/remote syslog or other means.

I hope this helps clear the issue.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .