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
