6

Several of the latest Intel Management Engine vulnerabilities are listed as local vulnerabilities, allowing code executing on the system to elevate its privileges to ME context. One of them (CVE-2017-5708) claims it allows an unauthorized process to access privileged content via unspecified vector. This gives no hints as to what is required to exploit it. I am specifically curious about the privilege escalation or information leak vulnerabilities.

To the best of my knowledge, on a system running the ME, assuming AMT is unprovisioned, userspace can only interact with the ME via HECI. This requires privileged instructions, so it can only be done by the kernel (or root via the kernel). Can any of these vulnerabilities be exploited entirely in userspace, using only unprivileged instructions? This is what makes the difference between this being really nasty, but overblown, and this being a full-scale disaster.

The CVSSv3 vector scoring says that CVE-2017-5708 requires "low privileges" (PR:L), but gives no further details (while a Cisco advisory says the attack requires access to a privileged user). The same is true for CVE-2017-5710, but that one is an exploit against Intel TXT, which, to the best of my knowledge, only adds privileged instructions.

Could a low-privilege process running as an isolated user exploit any of these vulnerabilities to gain higher privileges or read valuable information, assuming no vulnerabilities in the kernel, and assuming the MEI and TEXI drivers are not present? A few sources like The Register seem to explicitly say that a high privileged process can exploit these vulnerabilities, but they do not explain where they got that information from. According to the CSSv3 specifications document, PR:L is designated for attacks that require only basic user privileges, whereas PR:H requires "significant" privileges, such as administrative privileges. This makes it seem like the attack works as a regular user, in ring 3, but it conflicts with the other sources above (as well as my limited understanding of the methods of communication with the ME).

According to one of the people who discovered one of these vulnerabilities, the vector lies "somewhere in between" access to /dev/mei0 and access via a flash programmer. I'm not sure if he is implying simply that the vector is different, or if it requires more privilege than access to the character device, but less than that provided by physical access and a flash programmer. A discussion on IRC revealed that the original vulnerability may be related to improper configuration of the P2SB PCI bridge on Intel Series 100 chipsets (the Skylake PCH), but the specific implications seem ambiguous (not to mention, that is for only the first vulnerability disclosed, the one to be discussed at the upcoming BHEU talk, not any of the others discovered by the internal Intel audit).

Can an unprivileged user in ring 3 exploit any of these vulnerabilities?

forest
  • 64,616
  • 20
  • 206
  • 257

1 Answers1

1

Quoting directly from the IME firwmare update notes, if the attacker does not have physical access to the plaform to do a firmware flash, then they cannot do anything if the recommended flash descriptor write protections have been enabled. If they haven't, then the attackers needs ring 0 access to the kernel, where an attacker can exploit the vulnerabilities by applying the malicious firmware through malicious driver software. It can also be exploited remotely if the user has valid IME admin credentials, otherwise it isn't.

I came across this question whilst asking a question on Ring -3 exploits and existence of other rings

LTPCGO
  • 965
  • 1
  • 5
  • 22
  • So `PR:L` seems to have been a mistake? – forest Sep 05 '19 at 07:15
  • @forest I'm not sure how NIST scores vulnerabilities, but given the but can be exploited via physical access and thus no software privileges are needed, which might be the reason why. The bug is waiting to be reviewed too, if that ever happens perhaps it will be changed. But yes, if it's not either of those things it must be a mistake! – LTPCGO Sep 05 '19 at 09:55