Zenbleed-Technik

 (lock.cmpxchg8b.com)
2 Punkte von GN⁺ 2023-07-25 | 1 Kommentare | Auf WhatsApp teilen
  • Zenbleed ist eine Schwachstelle, die auf AMD-Prozessoren der Zen-2-Familie eine fehlerhafte Wiederherstellung eines fehlvorhergesagten vzeroupper ausnutzt, um Daten zu lesen, die im Vektorregistersatz desselben physischen Kerns zurückgeblieben sind
  • Die Schwachstelle ist als CVE-2023-20593 registriert; betroffen sind Zen-2-Produkte wie Ryzen 3000/4000/5000 with Radeon Graphics/7020 with Radeon Graphics, Ryzen PRO, Threadripper 3000 und EPYC „Rome“
  • Der Angriff funktioniert, wenn XMM Register Merge Optimization, Register Renaming und ein fehlvorhergesagtes vzeroupper innerhalb eines engen Zeitfensters aufeinanderfolgen; dadurch können selbst grundlegende Operationen wie strlen, memcpy und strcmp beobachtbar werden
  • Eine optimierte Variante kann pro Kern etwa 30 KB pro Sekunde exfiltrieren; problematisch ist dabei die gemeinsame Nutzung des Registersatzes auf demselben physischen Kern über Grenzen von VM, Sandbox, Container und Prozess hinweg
  • Empfohlen wird das Einspielen des AMD-Mikrocode-Updates; vorübergehend kann das DE_CFG[9]-Chicken-Bit gesetzt werden, was jedoch Performance kosten kann, und das bloße Deaktivieren von SMT reicht nicht aus

Welche Ausführungseinheit Zenbleed ins Visier nimmt

  • x86-64-CPUs besitzen 128-Bit-XMM-Vektorregister, die in modernen CPUs auf 256-Bit-YMM und 512-Bit-ZMM erweitert werden
  • Vektorregister werden nicht nur für numerische Berechnungen verwendet, sondern auch in Standard-C-Bibliotheksfunktionen wie strcmp, memcpy und strlen in glibc
  • Das AVX2-optimierte strlen in glibc kombiniert mehrere Vektorbefehle, um die Position des ersten nul-Bytes in einem String zu finden
    • vpxor xmm0,xmm0,xmm0 setzt den unteren Teil von ymm0 auf 0
    • vpcmpeqb ymm1,ymm0,[rdi] vergleicht die Bytes des Strings mit 0-Bytes
    • vpmovmskb eax,ymm1 überträgt das Vergleichsergebnis in ein allgemeines Register
    • tzcnt eax,eax berechnet die Position des ersten nul-Bytes

vzeroupper und der Registersatz

  • vzeroupper ist ein Befehl, der die oberen Bits von Vektorregistern auf 0 setzt
  • Wenn XMM- und YMM-Register gemischt verwendet werden, wird ein XMM-Register auf die volle Breite hochgestuft; dabei können Abhängigkeiten von den oberen Bits entstehen
  • glibc verwendet vzeroupper, um unnötige Stalls zu vermeiden und sicherzustellen, dass nachfolgende Ergebnisse nicht von oberen Bits abhängen
  • Die CPU legt Register nicht an festen physischen Positionen ab, sondern verwaltet die Zuweisung physischer Register über Register File und Register Allocation Table
  • Wenn ein XMM-Register auf 0 gesetzt wird, kann die CPU statt der tatsächlichen Bits ein z-bit-Flag in der RAT setzen
    • Dieses Flag kann unabhängig auf den oberen und unteren Teil eines YMM-Registers angewendet werden
    • vzeroupper kann das z-bit setzen und danach die entsprechenden Ressourcen im Registersatz freigeben

