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.
josheads Finder
spq Finder
matrizzo Finder
sirdarckcat Finder
taviso Finder
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.