GPUThor: Rowhammer-Angriff hebelt ECC-Schutz von Nvidia-GPUs aus

Forscher der University of Toronto haben Ende August eine neue Angriffstechnik namens GPUThor vorgestellt, die den ECC-Speicherschutz (Error-Correcting Code) von Nvidia-GPUs umgehen kann. Die auf dem Rowhammer-Prinzip basierende Methode wurde an Workstation-GPUs mit Ampere-Architektur und GDDR6-Speicher validiert — den Modellen RTX A4000, A4500, A5000 und A6000 —, die in der KI- und Cloud-Infrastruktur weit verbreitet sind. Das Team meldete die Schwachstelle am 29. April an Nvidia, das Unternehmen veröffentlichte nach rund vier Monaten koordinierter Offenlegung am 25. August entsprechende Empfehlungen zur Risikominderung.

Warum ECC bei einer KI-GPU unverzichtbar ist

Speicherchips können unter dauerhafter Last durch kosmische Strahlung, elektrische Störungen oder Fertigungsfehler zufällig einen 'Bit-Flip' erleiden: Ein als 0 gespeichertes Bit kippt versehentlich auf 1, oder umgekehrt. Im Alltagseinsatz fällt ein einzelner Bit-Flip meist gar nicht auf. Beim Training oder bei der Inferenz eines KI-Modells kann er jedoch direkt Gewichte, Gradienten oder Aktivierungswerte verfälschen — ein Trainingslauf driftet unbemerkt ab, oder das Modell liefert bei der Inferenz eine plausibel klingende, aber falsche Antwort, ohne jede Warnung. Genau dafür existiert ECC: Durch einen zusätzlichen Prüfcode pro Speicherblock korrigiert das System automatisch Einzelbitfehler und erkennt Doppelbitfehler — ein Verfahren namens SECDED. Erst diese Garantie erlaubt es Cloud-Anbietern, dieselbe physische GPU vertrauensvoll mehreren Kunden gleichzeitig zur Verfügung zu stellen.

Wie GPUThor den ECC-Schutz aushebelt

GPUThor hämmert den Speicher bewusst in einem nicht-uniformen Muster und nutzt dabei zwei GPU-Verhaltensweisen aus, die Nvidia nie dokumentiert hatte: wie der Chip wiederholte Speicherzugriffsanfragen zusammenfasst (Coalescing), und wie oft der Target-Row-Refresh-Mechanismus (TRR) von GDDR6-Speicher tatsächlich auslöst. Indem GPUThor knapp unter der Erkennungsschwelle von TRR bleibt, kann es eine Zielzeile im Speicher fortlaufend 'hämmern' und so Bit-Flips in benachbarten Zeilen auslösen.

• Auf getesteten GPUs ohne aktiviertes ECC erzeugte GPUThor zwischen 72.000 und 377.000 Bit-Flips pro Gigabyte Speicher — bis zu 23.597 Mal mehr als beim früheren Angriff des Teams, GPUHammer.
• Selbst bei aktiviertem ECC erzeugte GPUThor 387 Zweibitfehler (die ECC erkennt, aber nicht korrigieren kann) und zwei Dreibitfehler, die die Korrekturfähigkeit von ECC übersteigen und zu Datenkorruption führten.
• Einen ausnutzbaren Bit-Flip zu finden, dauert nun im Schnitt nur noch rund 1,1 Minuten — gegenüber 21,9 Stunden bei GPUHammer.
• Ein anhaltender Angriff auf eine RTX A6000 mit aktiviertem ECC kann die GPU zwingen, sich alle zwei Stunden neu zu starten und alle laufenden Aufgaben abzubrechen; bei wiederholten Angriffen kann sich die Karte schließlich selbst als austauschbedürftig melden.

Über den reinen Dienstausfall (DoS) hinaus demonstrierten die Forscher ein noch gravierenderes Szenario: Durch die Manipulation der GPU-Seitentabellen kann ein CUDA-Programm ohne besondere Rechte beliebigen Speicherzugriff erlangen und eine Root-Shell auf dem Host-System öffnen — aus einer gewöhnlichen GPU-Rechenaufgabe wird so die vollständige Kontrolle über den Server. Rechenzentrums-GPUs der Ampere-Klasse wie die A100 sind gegen DoS widerstandsfähiger, bleiben aber für Privilege Escalation anfällig; selbst GPUs der Blackwell-Generation mit RAS-Repair-Schutz verzögern den Angriff nur, ohne ihn zu verhindern. Die Forscher warnen, dass künftige GDDR7- oder HBM3e-GPUs mit On-Die-ECC unter Bedingungen mit mehreren gleichzeitigen Bit-Flips ebenfalls verwundbar sein könnten.

Wer tatsächlich einem Risiko ausgesetzt ist

GPUThor zielt auf GPU-Cluster in Rechenzentren, die KI-Training und -Inferenz tragen, insbesondere auf Multi-Tenant-Cloud-GPU-Instanzen — das Standardmodell der meisten Public-Cloud-GPU-Angebote, bei denen sich mehrere Kunden eine physische Karte teilen. Ein Angreifer, der auch nur einen kleinen Rechenzeit-Anteil mietet, könnte den Trainings- oder Inferenzjob eines anderen Mieters auf derselben Hardware stören oder sogar verfälschen — ein Risiko, das auf Anwendungsebene unsichtbar bleibt. Nvidias Empfehlungen konzentrieren sich auf Isolation und Monitoring: SYS-ECC und IOMMU/DMA-Isolation aktivieren, GPU-Fehlertelemetrie kontinuierlich überwachen und das gemeinsame Ausführen nicht vertrauenswürdiger CUDA-Workloads auf derselben Hardware einschränken.

Was das für deutsche Unternehmen bedeutet

Deutsche Unternehmen, die GPU-Instanzen bei AWS, Microsoft Azure, Google Cloud oder kleineren Anbietern wie Hetzner oder IONOS mieten, um KI-Modelle zu trainieren oder zu betreiben, verlassen sich dabei fast immer auf eine physische GPU, die nicht exklusiv genutzt wird, sondern mit anderen Kunden geteilt wird. GPUThor erinnert daran, dass diese Isolationsannahme überprüft und nicht einfach vorausgesetzt werden sollte. Bevor eine GPU-Cloud-Instanz als vertrauenswürdige, isolierte Umgebung behandelt wird, sollten Sicherheits- und Infrastrukturteams beim Anbieter nachfragen, ob die von Nvidia empfohlene SYS-ECC- und IOMMU/DMA-Isolation tatsächlich aktiviert ist, Einblick in die GPU-Fehlertelemetrie einfordern und die Isolation zwischen GPU-Mietern fest in Lieferanten-Sicherheitsprüfungen aufnehmen — insbesondere dort, wo personenbezogene Daten nach DSGVO auf gemeinsam genutzter Hardware verarbeitet werden. Das gehört nicht als Häkchen auf ein Datenblatt, sondern als echte Frage danach, wie eine geteilte Karte tatsächlich geschützt ist.