freax13/cve-2024-21980-pocExploit für CVE-2024-21980, der auf die AMD-SEV-Firmware abzielt, um beliebigen Speicher von stillgelegten SEV-SNP-Gästen über eine Umgehung der Befehlsprüfung zu entschlüsseln.
Dieses Repository enthält einen Exploit für eine Schwachstelle in der SEV-Firmware. Der Exploit ermöglicht es, beliebigen Speicher eines SEV-SNP-Gasts zu entschlüsseln, nachdem dieser außer Betrieb genommen wurde.
Getestet mit Version 1.55.16 (zum Zeitpunkt des Schreibens die neueste Version).
Die SEV-Firmware enthält eine Tabelle namens master_handler_table mit Funktionszeigern für alle Befehle sowie einigen weiteren Eigenschaften, die für die Befehle relevant sind. Zwei dieser zusätzlichen Eigenschaften sind cmd_buf_type und snp_cmd_buf_enforcement. cmd_buf_type bestimmt, ob der Befehlsbuffer in den Hostspeicher kopiert und/oder daraus kopiert werden soll. snp_cmd_buf_enforcement bestimmt, ob diese Kopiervorgänge Prüfungen unterliegen, die sicherstellen, dass der Speicher, der den Befehlsbuffer hinterlegt, sich im Zustand FIRMWARE oder DEFAULT befindet. Befehle, bei denen cmd_buf_type entweder CMD_BUF_OUTPUT_ONLY, CMD_BUF_INPUT_AND_OUTPUT oder CMD_BUF_INPUT_AND_OUTPUT_ERROR ist, sollten alle snp_cmd_buf_enforcement auf true gesetzt haben. Andernfalls könnte das Zurückschreiben der Befehlsausgabe zu Speicherkorruption innerhalb des von der RMP abgedeckten Bereichs führen. snp_cmd_buf_enforcement ist für alle diese Befehle auf true gesetzt, mit einer Ausnahme – SEV_MCMD_ID_ATTESTATION: Dieser Befehl hat cmd_buf_type auf CMD_BUF_INPUT_AND_OUTPUT_ERROR gesetzt, aber snp_cmd_buf_enforcement ist ebenfalls auf false gesetzt. Dadurch ist es möglich, SEV_MCMD_ID_ATTESTATION mit einem Befehlsbuffer auszuführen, der auf von der RMP abgedeckten Speicher zeigt, und diesen Speicher zu korrumpieren, sobald die Ausgabe zurückgeschrieben wird.
Ich sehe nicht, warum SEV_MCMD_ID_ATTESTATION eine Ausnahme sein müsste; es erscheint mir plausibel, dass dies ein Tippfehler/Kopier-und-Einfüge-Fehler sein könnte.
SEV_MCMD_ID_ATTESTATION schreibt nur in ein einzelnes Feld length (4 Bytes) im Befehlsbuffer, und daher sind dies die einzigen Bytes, die wir zur Speicherkorruption verwenden können. SEV_MCMD_ID_ATTESTATION schreibt immer denselben Wert – 0x000000d0. Glücklicherweise gibt es keine Ausrichtungsanforderungen an den Befehlsbuffer, sodass wir den Befehlsbuffer wiederholt verschieben können, um einen größeren Bereich zusammenhängenden Speichers zu korrumpieren. Wir werden dies nutzen, um die ersten 16 Bytes einer Gastkontextseite mit einem statischen Muster zu korrumpieren. Diese ersten 16 Bytes enthalten den UMC-Schlüsselsamen, und indem wir ihn auf einen statischen Wert erzwingen, können wir den Verschlüsselungsschlüssel des Gasts auf einen statischen Wert erzwingen.
Der hier bereitgestellte Exploit basiert stark auf dem, den ich für SWPSIRT-2684/CVE-2023-31355 bereitgestellt habe.
Um die Schwachstelle auszunutzen, können wir die folgenden Schritte ausführen:
SEV_MCMD_ID_ATTESTATION erforderlich. Lassen Sie diesen Gast weiterlaufen.0x2000 für den Opfer-Gast. Jede andere Adresse im von der RMP abgedeckten Bereich würde ebenfalls funktionieren, obwohl eine feste Adresse für die Fehlersuche nützlich ist.0x2000 für den Angreifer-Gast. Dies muss dieselbe Adresse sein, die in Schritt 1 verwendet wurde.SNP_DBG_ENCRYPT, um den Speicher des Opfer-Gasts mithilfe der Kontextseite des Angreifer-Gasts zu entschlüsseln. Dies wird gelingen, weil der Opfer-Gast und der Angreifer-Gast denselben UMC-Schlüsselsamen teilen.Die Auswirkungen hier sollten mindestens dieselben sein wie bei SWPSIRT-2684. Es ist mir derzeit nicht klar, ob dieser Fehler verwendet werden kann, um den Speicher eines laufenden Gasts zu entschlüsseln, bevor dieser außer Betrieb genommen wurde.
snp_cmd_buf_enforcement sollte für SEV_MCMD_ID_ATTESTATION auf true gesetzt werden.
Interessanterweise müssen die Linux-KVM-Host-Support-Patches nicht aktualisiert werden, da sie SEV_CMD_ATTESTATION_REPORT bereits in sev_cmd_buf_writable als einen Befehl auflisten, der erfordert, dass sich sein Befehlsbuffer im Zustand FIRMWARE befindet. Änderungen können für andere Hypervisoren erforderlich sein oder auch nicht.