Die Schwachstelle bei der Wiederherstellung spekulativer Ausführung

  • Moderne CPUs verwenden spekulative Ausführung, daher müssen Operationen, die auf einem fehlvorhergesagten Branch ausgeführt wurden, rückgängig gemacht werden
  • Das Problem ist, dass bei der Wiederherstellung nach einem ausgeführten, aber fehlvorhergesagten vzeroupper das bloße Zurücksetzen des z-bit den Zustand der bereits freigegebenen Registersatz-Ressourcen nicht korrekt wiederherstellt
  • Durch präzises Scheduling lässt sich bei einigen Prozessoren erreichen, dass sie sich von einem fehlvorhergesagten vzeroupper ungenau erholen
  • Diese Technik ist CVE-2023-20593 und betrifft die gesamte Zen-2-Familie
    • AMD Ryzen 3000 Series Processors
    • AMD Ryzen PRO 3000 Series Processors
    • AMD Ryzen Threadripper 3000 Series Processors
    • AMD Ryzen 4000 Series Processors with Radeon Graphics
    • AMD Ryzen PRO 4000 Series Processors
    • AMD Ryzen 5000 Series Processors with Radeon Graphics
    • AMD Ryzen 7020 Series Processors with Radeon Graphics
    • AMD EPYC „Rome“ Processors

Angriffsbedingungen und Umfang des Datenabflusses

  • Um den Bug auszulösen, müssen XMM Register Merge Optimization, Register Renaming und ein fehlvorhergesagtes vzeroupper innerhalb eines präzisen Zeitfensters aufeinanderfolgen
  • Die beispielhafte Befehlssequenz verwendet folgende Struktur
    • vcvtsi2s{s,d} löst die Merge Optimization aus
    • vmovdqa löst Register Renaming aus
    • Ist der bedingte Branch actually taken, die CPU sagt aber den not-taken-Pfad voraus, wird vzeroupper fehlvorhergesagt ausgeführt und der Bug tritt auf
  • Da grundlegende Operationen wie strlen, memcpy und strcmp ebenfalls Vektorregister verwenden, können sie überall im System zum Beobachtungsziel werden
  • Weil auf demselben physischen Kern der Register File gemeinsam genutzt wird, sind auch andere VMs, Sandboxes, Container und Prozesse betroffen
  • Zwei Hyperthreads teilen sich denselben physischen Registersatz
  • Eine optimierte Angriffsvariante kann pro Kern etwa 30 KB pro Sekunde exfiltrieren, genug, um kryptografische Schlüssel und Passwörter angemeldeter Benutzer zu überwachen
  • Technische Hinweise und zugehöriger Code wurden in Googles security research repository veröffentlicht
  • Testcode wird für Linux bereitgestellt, aber der Bug hängt nicht von einem bestimmten Betriebssystem ab; betroffen sind daher alle Betriebssysteme

Entdeckungsmethode: CPU-Fuzzing und Oracle Serialization

  • Die Schwachstelle wurde durch Fuzzing entdeckt
  • Auch die CPU-Industrie führt zur Suche nach Hardwarefehlern nach der Siliziumfertigung eine Post-Silicon-Validierung durch
  • Anders als beim üblichen Coverage-basierten Fuzzing gibt es bei CPUs keine Metrik, die direkt einer Code Coverage entspricht
  • Stattdessen werden performance counters verwendet, um dem Fuzzer Feedback über interessante Architekturereignisse zu geben
    • So lassen sich Befehlssequenzen erkunden, die sich zufällig kaum finden ließen
    • Funktionen wie Merge Optimization konnten auf diese Weise automatisch entdeckt werden
  • Software-Fuzzing sucht meist nach Crashes, aber bei zufällig erzeugten CPU-Programmen kann ein Crash selbst korrektes Verhalten sein
  • Ein bestehender Ansatz, reversi, erzeugt zu jedem zufälligen Befehl eine inverse Operation und prüft, ob der Endzustand vom Anfangszustand abweicht
    • Bei CISC-Architekturen wie x86 wird die Generierung solcher Testfälle komplex
  • Ein anderer Ansatz verwendet ein Oracle, um die Ergebnisse der Test-CPU mit denen einer anderen CPU oder eines Simulators zu vergleichen
  • Oracle Serialization kombiniert beide Ideen
    • Zunächst wird ein Zufallsprogramm erzeugt und dann automatisch in eine serialisierte Form umgewandelt
    • Dabei werden Serialisierungselemente wie store/load barrier, speculation fence und cache line flush hinzugefügt
    • Das Originalprogramm und das serialisierte Programm sollten trotz unterschiedlicher Performance-Eigenschaften dieselbe Ausgabe erzeugen
  • Stimmen die Endzustände nicht überein, kann ein mikroarchitektonischer Ausführungsfehler vorliegen; genau diese Abweichung führte zur Entdeckung von Zenbleed

