#1099830 amd64-microcode: CVE-2024-36347 weak microcode update validation

Package:
amd64-microcode
Source:
amd64-microcode
Submitter:
Markus Koschany
Date:
2025-03-08 16:09:03 UTC
Severity:
normal
Tags:
#1099830#5
Date:
2025-02-08 09:53:37 UTC
From:
To:
Hi,

The following vulnerability was published for amd64-microcode.

CVE-2024-56161[0]:
| 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.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-56161
https://www.cve.org/CVERecord?id=CVE-2024-56161

Please adjust the affected versions in the BTS as needed.

Regards,

Markus

#1099830#10
Date:
2025-03-06 10:59:56 UTC
From:
To:
Control: severity -1 grave

The Google Security Team has now released a tool [1] with which the
microcode can be manipulated, and the key has been leaked [2] (or rather
it was public anyway, but was now identified as the key being re-used
here).

I think a bump to grave is warranted, but it should be serious at least.

I have Zen 2, 3, 5 consumer CPUs at home, if I can help with testing.

Best,
Christian


[1]: https://github.com/google/security-research/blob/master/pocs/cpus/entrysign/zentool/README.md
[2]: https://www.openwall.com/lists/oss-security/2025/03/06/2

#1099830#21
Date:
2025-03-08 12:36:41 UTC
From:
To:
I will keep this open for a little while, and try to ask AMD about it directly, but expect either bad news, or extremely bad news for anyone that is not in a position to get a new firmware from their vendor or from a third-party (or build a new one themselves by replacing the AMD PI / AGESA with updated ones).
#1099830#26
Date:
2025-03-08 15:56:25 UTC
From:
To:
retitle 1095470  amd64-microcode: CVE-2024-56161 updated AMD-SEV FW needed to pass attestation
severity 1095470 important
clone 1095470 -1
tag 1095470 + fixed-upstream
retitle -1  amd64-microcode: CVE-2024-36347 weak microcode update validation
tag -1 = upstream security wontfix
severity -1 important
thanks

Please let me clarify some details.  If this is incorrect, please provide pointers to the relevant documentation/artifacts:

There is NO *operating-system-loadable* microcode update available from AMD to address the root issue (weak microcode validation) at this time.   And public documentation states the root-cause fix must be done through a system firmware (UEFI) update.

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html

Maybe this will change, and if it doesn't, maybe lesser mitigations (such as blocking further microcode updates) will become available: I understand running a minimal kernel-monitor secure hypervisor should be able to block the MSR writes that trigger a microcode update, for example.

So, AMD-SB-7033 / CVE-2024-36347 is unactionable by package amd64-microcode at this time.

I will clone the bug to split the two CVEs into their own bugs, and tag the one for CVE-2024-36347 "wontfix" accordingly.  I will also downgrade its severity to "important", since unactionable grave bugs can block actionable fixes from propagating to testing, etc.  Should the situation change (hopefully it will), we can revisit this.


Now, for CVE-2024-56161, which is the AMD-SEV side of the issue.

There is a pending AMD-SEV loadable firmware update from 2025/02/29, and I will package it soon (but I'd rather hear back from AMD about a few details, first).  However, I understand from AMD SB-3019 that the SEV firmware update will just ensure that SEV remote attestation can succeed on updated firmware.  It is relevant for CVE-2024-56161, yes, but it is NOT FIXING the underlying issue at all.

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html

Note that CVE-2024-56161 is mitigated by ensuring no SEV payload attestation can succeed on outdated firmware (and you don't need to do anything for THAT: the SEV payload providers are already on it), and by allowing attestation to succeed on updated firmware.

What is missing in Debian is a way for SEV payloads to pass attestation *on systems with updated firmware*, and THAT is what the pending  SEV firmware update is about.  I changed the bug title accordingly.

Since AMD-SEV is *not* officially supported in Debian anyway, I will downgrade the SEV bug to severity to important as well.

More information about  AMD-SEV:
https://www.amd.com/en/developer/sev.html