[coreboot] : AMT bug

[Trammell Hudson]

On Thu, May 11, 2017 at 10:08:12PM +0200, Igor Skochinsky wrote:
> TH> On Thu, May 11, 2017 at 10:30:48AM -0500, Allen Krell wrote:
> >> [...] There are multiple keys
> >>
> >> ME -  public/private key pair - Fused in by Intel and checked by Intel
> >> silicon - Probably different across models
> 
> It's a little simpler than that: the ME ROM has a hardcoded list of
> pubkey hashes and accepts ME manifests signed by any of them. I think
> (but haven't checked) that the keys change with each major ME version.

That makes sense and would require far less die space.

> TH> If an attacker can sign an ME binary, they can provide invalid fuses to
> TH> the CPU microcode so that it won't check the ACM key (or provide their
> TH> own bootguard key so that the TPM locality will be set for the IBB
> TH> measurement).
> 
> I'm don't think this is possible. the OEM keys (or rather, their hashes)
> are set in the data area of ME and are copied to the PCH/MCH fuses on
> first boot. These fuses are one-time programmable so can't be
> overwritten (supposedly) even if you manage to get ME codeexec.

You're right that the fuses are OTP, although my understanding (which is
not supported by any documentation and very well may be wrong) is that
the ME copies the bootguard profile and hashes to the x86 during the
reset initialization and that the x86 can't read them directly.
If this is the case, it would allow a ME binary to potentially copy
their own set of fuses to the host with a different policy or different
OEM hash.

If the x86 reset microcode reads the fuses directly, then this particular
attack would not be feasible.

> [...]
> In fact I think this is exactly the reason why flashing cleaned ME
> fails on BootGuard-protected systems - they check ME's hash (which ME provides
> in the PCI register space) and fail when it changes. Though that makes
> me wonder how they handle ME firmware updates...

This definitely requires further analysis.

-- 
Trammell