Gegenmaßnahmen und Grenzen der Erkennung

  • Die Schwachstelle wurde am 15. Mai 2023 an AMD gemeldet
  • AMD hat für betroffene Prozessoren ein Mikrocode-Update veröffentlicht
  • BIOS- oder Betriebssystemanbieter könnten bereits Patches bereitstellen, die dieses Update enthalten
  • Die empfohlene Maßnahme ist das Einspielen des Mikrocode-Updates
  • Wenn das Update nicht eingespielt werden kann, lässt sich als Software-Workaround das DE_CFG[9]-Chicken-Bit setzen
    • Das kann Performance kosten
    • Unter Linux lässt es sich mit msr-tools auf allen Kernen setzen
    • Unter FreeBSD wird cpucontrol(8) verwendet
    • Wenn nicht bekannt ist, wie MSRs unter anderen Betriebssystemen gesetzt werden, ist Unterstützung durch den Hersteller nötig
  • Das bloße Deaktivieren von SMT ist nicht ausreichend
  • Es sind keine verlässlichen Techniken zur Angriffserkennung bekannt
    • Denn es sind keine besonderen Systemaufrufe oder Berechtigungen erforderlich
    • Auch eine statische Erkennung unsachgemäßer vzeroupper-Verwendung ist nicht möglich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-25
