• Bug#1095470: amd64-microcode: CVE-2024-56161

    From Henrique de Moraes Holschuh@21:1/5 to Christian Kastner on Sat Mar 8 13:50:01 2025
    On Thu, Mar 6, 2025, at 07:59, Christian Kastner wrote:
    Control: severity -1 grave

    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).

    --
    Henrique de Moraes Holschuh <hmh@debian.org>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Salvatore Bonaccorso@21:1/5 to Henrique de Moraes Holschuh on Sun Mar 9 08:20:01 2025
    Hi Nenrique,

    On Sat, Mar 08, 2025 at 12:56:25PM -0300, Henrique de Moraes Holschuh wrote:
    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

    Thanks for your analysis, I have tried to reflect the status in the security-tracker for both CVEs now.

    AFAIU, there are "stop-gap" mitigations in Kernel and Xen as well
    which are implemnted (and for the kernel they did already land in
    6.12.18 and 6.13.6):

    https://www.openwall.com/lists/oss-security/2025/03/06/3

    Regards,
    Salvatore

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)