Re: AMD Microcode Signature Verification Vulnerability

[Solar Designer <solar () openwall com>]

On Tue, Feb 04, 2025 at 11:10:28AM +0100, Solar Designer wrote:
> On Wed, Jan 22, 2025 at 07:52:48AM -0800, Tavis Ormandy wrote:
> > On Tue, Jan 21, 2025 at 11:38:16PM -0500, Demi Marie Obenour wrote:
> > > On Tue, Jan 21, 2025 at 06:31:31PM -0800, Tavis Ormandy wrote:
> > > > It looks like an OEM leaked the patch for a major upcoming CPU
> > > > vulnerability, i.e. "AMD Microcode Signature Verification
> > > > Vulnerability":
> > > >
> > > > https://rog.asus.com/motherboards/rog-strix/rog-strix-x870-i-gaming-wifi/helpdesk_bios/
> > > >
> > > > I'm not thrilled about this - the patch is *not* currently in
> > > > linux-firmware, so this is the only publicly available patch.

Tavis also posted a screenshot to Twitter at the time, from which it
could be seen that ASUS had indeed listed a relevant change in there.
That mention was deleted from the web page within a day or so.

> > > > However, other people are discussing how to extract them:
> > > >
> > > > https://winraid.level1techs.com/t/offer-intel-amd-via-cpu-microcode-archives-1995-present/102857/53
> > >
> > > Is this fix effective, or can it be bypassed via a downgrade attack?
> >
> > I'm not sure yet, the vendor has been really excruciating to deal with,
> > this is the first time I've been allowed to see the patch!! :(
>
> Much of the info is finally public (with more planned for March):
>
> https://github.com/google/security-research/security/advisories/GHSA-4xq7-4mgh-gp6w

> > Google notified AMD of this vulnerability on September 25, 2024. AMD
> > subsequently provided an embargoed fix to its customers on December 17,
> > 2024. To coordinate with AMD, we made a one-off exception to our
> > standard vulnerability disclosure policy and delayed public disclosure
> > until today, February 3, 2025. This joint disclosure occurs 46 days
> > after AMD shared the fix with its customers and 131 days after Google's
> > initial report. Due to the deep supply chain, sequence and coordination
> > required to fix this issue, we will not be sharing full details at this
> > time in order to give users time to re-establish trust on their
> > confidential-compute workloads. We will share additional details and
> > tools on March 5, 2025.
>
> > CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N
> > CVE-2024-56161

As mentioned in a Xen Security Notice in here earlier today:

https://www.openwall.com/lists/oss-security/2025/03/05/3

the Google team did in fact "share additional details and tools" now:

https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking
https://github.com/google/security-research/tree/master/pocs/cpus/entrysign/zentool
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html

This is an exciting read with a lot of detail, but for this posting I'll
focus on what the vulnerability and its fix are:

> The root cause of the EntrySign vulnerability is that the AMD Zen
> microcode signature verification algorithm uses the CMAC function as a
> hash function; however, CMAC is a message authentication code and does
> not necessarily provide the same security guarantees as a cryptographic
> hash function.

> The weakness of using CMAC as a hash function is that anyone who has the
> encryption key is able to observe the intermediate values of the
> encryption and calculate a way to "correct" the difference so that the
> final output remains the same, even if the inputs are completely
> different.

> Secure hash functions are designed in such a way that there is no secret
> key, and there is no way to use knowledge of the intermediate state in
> order to generate a collision. However, CMAC was not designed as a hash
> function, and therefore it is a weak hash function against an adversary
> who has the key. Remember that every AMD Zen CPU has to have the same
> AES-CMAC key in order to successfully calculate the hash of the AMD
> public key and the microcode patch contents. Therefore, the key only
> needs to be revealed from a single CPU in order to compromise all other
> CPUs using the same key. This opens up the potential for hardware
> attacks (e.g., reading the key from ROM with a scanning electron
> microscope), side-channel attacks (e.g., using Correlation Power
> Analysis to leak the key during validation), or other software or
> hardware attacks that can somehow reveal the key. In summary, it is a
> safe assumption that such a key will not remain secret forever.
>
> Forging On
> We noticed that the key from an old Zen 1 CPU was the example key of the
> NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588
> 09cf4f3c) and was reused until at least Zen 4 CPUs. Using this key we
> could break the two usages of AES-CMAC: the RSA public key and the
> microcode patch contents. We were able to forge new public keys which
> generated the same hash as the authentic AMD key. Additionally, we
> calculated collisions for signatures, and were able to generate a
> microcode patch that shares the same signature as another message that
> was legitimately signed.

> Vulnerability Mitigation
> 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.
> We plan to provide additional details in the upcoming months on how we
> reverse engineered the microcode update process, which led to us
> identifying the validation algorithms, extracting the CMAC key, and
> discovering some file format details.

Alexander