Matthew Garrett

There's two classes of vulnerability disclosed. One is in the Intel AMT component, which runs on ME and is restricted to "enterprise" hardware (which includes higher end laptops), the other is arbitrary ME execution and applies to the entire product range.

The AMT vulnerabilities "only" permit code execution in the context of AMT. That means at least all the capabilities of AMT, but potentially more besides.

One of AMT's features is allowing a user to VNC into a system without the OS being involved. Doing this draws a warning border around the screen to alert the user. Unclear whether that's hardware or not - if not, this could allow silent observation of affected systems.

AMT also allows secure boot to be disabled for one-shot boots, so AMT compromise is probably also a complete secure boot compromise

The ME compromise presumably gives you everything the AMT compromise gives you, plus more. If you compromise the ME kernel you compromise everything on the ME. That includes AMT, but it also includes PTT.

PTT is Intel's "Run a TPM in software on the ME" feature. If you're using PTT and someone compromises your ME, the TPM is no longer trustworthy. That probably means your Bitlocker keys are compromised, but it also means all your remote attestation credentials are toast.

Worst case there is that an attacker is able to obtain the EK credentials from PTT. Unless there's a way to generate a new EK (and a new EK certificate), you can no longer ever trust remote attestation from that system.

Of course, once someone's in the ME they're able to do anything the ME can do. Even if your system doesn't have AMT, they can do everything that AMT can do - including scraping the screen, injecting input events, disabling secure boot and so on.

But the big thing that influences whether this is very bad but manageable or whether it's "This hardware can never be trusted again" is whether it's persistent or not. ME firmware is signed. Even with ME access, it shouldn't be possible to replace the ME firmware.

However, if the exploit is in unsigned data that's interpreted by the ME, an attacker could potentially modify that data and rexploit it on every ME boot. At that point they can disable Boot Guard and have full control of system firmware as well.

If that happens? Only remediation path is to re-flash SPI by hand, because every internal root of trust is now under the control of the attacker. Probably cheaper for most companies to buy new hardware instead.