SEV Firmware Vulnerability

This repo contains an exploit for a vulnerability in the SEV firmware. The exploit allows decrypting arbitrary memory of a running SEV-SNP guest.

Tested on version 1.55.16 (latest as of the time of writing).

Root Cause

The nv_paddr field of the SEV_INIT_EX command can be used to donate a chunk of memory to the firmware, so that it can be used instead of the persistent flash. If SEV-SNP is enabled, this memory has to be in the FIRMWARE state. The firmware checks this once while executing the SEV_INIT_EX command. From thereon after, the firmware assumes that this memory is in the FIRMWARE state and writes to it without any additional checks. The assumption that the memory is still in the FIRMWARE state is not always correct, nothing prevents the host from changing the state back to the HYPERVISOR state using the SNP_PAGE_RECLAIM command. Once the pages are in the HYPERVISOR state they can be transitioned into other states e.g. CONTEXT. Even though the pages are no longer in the FIRMWARE state, the firmware will write to those pages thus breaking the integrity required by certain page states.

Exploit

We can exploit this memory corruption by targeting CONTEXT pages. CONTEXT pages are powerful target, but there are some problems:

1. CONTEXT pages are encrypted with a key than other memory. As a result, it's not easy to control the plaintext even if we could control the ciphertext.
2. We don't have a lot of control of the memory written by the firmware.

The memory corruption effectively fills the CONTEXT page with random data, so it's not easy to actually corrupt CONTEXT pages in such a way that it's useful for the attacker. To work around that, we can repeatedly trigger the bug to cause corruption and use the SNP_GUEST_STATUS command the read back relevant fields of the corrupted CONTEXT page until we observe values that are useful.

The SNP_DBG_DECRYPT command can be used to decrypt the memory of a SEV-SNP guest with the DEBUG policy enabled. If we can craft a CONTEXT so that it has the DEBUG flag set and contains the ASID of another guest, we can use it to decrypt the memory of the other guest even though it doesn't have DEBUG policy set.

It turns out that SNP_DBG_DECRYPT ignores most fields in the CONTEXT page, it only checks gctx->guest.asid, gctx->guest.policy_snp and gctx->guest.guest_flags. The chance of these fields being correct after the memory corruption is not high, but it's also not out of the realm of possibility. The good news is also that we can read all of those fields using the GUEST_STATUS command.

In conclusion, we can exploit the bug with the following steps:

1. Transition nv_paddr into the FIRMWARE state using the rmpupdate instruction.
2. Execute the SEV_INIT_EX command.
3. Transition nv_paddr back into the HYPERVISOR state using the SNP_RECLAIM_PAGE command.
4. Create one or more CONTEXT pages at nv_paddr.
5. Trick the firmware into writing to nv_paddr using the SEV_PDH_GEN command. This corrupts the CONTEXT pages.
6. Use the GUEST_STATUS command to check whether SNP_DBG_DECRYPT would succeed, if not go back to step 5. The main bottleneck here is that ASIDs are stored in a 32-bit int, but there are way fewer valid ASIDs (509 or 1006 depending on the CPU), so it will take quite a lot of attempts to get this right.
7. Launch (and optionally run) a victim guest using the corrupted ASID in the corrupted CONTEXT page. Keep track of the secrets page. This is possible because the SEV firmware tracks active ASIDs internally and doesn't check the active CONTEXT pages to check for duplicates.
8. Use the corrupted CONTEXT page to execute SNP_DBG_DECRYPT on the secrets page of the victim guest.

The exploit spends most of its time on steps 5 and 6. The chances of hitting all the right conditions are about 1/20,000,000 on an EPYC Milan and we can do about 100 attempts per second, so we expect to hit the right conditions about once every two days (Warning: the calculations are only approximations and I may have messed something up, but anecdotally, once every two days feels about right). We can speed this up by not just attacking one CONTEXT page at a time, but three CONTEXT pages at nv_paddr, nv_paddr+4096, and nv_paddr+8192 (SEV_PDG_GEN will corrupt three pages). Conveniently those steps can be done ahead of launching the victim guest and only have to succeed once to attack an arbitrary number of guests (note that the PoC currently attacks just one guest though).

Impact

Although I haven't been able to test this yet, I believe that once an attacker has used this vulnerability to leak the guest's virtual machine platform communication keys, she should be able to send guest messages to the firmware on the guest's behalf and use this to request attestation reports. This violates a key principle of SEV-SNP in which only the guest should be able to request attestion reports.

Mitigation

A few commands (e.g. SNP_RECLAIM_PAGE, SNP_GCTX_CREATE, RING_BUFFER, maybe more?, maybe all just to be safe?) that accept a FIRMWARE page should check whether it overlaps with nv_paddr and fail if it does.

Upgrade Mitigations

There's one more concern I have, which I'm not sure is valid and would love to hear y'all's opinion on: IIUC the SEV firmware can be upgraded without interrupting running guests. This implies to me that it would be possible to carry over the corrupted CONTEXT page from an old vulnerable firmware version to a new fixed firmware version. Would it be possible to start on an older vulnerable version, do the exploit described above, upgrade and commit the new fixed firmware, launch the guest with the new firmware (so that the old firmware version doesn't show up in the attestation report) and then use the corrupted CONTEXT page created using the old firmware to attack the guest creating using the new version? Would a consumer of the attestion reports created by the new guest be able to tell that the old firmware version was running at some point before the new guest was launched? If not, are further mitigations required to prevent this from happening?

PoC Usage