[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250306033000.GA4987@openwall.com>
Date: Thu, 6 Mar 2025 04:30:00 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Tavis Ormandy <taviso@...il.com>
Subject: Re: AMD Microcode Signature Verification Vulnerability
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