Hacker-News-Kommentare

  • Das ist wirklich beeindruckend und taugt als Paradebeispiel dafür, dass man nicht automatisch sicher ist, nur weil etwas in einer VM läuft
    VM-Escape war schon immer bekannt, aber hier handelt es sich um eine großflächige Schwachstelle, die auch ohne Escape einfach auszunutzen ist und einen hohen Ertrag bringt
    Nur weil dieser Bug per Microcode behoben wird, heißt das nicht, dass es keine anderen ähnlichen Bugs gibt. Viele 0-Days sind Söldner-Blackhats oft schon lange bekannt, bevor sie öffentlich werden
    In den letzten Jahren entdeckte CPU-Schwachstellen:
    https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
    https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
    https://aepicleak.com/
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#SGAxe
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#LVI
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#Plundervolt
    https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#Enclave_attack
    https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
    https://www.vusec.net/projects/crosstalk/
    https://en.wikipedia.org/wiki/Hertzbleed
    https://securityweek.com/amd-processors-expose-sensitive-data-new-squi…

    • Das Problem ist, dass eine VM heute keine echte virtuelle Maschine mehr ist
      Statt Befehle mit einem großen switch-Block zu interpretieren, werden sie auf der echten CPU ausgeführt, und man verlässt sich auf einige Hardware-Flags, mit denen die CPU garantieren soll, dass sich Daten oder Befehle nicht überschneiden. Die CPU verspricht das zwar, aber in der Praxis sind solche Versprechen schwer einzuhalten
    • Der Vergleich mit Meltdown/Spectre kann etwas irreführend sein
      Dort hat die CPU genau das getan, was sie sollte, und es entstand eine völlig neue, timingbasierte Form des Angriffs. Zenbleed ist dagegen eher ein klassischer Bug, bei dem Daten, die dort nicht sein dürften, in Registern zurückbleiben
    • Unvertrauenswürdigen Code in einer Sandbox, einem Container oder einer VM auszuführen, ist spätestens seit Rowhammer nicht mehr sicher
      Viele dieser Schwachstellen entstehen meiner Ansicht nach daraus, dass Software- und Hardware-Seite nicht richtig miteinander sprechen. Die Software-Seite geht von garantierter Isolation aus, und die Hardware-Seite warnt nicht ausreichend, wenn solche Annahmen getroffen werden
    • Am Ende scheint das meiste davon doch irgendwie mit Branch Prediction zusammenzuhängen
      Entweder ist Branch Prediction grundsätzlich so komplex, dass sie zwangsläufig immer wieder für solche Schwachstellen anfällig ist, oder sie unterscheidet sich so stark davon, wie wir Codepfade und Befehlsausführung intuitiv verstehen, dass man Randbedingungen erst bemerkt, wenn es zu spät ist
      Wird die Komplexität von CPU-Architekturen ab einem bestimmten Punkt so schwer zu durchdenken, dass man den Performanceverlust einer einfacheren Bauweise in Kauf nimmt?
    • Ich habe bei einigen Unternehmen gesehen, dass internetexponierte/DMZ-VMs und interne VMs auf demselben Hypervisor gemischt wurden
      Ich habe darauf hingewiesen und empfohlen, sie per separatem Hypervisor airgapped zu trennen, aber das wurde immer ignoriert. Am Ende ist das wohl deren Schaden

  • Die README in der Exploit-Tar-Datei enthält mehr Details und den Veröffentlichungszeitplan
    2023-05-09 Eine Komponente der CPU-Verifikations-Pipeline erzeugt abnormale Ergebnisse
    2023-05-12 Problem erfolgreich isoliert und reproduziert, Untersuchung fortgesetzt
    2023-05-14 Umfang und Schwere des Problems festgestellt
    2023-05-15 Einen kurzen Statusbericht erstellt und an AMD PSIRT weitergegeben
    2023-05-17 AMD bestätigt den Bericht und erkennt an, dass das Problem reproduzierbar ist
    2023-05-17 Entwicklung eines zuverlässigen PoC abgeschlossen und an AMD weitergegeben
    2023-05-19 Begonnen, wichtige Kernel- und Hypervisor-Anbieter zu informieren
    2023-05-23 Beta-Mikrocode-Update für Rome von AMD erhalten
    2023-05-24 Bestätigt, dass das Update das Problem behebt, und AMD informiert
    2023-05-30 AMD teilt mit, dass eine Sicherheitsmitteilung an Partner verschickt wurde
    2023-06-12 Meeting mit AMD zur Besprechung von Status und Details
    2023-07-20 AMD veröffentlicht den Patch ohne Vorankündigung vor dem vereinbarten Embargo-Datum
    2023-07-21 Da der Fix nun öffentlich ist, wird vorgeschlagen, wichtige Distributionen vertraulich darüber zu informieren, dass sie Firmware-Paket-Updates vorbereiten sollen
    2023-07-24 Öffentliche Offenlegung

  • Das ist wirklich beängstigend. Ich habe den Exploit auf meinem Zen-2-System, einem Ryzen 3600, als unprivilegierter Benutzer ausgeführt und im Hintergrund in den Texteditor Kate eine Zeichenfolge kopiert und eingefügt; innerhalb weniger Sekunden wurden Fragmente dieser Zeichenfolge in der Zenbleed-Ausgabe protokolliert
    Glücklicherweise scheint dieser Exploit stark von einer bestimmten Assembler-Routine abzuhängen, sodass er sich in Browser-JS oder WASM wohl nur sehr schwer ausnutzen lässt. Andernfalls hätte schon ein bösartiger Tab, der ein paar Stunden im Hintergrund offen ist, leicht zu einem Leak führen können
    Ich warte darauf, dass der Fedora-Maintainer den neuen Mikrocode ausliefert, damit der Kernel ihn beim Booten aktualisieren kann

    • Mindestens eine Person hier sagt, dass sich das auch in JavaScript reproduzieren lässt: https://news.ycombinator.com/item?id=36849767
    • Ich habe es auch auf meinem Zen-2-System ausprobiert, und derselbe Angriff funktioniert auch innerhalb von KVM
    • Wenn einmal eine Methode in JS gefunden wird, scheint sie potenziell recht breit anwendbar zu sein
      Gleichzeitig hoffe ich, dass Software-Patches für V8 und SpiderMonkey früher kommen und zusätzlich abmildern
      Allerdings würde ein JS-Exploit auch einen Weg brauchen, die Daten nach außen zu bringen, und das vollständig zu verbergen dürfte ziemlich schwierig sein
    • Ich weiß nicht, wie man den PoC baut. Unter Ubuntu bekomme ich "No such file or directory" und Fehler 127

  • Dass OpenBSD innerhalb der letzten 3 Tage AMD-Mikrocode-Laden hinzugefügt hat, wirkt nicht wie ein Zufall
    https://news.ycombinator.com/item?id=36838511

  • Die Formulierung, AMD habe ein Microcode-Update für betroffene Prozessoren veröffentlicht, scheint nicht ganz korrekt zu sein
    AMD hat Microcode-Updates[0] für Family 17h Modell 0x31 und 0xa0 veröffentlicht, und laut WikiChip[1] entspricht das Rome, Castle Peak und Mendocino
    Bislang scheint es keine Microcode-Updates für Renoir, Grey Hawk, Lucienne, Matisse oder Van Gogh zu geben. Glücklicherweise kann der neue Kernel für diese einfach das chicken bit setzen und tut das auch tatsächlich[2]
    [0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
    [1] https://en.wikichip.org/wiki/amd/cpuid#Family_23_.2817h.29
    [2] https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

  • Im relevanten Abschnitt steht, dass diese Technik CVE-2023-20593 ist und auf allen Prozessoren der Zen-2-Klasse funktioniert, darunter mindestens die folgenden Produkte
    AMD Ryzen 3000 Series Processors
    AMD Ryzen PRO 3000 Series Processors
    AMD Ryzen Threadripper 3000 Series Processors
    AMD Ryzen 4000 Series Processors with Radeon Graphics
    AMD Ryzen PRO 4000 Series Processors
    AMD Ryzen 5000 Series Processors with Radeon Graphics
    AMD Ryzen 7020 Series Processors with Radeon Graphics
    AMD EPYC “Rome” Processors

    • Ich frage mich, ob das bedeutet, dass es nur „auf Zen 2 bestätigt“ ist, oder ob sicher ist, dass das Problem wirklich auf diese Architektur beschränkt ist
      Könnte es sein, dass dieselbe oder eine ähnliche Technik auch auf früheren Zen-/Zen+- oder späteren Zen-3-Kernen funktioniert, man es aber noch nicht nachweisen konnte?
    • Mein 2700X scheint nur knapp davongekommen zu sein. Zumindest unter der Annahme, dass die 7020-Serie betroffen ist und die 7000-Serie nicht
    • Ich frage mich, wie es bei der PlayStation 5 aussieht. Dasselbe gilt für Xbox und dieses Gerät von Valve
    • Sind Ryzen 5000 ohne Radeon nicht verwundbar? Diese Prozessoren scheinen Zen 3 zu sein
      Mein AMD Ryzen 9 5950x Desktop Processor scheint ebenfalls Zen 3 zu sein, also vermutlich in Ordnung
      Ich lasse zwar keine nicht vertrauenswürdigen Workloads laufen, aber sicher ist sicher
    • Zur Einordnung: Ryzen-3000-APUs sind nicht Zen 2

  • Die Website geht gerade unter dem Traffic in die Knie: https://web.archive.org/web/20230724143835/https://lock.cmpx...

    • Es ist nur eine einfache statische HTML-Seite, daher ist mir unklar, wie eine statische Website 2023 überhaupt am Traffic scheitern kann
      In den meisten Fällen kommt HN-Traffic kaum auf 100 Pageviews pro Sekunde
    • Schnellerer Link: https://archive.is/QAwvQ
    • Das Original lädt am Ende auch. Kann je nach Umgebung unterschiedlich sein

  • https://www.amd.com/en/resources/product-security/bulletin/a...
    Laut AMD-Sicherheitsbulletin kommen Firmware-Updates für Nicht-EPYC-CPUs erst gegen Jahresende. Müssen Nutzer bis dahin das chicken bit deaktivieren und den Performance-Verlust in Kauf nehmen?

    • Ist AMD noch ganz bei Trost? Das ist keine mittlere Schwere

  • So beeindruckend wie beängstigend. Ich habe den 10-MB-Sample eine Minute lang laufen lassen und konnte Teile meines Bitwarden-Passworts, meines SSH-Login-Passworts und Fragmente von Bank-Zugangsdaten „leaken“, die sich leicht rekonstruieren ließen

  • Der Artikel war wirklich sehr gut. Besonders gut fand ich den Teil darüber, wie man beurteilen kann, ob ein Zufallsgenerator-Programm korrekt ausgeführt wurde.
    Der naheliegende Ansatz ist, es auf einem Oracle wie einem anderen Prozessor oder einem Simulator auszuführen und zu prüfen, ob es sich auf dieselbe Weise verhält.
    Um jedoch mikroarchitektonische Effekte in einem engen Timing-Fenster zu überprüfen, kann man dasselbe Programm auch mit verschiedenen stall, fence, nop usw. schreiben. In Single-Thread-Code sollte das die Ausgabe nicht beeinflussen, aber innerhalb der CPU führt es mikroarchitektonisch zu recht unterschiedlichen Vorgängen. So kann die CPU zu ihrem eigenen Oracle werden.

    • Diesen Teil fand ich wirklich interessant, besonders den Unterschied zwischen Software-Fuzzing und Hardware-Fuzzing.
      Das chicken bit hat mir auch gefallen.