Hochperformante Grafikprozessoren (GPU) galten lange als vergleichsweise schwer auszubeutende Angriffsfläche. Neue akademische Studien zeigen nun jedoch, dass aktuelle GDDR6-basierte GPUs systematisch für RowHammer-Angriffe anfällig sind. Die Arbeiten mit den Codenamen GPUBreach, GDDRHammer und GeForge demonstrieren nicht nur Datenkorruption in der Videospeicher (VRAM), sondern in bestimmten Szenarien sogar die vollständige Kompromittierung der Host-CPU.
RowHammer auf GDDR6-GPUs: Technischer Hintergrund und neue Erkenntnisse
RowHammer bezeichnet einen Hardwarefehler in DRAM, bei dem wiederholtes Auslesen derselben Speicherzeile (Hammering) durch elektrische Störwirkungen Bit-Flips in benachbarten Zeilen auslöst. Dieses Phänomen wurde erstmals 2014 für DDR3-Systeme detailliert beschrieben und untergräbt das Grundprinzip der Speicherisolation, auf dem Betriebssysteme und Sandbox-Mechanismen aufbauen.
Lange wurde angenommen, dass moderne GPUs durch Architekturanpassungen, Refresh-Strategien und optionales ECC (Error Correcting Code) hinreichend geschützt seien. Die Forschung GPUHammer (2025) widerlegte diese Annahme erstmals praktisch: Durch massiv paralleles Hammering auf NVIDIA-GPUs mit GDDR6-Speicher konnten Forschende reproduzierbar Bit-Flips erzeugen und die Genauigkeit von auf der GPU laufenden Machine-Learning-Modellen um bis zu 80 Prozent reduzieren.
GPUBreach: Von GDDR6-RowHammer zur Root-Recht-Eskalation
Manipulation von GPU-Page-Tables über RowHammer
GPUBreach geht über reine Integritätsangriffe hinaus und zielt gezielt auf die Tabellen zur GPU-Speicherverwaltung (Page Tables). Durch präzise induzierte Bit-Flips in GDDR6 werden Einträge der Page Tables (Page Table Entries, PTE) verändert. Ein zunächst unprivilegierter Prozess kann so beliebige Lese- und Schreibzugriffe im GPU-Adressraum erlangen, indem er die Zuordnung von Speicherseiten heimlich umbiegt.
IOMMU-Bypass und Uebergang zu Kernel-Rechten
Besonders sicherheitsrelevant ist, dass GPUBreach diesen Angriff auch bei aktivierter IOMMU demonstriert. Anstatt die Isolationsmechanismen der IOMMU direkt zu brechen, nutzt der kompromittierte GPU-Kontext seine manipulierten PTE, um DMA-Zugriffe auf legitimerweise freigegebene Host-RAM-Bereiche durchzuführen – etwa auf Puffer des NVIDIA-Treibers. Durch Korruption dieses vertrauenswürdigen Treiberzustands entstehen kontrollierbare Speicherfehler im Kernel, die letztlich eine beliebige Schreibprimitive im Kernelspace und Root-Shell ermöglichen.
Diebstahl von Kryptoschluesseln und Sabotage von KI-Modellen
Neben der Privilegieneskalation zeigen die Forschenden, dass GPUBreach vertrauliche kryptografische Schlüssel aus GPU-basierten Bibliotheken wie NVIDIA cuPQC extrahieren kann. Zudem lassen sich ML-Modelle gezielt manipulieren, indem Gewichte oder Parameter im Speicher unbemerkt verändert werden. Damit bedroht GPUBreach sowohl die Vertraulichkeit als auch die Integrität von Workloads in GPU-beschleunigten Umgebungen.
Auswirkungen auf Cloud-Computing, Multi-Tenant-GPUs und KI-Sicherheit
Die vorgestellten Angriffe haben unmittelbare Relevanz für Cloud-GPU-Angebote, HPC-Cluster und Multi-Tenant-KI-Plattformen. In solchen Szenarien teilen sich mehrere Kunden denselben physischen Beschleuniger. Gelingt einem Angreifer der Zugriff auf einen geteilten GPU-Knoten, kann ein erfolgreicher GPUBreach-Angriff im schlimmsten Fall:
- Daten, Modelle und Zwischenergebnisse anderer Mandanten im GPU-Speicher auslesen oder manipulieren,
- über DMA Zugriffe auf Host-RAM erlangen, inklusive kryptografischer Schlüssel oder Zugangstoken,
- als Ausgangspunkt für laterale Bewegungen im Rechenzentrum dienen und Management- oder Orchestrierungsysteme kompromittieren.
Vergleich: GPUBreach, GDDRHammer und GeForge im Ueberblick
Alle drei neuen Ansätze nutzen RowHammer-induzierte Bit-Flips in GDDR6, um die GPU-Adressübersetzung zu manipulieren, unterscheiden sich aber in technischen Details und Anforderungen. GDDRHammer verändert das sogenannte Aperture-Feld in PTEs, sodass ein unprivilegierter CUDA-Kern den gesamten CPU-Adressraum lesen und schreiben kann. Dies ermöglicht weitreichenden Zugriff auf Host-Speicher, ohne zwangsläufig direkten Root-Codeausführung zu garantieren.
GeForge adressiert den letzten Level des GPU-Page-Directory (PD0) und erzielt ebenfalls beliebige Speicherzugriffe auf GPU- und Host-Seite. Die praktische Einsatzfähigkeit ist jedoch eingeschränkt, da die Attacke ein deaktiviertes IOMMU voraussetzt – eine Konfiguration, die in gehärteten Rechenzentrumsumgebungen zunehmend unüblich ist. GPUBreach sticht heraus, weil der Angriff trotz aktiver IOMMU funktioniert, eine vollständige CPU-Privilegieneskalation erreicht und gleichzeitig Datenlecks sowie Modellmanipulation kombiniert.
Schutzmassnahmen und aktuelle Grenzen der Abwehr
Als kurzfristige Gegenmassnahme empfehlen die Forschenden, ECC für GPU-Speicher überall dort zu aktivieren, wo dies verfügbar ist. Studien wie ECCploit und ECC.fail haben jedoch gezeigt, dass ECC kein vollständiger Schutz ist: Werden mehr als zwei Bits in einer Speicherzelle umgeklappt, versagen gängige ECC-Schemata, was zu unentdeckter Datenkorruption führen kann. Auf Desktop- und Mobil-GPUs ohne ECC existiert derzeit kein belastbarer Hardwareschutz gegen RowHammer.
In Rechenzentren und Clouds sollten Betreiber daher zusätzliche Verteidigungsschichten etablieren: strengere Mandantentrennung (z. B. keine gemeinsame physische GPU für hochkritische und untrusted Workloads), konsequente Aktualisierung von GPU-Treibern und Firmware, sowie Monitoring auffälliger Speicherzugriffsmuster mit stark repetitiven Zugriffen auf dieselben Zeilen. Ergänzend sind Integritätsprüfungen für GPU-Page-Tables auf Treiber- oder Hypervisor-Ebene denkbar, auch wenn dies Performancekosten verursacht.
Die neuen RowHammer-Angriffe auf GPUs machen deutlich, dass GPU-Sicherheit ein zentraler Bestandteil jeder modernen Cybersecurity-Strategie werden muss – insbesondere dort, wo KI, Kryptografie und Hochleistungsrechnen eingesetzt werden. Organisationen sollten ihre Bedrohungsmodelle um GPU-basierte Angriffe erweitern, bestehende Cloud- und On-Premises-Architekturen kritisch prüfen und bei Neuplanungen frühzeitig auf RowHammer-resistente Speicher- und Treiberarchitekturen achten. Wer diese Risiken proaktiv adressiert, reduziert die Wahrscheinlichkeit, dass der eigene GPU-Stack zum Einfallstor für einen vollständigen Systemkompromiss wird.
