DDRop: Neuer Hardware-Angriff hebelt Intel TDX und AMD SEV-SNP aus
Forscher von KU Leuven, ETH Zürich, Durham University und Google haben am 14. September 2026 den Angriff DDRop veröffentlicht. Eine kleine Zwischenplatine auf dem Speicherbus lässt Schreibzugriffe verschwinden, sodass Intel TDX, Intel Scalable SGX und AMD SEV-SNP veraltete, vom Angreifer vorbereitete Daten als gültig akzeptieren. Betroffen sind Confidential-Computing-Umgebungen, nicht normale Server im eigenen Serverraum.

Am 14. September 2026 haben Forscher von KU Leuven, ETH Zürich, Durham University und Google einen Hardware-Angriff namens DDRop veröffentlicht. Eine selbstgebaute Zwischenplatine, ein sogenannter Interposer, wird zwischen Prozessor und DDR5-Speichermodul gesteckt und lässt einzelne Schreibzugriffe stillschweigend verschwinden. Der Prozessor liest danach den alten, weiterhin korrekt entschlüsselbaren Inhalt und merkt nichts davon. Damit fällt die Integritätszusage von Intel TDX, Intel Scalable SGX und AMD SEV-SNP, also den Confidential-Computing-Funktionen aktueller Server-CPUs.
Wer klassische Server im eigenen Haus betreibt, muss heute nichts tun. DDRop braucht kurzzeitig physischen Zugriff auf die Hauptplatine und zusätzlich privilegierte Software auf dem Host, also einen kompromittierten Hypervisor oder einen böswilligen Betreiber. Normale virtuelle Maschinen ohne Confidential Computing sind nicht Ziel dieses Angriffs, ebenso wenig Arbeitsplatzrechner, Notebooks oder Smartphones. Relevant ist die Meldung für Unternehmen, die Confidential-Computing-Angebote in der Public Cloud nutzen und ihr Vertrauensmodell auf Remote Attestation stützen. Für diese Gruppe gibt es keinen Patch, sondern eine Neubewertung der eigenen Annahmen.
Was ist passiert?
Confidential Computing verschlüsselt den Arbeitsspeicher einer virtuellen Maschine im Prozessor, damit selbst der Cloud-Betreiber die Inhalte nicht lesen kann. Um sehr große Speichermengen abzudecken, verzichten die skalierbaren Verfahren von Intel und AMD jedoch auf eine Eigenschaft, die die Forscher Freshness nennen: Die Hardware kann bestätigen, dass Speicher verschlüsselt ist, aber nicht, dass er den zuletzt geschriebenen Wert enthält. Veraltete Chiffrate entschlüsseln weiterhin sauber.
Genau dort setzt DDRop an. Der Interposer erzeugt gezielt einen Paritätsfehler auf dem Kommandobus und unterdrückt anschließend die Fehlermeldung des Speichermoduls. Das Modul verwirft den Befehl, der Prozessor erfährt davon nichts, der Schreibzugriff ist verloren. Laut Projektseite ist DDRop der erste aktive Interposer-Angriff, der bei voller DDR5-Geschwindigkeit arbeitet. Frühere aktive Angriffe wie Battering RAM funktionierten nur auf DDR4, weil DDR5 die dort genutzten Adress-Aliasing-Tricks unterbindet. Der 2025 veröffentlichte DDR5-Angriff TEE.fail war passiv und musste den Speicherbus verlangsamen.
Die Forscher legen Schaltpläne, Platinendaten, Controller-Firmware und Angriffscode als Open Source offen. Das Repository ddropattack/ddrop auf GitHub steht unter MIT-Lizenz, wurde am 8. September 2026 angelegt und zuletzt am 14. September 2026 aktualisiert; beim Abruf am 16. September 2026 zeigte es 19 Sterne. Die Stückliste auf der Projektseite beziffert die Materialkosten eines Interposers auf rund 159 US-Dollar bei einer Fertigungsmenge von zehn Stück, ohne Entwicklung und Montage. Das Papier trägt den Titel "DDRop: Active Memory Interposer Attacks on Confidential VMs by Dropping DDR5 Writes" und soll im November 2026 auf der ACM CCS 2026 vorgestellt werden.
Wer ist betroffen?
Betroffen sind die skalierbaren Speicherverschlüsselungen ohne Freshness-Prüfung. Die Forscher haben ihre Ergebnisse auf konkreten Plattformen gemessen, nicht nur theoretisch abgeleitet.
| Technik | Testplattform laut Forschern | Ergebnis |
|---|---|---|
| Intel TDX | Xeon Scalable der 5. Generation | Fremde VM auslesbar, Debug-Modus erzwingbar, Attestation fälschbar |
| Intel Scalable SGX | Xeon Scalable der 5. Generation | Veraltete Daten lassen sich in Enklaven erzwingen |
| AMD SEV-SNP | EPYC Turin | Kopieren fremder Speicherseiten über die Relocation-Schnittstelle |
| Intel Client SGX | ältere Core-Prozessoren | nicht betroffen, nutzt Merkle-Baum mit Freshness-Zählern, von Intel abgekündigt |
| NVIDIA Confidential-GPUs | nicht angreifbar mit diesem Aufbau | Speicher sitzt im Chip-Gehäuse, kein Interposer anbringbar |
| Arm CCA | nicht getestet | laut Forschern möglicherweise ebenfalls betroffen, unbestätigt |
Ausdrücklich nicht betroffen sind:
- Kleine und mittlere Unternehmen mit eigener Hardware im eigenen, zugangsgeschützten Serverraum, solange kein Fremder unbeaufsichtigt an die Hauptplatine kommt.
- Normale virtuelle Maschinen ohne aktiviertes Confidential Computing. Deren Speicher ist gegenüber dem Hypervisor ohnehin nicht geschützt, DDRop bringt hier keinen zusätzlichen Vorteil für einen Angreifer.
- Arbeitsplatzrechner, Notebooks, Smartphones und übliche Anwendungsserver.
- Reine Netzwerkangreifer. Der Angriff ist laut Intel-Bulletin ausdrücklich nicht aus der Ferne ausnutzbar.
Wie kritisch ist das?
Für die Bewertung ist die Unterscheidung dreier Wirkungen entscheidend, die in Berichten oft vermischt werden.
- Datenabfluss: Auf Intel TDX konnten die Forscher eine fremde Trust Domain in den Debug-Modus schalten und deren Speicher im Klartext auslesen. Das gelang nur im Standardmodus "logical integrity". Da die Zielattribute unter fremdem Schlüssel liegen, trifft der Schreibversuch laut Projektseite in etwa der Hälfte der Fälle.
- Manipulation: Über präparierte Einträge in den Secure Extended Page Tables lässt sich eigener VM-Speicher auf beliebige physische Adressen abbilden. Auf AMD SEV-SNP fällt das Ergebnis schmaler aus: Dort ließ sich über die Seitenverschiebung der Inhalt einer Opferseite in eine andere kopieren.
- Bruch der Attestation: Das ist der weitreichendste Punkt. Die Forscher überschrieben die Launch Measurement einer selbst gestarteten, manipulierten Trust Domain mit dem Wert einer legitimen Arbeitslast. Der TDX-Modul liefert danach einen gültig signierten Report mit dem gefälschten Messwert. Eine vom Angreifer kontrollierte VM besteht damit die Fernprüfung, als wäre sie vertrauenswürdig.
Die beiden erstgenannten Angriffe würde Intels optionaler Modus "cryptographic integrity" nach Angaben der Forscher blockieren, weil dabei Daten unter fremdem Schlüssel verändert werden. Die Attestation-Fälschung soll auch dort funktionieren, da der Schreibzugriff innerhalb der eigenen VM unter eigenem Schlüssel stattfindet. Das konnten die Forscher jedoch nicht praktisch bestätigen, weil ihr Testsystem den Modus nicht unterstützte. Diese Einschränkung gehört zur ehrlichen Einordnung dazu.
Laut den Forschern laufen die Angriffe auf TDX deterministisch und in unter zwei Minuten ab, ohne das System zum Absturz zu bringen. Gleichzeitig gilt: Es gibt keine CVE-ID und keinen CVSS-Wert, und es gibt keine Hinweise auf eine Ausnutzung außerhalb des Labors. Die Forscher haben gegenüber The Hacker News erklärt, ihnen sei kein solcher Fall bekannt. Ein Einbruch bei AWS, Microsoft Azure oder Google Cloud ist mit dieser Veröffentlichung nicht belegt.
Was sagen Intel und AMD?
Beide Hersteller wurden im Rahmen einer koordinierten Offenlegung vorab informiert und haben am 14. September 2026 Sicherheitsmitteilungen veröffentlicht. Beide stufen den Angriff als außerhalb ihres veröffentlichten Bedrohungsmodells ein. Das ist eine Herstellerposition, keine unabhängige Bewertung.
- Intel führt die Sache als Bekanntmachung mit der Ankündigungs-ID 2026-09-14-001 unter dem Titel "DDRop - Physical Memory Interposer Research". Intel schreibt, die beschriebenen Szenarien fielen außerhalb des Standard-Bedrohungsmodells für Confidential-Computing-Bereitstellungen, und nennt als Voraussetzungen physischen Zugriff auf den Server, physischen Einbau eines DDR5-Interposers sowie privilegierte Softwareausführung. Als Kundenempfehlung nennt Intel ausschließlich Defense-in-Depth-Praktiken. Weiter heißt es, man prüfe zusätzliche Härtungsoptionen und Erkennungsmechanismen, unter anderem Platform Owner Endorsements, mit denen entfernte Parteien feststellen können sollen, wer die Hardware physisch besitzt.
- AMD veröffentlicht das Bulletin AMD-SB-3048 unter dem Titel "Physical Memory Fault Injection Attacks on DDR5". AMD stellt fest, die Technik beruhe auf einem physischen Angriff auf den Speicherbus und liege damit außerhalb des veröffentlichten Bedrohungsmodells für SEV-SNP. AMD kündigt ausdrücklich an, keine CVE zu vergeben und keine Gegenmaßnahmen zu diesem Bericht zu veröffentlichen. Als betroffene Produkte listet AMD unter anderem die EPYC-Serien 4004, 4005, 8004, 9004 und 9005 sowie Instinct MI300A.
Für Admins bedeutet das konkret: Es gibt derzeit kein Mikrocode-Update und kein Firmware-Update gegen DDRop. Die Ursache liegt im Hardware-Design der skalierbaren Speicherverschlüsselung, eine dauerhafte Lösung erfordert laut Forschergruppe neue Speicherverschlüsselungs-Engines mit Integritäts- und Freshness-Schutz. Intels Vorschlag "cache line versioning" wäre nach Einschätzung der Forscher nicht zwingend wirksam, Intel hat sich dazu nicht geäußert.
Was sollten Admins jetzt tun?
- Erst Inventar prüfen: Feststellen, ob überhaupt Confidential Computing im Einsatz ist. Gesucht sind Azure Confidential VMs, AWS-Instanzen mit AMD SEV-SNP, Google Cloud Confidential VMs oder eigene TDX-Bereitstellungen. Wer nichts davon nutzt, kann den Vorgang als Hintergrundinformation ablegen.
- Vertrauensmodell dokumentieren: Klären, welche Zusage im Unternehmen tatsächlich auf Confidential Computing beruht. Oft ist es eine Compliance-Formulierung, die den Betreiber aus dem Vertrauenskreis nimmt. Genau diese Aussage schwächt DDRop.
- Attestation-Prüfungen bewerten: Wo Remote Attestation als alleiniges Kriterium für die Freigabe von Schlüsseln oder Daten dient, eine zweite unabhängige Bedingung ergänzen, etwa Netzwerksegmentierung, betriebliche Freigaben oder getrennte Schlüsselverwaltung außerhalb der bewerteten VM.
- Beim Anbieter nachfragen: Von Cloud- und Hosting-Anbietern schriftlich erfragen, welche physischen Zugangskontrollen, Manipulationssicherungen und Lieferkettenkontrollen für die betroffenen Racks gelten und ob der optionale Modus cryptographic integrity auf den genutzten Xeon-Systemen verfügbar ist.
- Patchstand trotzdem halten: BIOS, Firmware und Hypervisor aktuell halten. Das behebt DDRop nicht, schließt aber die Softwarelücken, die ein Angreifer zusätzlich für die privilegierte Ausführung bräuchte.
- Physische Sicherheit prüfen: Bei eigener Hardware Rackschlösser, Gehäusekontakte, Besucherprotokolle und Begleitregeln für externe Techniker kontrollieren. Der Interposer lässt sich laut Forschern in Minuten einbauen.
- Lieferkette absichern: Bei Neubeschaffung und bei Rückläufern aus Reparaturen auf versiegelte Transporte und Wareneingangskontrolle achten. Als realistische Zugangswege nennen die Forscher Innentäter im Rechenzentrum, Manipulation während Transport oder Bereitstellung sowie behördlich erzwungenen Zugriff.
- Logs und Zugangsdaten sichten: Zutrittsprotokolle zum Rechenzentrum und Hypervisor-Administrationszugänge stichprobenartig prüfen. Ein Interposer hinterlässt in Systemlogs keine Spur, der physische Zutritt aber sehr wohl.
- Backups unabhängig halten: Sicherungen und die zugehörigen Schlüssel nicht ausschließlich innerhalb der Confidential-Computing-Umgebung verwalten, damit ein kompromittiertes Vertrauensmodell nicht gleichzeitig die Wiederherstellung entwertet.
Einordnung für Unternehmen
DDRop ist keine Meldung, die am selben Tag ein Wartungsfenster erzwingt. Es gibt nichts zu patchen, keine aktive Ausnutzung und keine Fernangriffsfläche. Wer daraus einen Notfall macht, verbrennt Aufmerksamkeit, die andernorts fehlt.
Trotzdem ist die Sache nicht folgenlos. Confidential Computing wird verkauft als technische Zusage, dass selbst der Betreiber die Daten nicht sehen kann. DDRop zeigt, dass diese Zusage bei DDR5-Servern an einer Hardware-Eigenschaft hängt, die bewusst zugunsten von Speicherkapazität weggelassen wurde. Wenn ein Unternehmen also Confidential Computing als Begründung dafür führt, besonders schutzwürdige Daten trotz fehlenden Vertrauens in den Betreiber in die Public Cloud zu geben, gehört diese Begründung überarbeitet, sobald ein Innentäter- oder Lieferkettenszenario im Risikomodell steht.
Der zweite Punkt betrifft Attestation. Viele Architekturen geben Schlüssel oder Daten erst frei, wenn ein Attestation-Report eine bekannte Messung meldet. Nach DDRop ist dieser Report auf TDX unter bestimmten Bedingungen fälschbar. Für die Praxis heißt das: Attestation bleibt ein nützliches Signal, taugt aber nicht als einziges Tor zu sensiblen Schlüsseln, wenn der physische Zugriff auf die Hardware im Bedrohungsmodell steht.
Für die typische KMU-Umgebung mit eigenen Servern, virtualisierten Anwendungen und Standard-Cloud-Diensten bleibt der Handlungsbedarf gering. Wer in einem Rechenzentrum mit Fremdzugang steht, sollte die Gelegenheit nutzen, die eigenen physischen Kontrollen und die Vertragslage mit dem Betreiber einmal bewusst gegenzulesen.
Passende Anleitungen auf S-EDV
- AMD bringt RAM-Verschlüsselung TSME zurück: Hintergrund dazu, wie Speicherverschlüsselung auf AMD-Plattformen funktioniert und wo ihre Grenzen liegen.
- TPM-Attestierung wird ab Windows Server 2028 verpflichtend: Einordnung, wie Attestierung im Microsoft-Umfeld als Vertrauensanker eingesetzt wird.
- Hyper-V: Notfall-Update gegen einfrierende VMs: Beispiel dafür, wie schnell Confidential-VM-Umgebungen im Betrieb Probleme machen können.
Quellen
- Projektseite DDRop der Forschergruppe (KU Leuven, ETH Zürich, Durham University, Google), abgerufen am 16.09.2026
- Intel Security Announcement, ID 2026-09-14-001, "DDRop - Physical Memory Interposer Research"
- AMD-SB-3048, "Physical Memory Fault Injection Attacks on DDR5", 14.09.2026
- GitHub-Repository ddropattack/ddrop, MIT-Lizenz, letzter Push 14.09.2026, abgerufen am 16.09.2026
- The Hacker News: New DDRop Attack Breaks Intel TDX and AMD SEV-SNP Confidential Computing, 14.09.2026