11–20 of 69 posts
The blog post that explains the exploit and how this whole thing works is at https://bughunters.google.com/blog/5424842357473280/zen-and-...
The blog post that explains the exploit and how this whole thing works is at https://bughunters.google.com/blog/5424842357473280/zen-and-...
Is the mitigation something that has to be installed on every system boot and only protects against microcode exploits later on that boot?
Earlier quoted context omitted.
The intro document mentions > Here's the thing - the big vendors encrypt and sign their updates so that you cannot run your own microcode. A big discovery recently means that the authentication scheme is a lot weaker than intended, and you can now effectively "jailbreak" your CPU! But there's no further details. I'd love to know about the specifics too!
They accidentally used the example key from AES-CMAC RFC, the full details are in the accompanying blog post: https://bughunters.google.com/blog/5424842357473280/zen-and-...
Would it be useful to have a public list of all example keys that could be accidentally used, which could be CI/CD tested on all publicly released firmware and microcode updates?
If there was a public test suite, Linux fwupd and Windows Update could use it for binary screening before new firmware updates are accepted for distribution to endpoints.
Earlier quoted context omitted.
Is the mitigation something that has to be installed on every system boot and only protects against microcode exploits later on that boot?
> The fix released by AMD modifies the microcode validation routine to use a custom secure hash function. This is paired with an AMD Secure Processor update which ensures the patch validation routine is updated before the x86 cores can attempt to install a tampered microcode patch.
This is not the first case of accidental reuse of example keys in firmware signing, https://kb.cert.org/vuls/id/455367 Would it be useful to have a public list of all example keys that could be accidentally used, which could be CI/CD tested on all publicly released firmware and microcode updates? If there was a public test suite, Linux fwupd and Windows Update could use it for binary screening before new firmware upd…
Using CMAC as both the RSA hashing function and the secure boot key verification function is almost the bigger WTF from AMD, though. That’s arguably more of a design failure from the start than something to be caught.
CPUs have no non-volatile memory -- microcode fully resets when the power is cycled. So, in a sensible world, the impact of this bug would be limited to people temporarily compromising systems on which they already had CPL0 (kernel) access. This would break (possibly very severely and maybe even unpatchably) SEV, and maybe it would break TPM-based security if it persisted across a soft reboot, but would not do much else of consequence.
But we do not live in a sensible world. The entire UEFI and Secure Boot ecosystem is a complete dumpster fire in which the CPU, via mechanisms that are so baroque that they should have been disposed of in, well, the baroque era, enforces its own firmware security instead of delegating to an independent coprocessor. So the actual impact is that getting CPL0 access to an unpatched system [0] will allow a complete compromise of the system flash, which will almost certainly allow a permanent, irreversible compromise of that system, including persistent installation of malicious microcode that will pretend to be patched. Maybe a really nice Verified Boot (or whatever AMD calls its version) implementation would make this harder. Maybe not.
(Okay, it's not irreversible if someone physically rewrites the flash using external hardware. Good luck.)
[0] For this purpose, "unpatched" means running un-fixed microcode at the time at which CPL0 access is gained.
Something worth noting: CPUs have no non-volatile memory -- microcode fully resets when the power is cycled. So, in a sensible world, the impact of this bug would be limited to people temporarily compromising systems on which they already had CPL0 (kernel) access. This would break (possibly very severely and maybe even unpatchably) SEV, and maybe it would break TPM-based security if it persisted across a soft reboot,…
Something worth noting: CPUs have no non-volatile memory -- microcode fully resets when the power is cycled. So, in a sensible world, the impact of this bug would be limited to people temporarily compromising systems on which they already had CPL0 (kernel) access. This would break (possibly very severely and maybe even unpatchably) SEV, and maybe it would break TPM-based security if it persisted across a soft reboot,…
SEV attestation does delegate to the PSP, no? I think it _might_ be reasonable to attest that upgraded microcode is both present and valid using SEV, without the risk of malicious microcode blinding the attestation, but I’m not positive yet - need to think on it a bit more.
I think that, at least on Intel, the “microcode” package includes all kinds of stuff beyond just the actual CPU microcode, and I think it’s all signed together. If AMD is like this, than an unpatched CPU can be made to load all kinds of goodies.
Also, at least in Intel (and I think also on AMD), most of the SPI flash security mechanism is controlled by SMM code. So any ranges that the CPU can write, unless locked by a mechanism outside of the control of whatever this bug compromises, can be written. This seems pretty likely to include the entire SPI chip, which includes parts controlling code that will run early after the next power cycle, which can compromise the system again.