oss-sec
mailing list archives
From: Solar Designer <solar () openwall com>
Date: Tue, 4 Feb 2025 11:10:28 +0100
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.
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
AMD: Microcode Signature Verification Vulnerability
sirdarckcat published GHSA-4xq7-4mgh-gp6w Feb 3, 2025
Package
AMD CPUs
Affected versions
Zen 1-4 CPUs
Patched versions
Naples/Rome/Milan PI 2024-12-13 and Genoa 2024-12-16
Description
Summary
Google Security Team has identified a security vulnerability in some AMD
Zen-based CPUs. This vulnerability allows an adversary with local
administrator privileges (ring 0 from outside a VM) to load malicious
microcode patches. We have demonstrated the ability to craft arbitrary
malicious microcode patches on Zen 1 through Zen 4 CPUs. The
vulnerability is that the CPU uses an insecure hash function in the
signature validation for microcode updates. This vulnerability could be
used by an adversary to compromise confidential computing workloads
protected by the newest version of AMD Secure Encrypted Virtualization,
SEV-SNP or to compromise Dynamic Root of Trust Measurement.
AMD SEV-SNP users can verify the fix by confirming TCB values for SNP in
their attestation reports (can be observed from a VM, consult AMD's
security bulletin for further details).
Severity
HIGH - Improper signature verification in AMD CPU ROM microcode patch
loader may allow an attacker with local administrator privilege to load
malicious CPU microcode resulting in loss of confidentiality and
integrity of a confidential guest running under AMD SEV-SNP.
Proof of Concept
A test payload for Milan and Genoa CPUs that makes the RDRAND
instruction return 4 can be downloaded here (applying it requires the
user to be root from outside of a VM).
Timeline
Date reported: September 25, 2024
Date fixed: December 17, 2024
Date disclosed: February 3, 2025
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
Credits
@josheads josheads Finder
@spq spq Finder
@matrizzo matrizzo Finder
@sirdarckcat sirdarckcat Finder
@taviso taviso Finder
There's a PoC in:
https://github.com/google/security-research/tree/master/pocs/cpus/entrysign
Tested on AMD EPYC 7B13 64-Core Processor (Milan) and AMD Ryzen 9 7940HS
w/ Radeon 780M Graphics (Phoenix).
We've provided these PoCs to demonstrate that this vulnerability allows
an adversary to produce arbitrary microcode patches. They cause the
RDRAND instruction to always return the constant 4, but also set the
carry flag (CF) to 0 to indicate that the returned value is invalid.
Because correct use of the RDRAND instruction requires checking that CF
is 1, this PoC can not be used to compromise correctly functioning
confidential computing workloads. Additional tools and resources will be
made public on March 5.
The corresponding AMD security bulletin is:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html
AMD SEV Confidential Computing Vulnerability
AMD has made available a mitigation for this issue which requires
updating microcode on all impacted platforms to help prevent an attacker
from loading malicious microcode. Additionally, an SEV firmware update
is required for some platforms to support SEV-SNP attestation. Updating
the system BIOS image and rebooting the platform will enable attestation
of the mitigation. A confidential guest can verify the mitigation has
been enabled on the target platform through the SEV-SNP attestation
report.
Alexander
Current thread: