AMD CacheWarp Vulnerability Afflicts Previous Gen EPYC Server CPUs, Patch Issued

Ryzen 7 5800X3D
(Image credit: AMD)

AMD and Graz University of Technology researchers have disclosed a new vulnerability in AMD CPU called CacheWarp, or CVE-2023-20592 (via ComputerBase). This attack exploits a security feature in EPYC server CPUs that's supposed to make them resistant to hacks. The vulnerability affects first through third generation EPYC CPUs (Naples, Rome, and Milan), but AMD has only made a microcode patch for third generation Milan chips.

Secure Encrypted Virtualization (or SEV) is an exclusive security feature for EPYC CPUs that's intended to make virtual machines more secure by encrypting each VM's memory with a key. Ironically, it's SEV itself that makes CacheWarp possible and EPYC CPUs thus exploitable. This isn't the first time SEV has been exploited but CacheWarp is more critical as it doesn't require physical access to a PC.

The CacheWarp exploit is triggered by wiping the CPU's cache using the INVD instruction, which leaves the CPU with outdated data stored in system memory or RAM. The CPU will then read the data from the RAM and assume it's brand-new when it's actually not.

The crucial thing that the CPU reads is the value for authentication, which needs to be 0 in order to successfully authenticate. Entering the correct passkey is supposed to be the only way to get the value to be 0, but it turns out the initial value is also 0, which is why sending the CPU effectively back in time is a big security hole.

Although this exploit impacts first, second, and third generation EPYC processors, only third generation EPYC Milan chips are getting new microcode with the CacheWarp vulnerability patched out. In a statement to Computerbase, AMD claims that a patch isn't necessary for first and second generation CPUs as "SEV and SEV-ES features are not intended for protection."

Unlike many other patches, AMD says there should be no performance impact with the patch enabled. This is expected since CacheWarp doesn't hinge on speculative execution like Spectre, which has been patched at the expense of performance.

Matthew Connatser

Matthew Connatser is a freelancing writer for Tom's Hardware US. He writes articles about CPUs, GPUs, SSDs, and computers in general.

  • The Historical Fidelity
    Kinda seems like a big oversight to make the default condition of the anti-hack feature the correct value to pass the authentication challenge….
    Reply
  • rluker5
    Also an oversight to not release the patch for the first two gens of Epyc since it doesn't hurt performance.

    That's worse than Intel APO for just 14th gen since it seems they are holding an active remote authentication exploit stick as a motivation to upgrade.

    It can't cost that much just to release a microcode update for the other two gens since they are already doing it for the third.
    Reply
  • bit_user
    rluker5 said:
    It can't cost that much just to release a microcode update for the other two gens since they are already doing it for the third.
    You have no idea how much resemblance there is between the microcode of those cores. Don't assume all they have to do is "recompile" the fix for earlier CPUs. Furthermore, any fix needs to be validated, all of which takes resources that would probably have to be pulled off of other tasks.

    IMO, the main reason they're not patching older CPUs is that it's just not a very bad vulnerability. Memory should already be getting zero'd by the OS, before it can be used by another process.
    Reply
  • rluker5
    bit_user said:
    You have no idea how much resemblance there is between the microcode of those cores. Don't assume all they have to do is "recompile" the fix for earlier CPUs. Furthermore, any fix needs to be validated, all of which takes resources that would probably have to be pulled off of other tasks.

    IMO, the main reason they're not patching older CPUs is that it's just not a very bad vulnerability. Memory should already be getting zero'd by the OS, before it can be used by another process.
    It is true I don't know how much work it is to update the microcode.

    And it doesn't seem bad for those not using a public VM. But from the whitepaper: "Cloud providers, such as Microsoft Azure, Google Cloud, and Amazon Web Services already support AMD SEV" and "In 3 case studies, we demonstrate an attack on RSA in the Intel IPP crypto library, recovering the entire private key, logging into an OpenSSH server without authentication, and escalating privileges to root via the sudo binary. While we implement a software-based mitigation proof-of-concept, we argue that mitigations are difficult, as the root cause is in the hardware."

    This is only a problem, apparently if the hypervisor has been compromised, or if an organization is required to run a trusted VM(s) and wants to use an untrusted hypervisor.

    And as far as the first two gens of Epyc, per Tom's article: " In a statement to Computerbase, AMD claims that a patch isn't necessary for first and second generation CPUs as "SEV and SEV-ES features are not intended for protection."" BUT per AMD: https://www.amd.com/en/developer/sev.html that is not true and AMD SEV is used in those gens and you can download the tools to do it in the link I provided.

    There may be organizations that are required to run trusted VMs that may no longer be able to do so on servers that run on those first 2 gens of Epyc. Is someone going to let them know?

    I hope I don't have money or available credit in one of them.

    Edit: So it is an oversight to not have released the patch for the first 2 gens as well. It looks better at least.
    Reply