Attaque DDRop : une menace matérielle concrète pour Intel TDX et AMD SEV-SNP en environnement cloud

Moins de 200 dollars et une intervention de quelques minutes sur un serveur : c’est le prix à payer pour démanteler les protections mémoire d’Intel TDX et d’AMD SEV-SNP, les piliers du confidential computing dans le cloud. Cette menace, baptisée DDRop, a été dévoilée par une équipe de chercheurs internationaux (KU Leuven, ETH Zurich, Durham University et Google) lors de la conférence ACM CCS 2026. Elle repose sur un interposeur matériel qui, inséré entre le processeur et la mémoire DDR5, annule silencieusement certaines écritures, exploitant l’absence de vérification de fraîcheur dans les solutions de chiffrement mémoire actuelles. Nous vous proposons une analyse détaillée de cette attaque, de ses implications pour les entreprises et des parades possibles.

Attaque DDRop : mécanisme et technologies visées

L’attaque DDRop tire parti d’une faiblesse fondamentale du chiffrement mémoire tel qu’il est déployé dans les serveurs cloud modernes : l’absence de vérification de la fraîcheur des données. Pour comprendre comment un simple circuit peut briser la sécurité d’Intel TDX et d’AMD SEV-SNP, il est nécessaire d’examiner le fonctionnement de l’interposeur et le maillon faible qu’il exploite.

Caractéristiques techniques de l’interposeur DDRop

L’interposeur est une petite carte électronique insérée physiquement entre le processeur et les barrettes de mémoire. Il agit comme un commutateur capable d’intercepter les signaux sur le bus DDR5. Ses principales caractéristiques sont les suivantes :

• Composants électroniques rapides (transistors ou relais) capables de suivre la cadence du bus DDR5 (jusqu’à 6,4 GT/s).
• Fonctionnement actif : contrairement aux attaques passives précédentes (TEE.fail), il peut modifier le comportement du bus.
• Coût estimé des composants : environ 200 dollars, rendant l’attaque accessible à un large éventail d’attaquants.
• Installation rapide : quelques minutes suffisent pour insérer l’interposeur sur une machine en fonctionnement.
• Pilotage entièrement logiciel : une fois installé, l’interposeur est contrôlé via des commandes envoyées par le serveur compromis.

Le principe de l’attaque est le suivant : lorsque le processeur émet une commande d’écriture en mémoire, l’interposeur force une erreur sur le bus de commande et coupe le signal par lequel le module mémoire pourrait signaler cette erreur. La mémoire ignore donc la commande d’écriture, et l’ancienne valeur chiffrée reste en place. Le processeur, de son côté, n’est jamais informé que l’écriture n’a pas eu lieu. Lors d’une lecture ultérieure, il récupère la donnée chiffrée vieille, la déchiffre et l’utilise comme si la mise à jour avait bien été effectuée.

L’absence de vérification de fraîcheur : la racine du problème

Le chiffrement mémoire mis en œuvre par Intel TDX, AMD SEV-SNP et Intel Scalable SGX protège la confidentialité des données (personne ne peut lire le contenu sans la clé), mais il ne garantit pas la fraîcheur (c’est-à-dire qu’il s’agit bien de la version la plus récente). Les concepteurs de ces technologies ont délibérément omis cette vérification pour gérer de grandes quantités de mémoire sans surcoût matériel important. Or, cette omission ouvre la porte à une attaque de type « rollback » ou « replay » : si un attaquant peut empêcher une écriture, il peut maintenir une ancienne version chiffrée en mémoire et la faire accepter par le processeur.

« L’attaque DDRop est la première attaque par interposeur actif fonctionnant à pleine vitesse sur la mémoire DDR5 des serveurs cloud modernes, et elle brise l’intégrité d’un système Intel TDX à jour. » - Les chercheurs.

Technologies concernées par DDRop

Toutes les technologies de chiffrement mémoire qui ne vérifient pas la fraîcheur sont potentiellement vulnérables. Voici un tableau récapitulatif :

Scénarios d’attaque démontrés par les chercheurs

L’équipe de recherche a mis en œuvre plusieurs scénarios prouvant la gravité de l’attaque DDRop sur Intel TDX, et un scénario plus restreint sur AMD SEV-SNP.

Intel TDX : prise de contrôle complète d’une machine virtuelle

Sur Intel TDX, les chercheurs ont réussi à prendre le contrôle intégral d’une machine virtuelle protégée. Le principe consiste à bloquer les écritures que le firmware de confiance effectue lors de l’initialisation des tables de pages. En laissant dans ces tables des données contrôlées par l’attaquant (issues d’écritures précédentes), celui-ci peut mapper sa propre mémoire physique sur l’espace d’adressage de la VM cible.

Les conséquences sont multiples :

1. Lecture de la mémoire privée de la VM victime : l’attaquant peut copier l’intégralité du contenu mémoire.
2. Activation du mode debug : en modifiant les flags appropriés, la VM passe en mode debug et vide sa mémoire en clair, l’attaquant peut la lire puis restaurer l’état initial, rendant l’attaque indétectable.
3. Falsification de l’attestation de lancement : la mesure cryptographique qui permet à un client distant de vérifier que la VM a démarré dans un état connu et sûr est modifiée. Une VM malveillante peut alors se faire passer pour une VM de confiance.

Ces deux premiers points ont été démontrés sur le mode par défaut (intégrité logique) de TDX. Le mode optionnel d’intégrité cryptographique les bloquerait, selon les chercheurs, car il implique de modifier les données d’une autre VM. En revanche, le troisième point (falsification de l’attestation) pourrait fonctionner même en mode d’intégrité cryptographique, car l’écriture a lieu à l’intérieur de la VM attaquante, sous sa propre clé.

AMD SEV-SNP : exploitation plus limitée

Sur les processeurs AMD, les chercheurs se sont concentrés sur la fonction de relocalisation de pages. En bloquant les écritures pendant cette opération, ils ont réussi à copier le contenu d’une page mémoire appartenant à la VM victime vers une page contrôlée par l’attaquant. Ils n’ont pas mené d’attaque de basculement en mode debug ni de falsification d’attestation, celles-ci étant spécifiques à la conception d’Intel TDX.

Conséquences pour la chaîne de confiance

La capacité de falsifier l’attestation est particulièrement préoccupante. Dans un environnement de cloud confidentiel, un client déploie une VM en s’appuyant sur une preuve cryptographique que la machine a bien démarré dans l’état attendu. Si cette preuve peut être imitée, c’est tout le modèle de confiance qui s’effondre.

« Aucun correctif simple n’existe. La faiblesse est dans la conception matérielle. » - Les chercheurs.

Réactions des constructeurs et implications pour le cloud

Les réactions d’Intel et AMD illustrent la difficulté de corriger une faille matérielle. Tous deux ont été informés via un processus de divulgation coordonnée et ont reconnu les résultats, mais leurs positions divergent.

Intel : un problème de périmètre

Intel indique que les attaques par interposeur physique ne font pas partie du périmètre de protection couvert par son chiffrement mémoire. Le constructeur a déclaré qu’il n’attribuera pas de CVE à cette recherche, qualifiant ce type de menace de « hors scope, mais pas hors de propos » (out of scope, but not out of mind). Intel précise que son mode d’intégrité cryptographique, disponible sur certains Xeon, bloque déjà une partie de l’attaque DDRop. Toutefois, les chercheurs n’ont pas pu tester ce mode et émettent des réserves quant à son efficacité contre la falsification d’attestation. Intel travaille par ailleurs sur une future génération de mécanismes de chiffrement intégrant une vérification de fraîcheur, comme le « cache-line versioning ».

AMD : l’attaque hors modèle de menace

AMD a publié un bulletin de sécurité sur sa page produit. La société souligne que l’attaque nécessite un accès physique à la machine, ce qui se situe en dehors du modèle de menace établi pour SEV-SNP. AMD n’a pas proposé de solution logicielle, mais a indiqué suivre les évolutions de la recherche.

Fournisseurs cloud : quelle exposition ?

Les principales plateformes cloud (AWS, Microsoft Azure, Google Cloud) proposent des services basés sur Intel TDX et AMD SEV-SNP. Bien qu’aucun incident n’ait été signalé, l’attaque DDRop démontre qu’un employé malveillant, un accès physique non autorisé ou une compromission de la chaîne d’approvisionnement pourraient permettre de déployer un interposeur. Les fournisseurs cloud ont donc tout intérêt à renforcer leurs contrôles d’accès physique et à surveiller l’intégrité des serveurs.

Mesures de protection pour les entreprises utilisatrices

En attendant une refonte matérielle, plusieurs actions peuvent être mises en place pour limiter l’exposition à l’attaque DDRop.

Mesures logicielles à court terme

Les chercheurs et experts en sécurité recommandent les actions suivantes :

• Restreindre les fonctionnalités mémoire exploitées : limiter l’utilisation des opérations de réécriture de tables de pages en cours d’exécution, lorsque c’est possible.
• Vérifier les écritures critiques : pour les écritures de données sensibles (comme les tables de pages ou les mesures de lancement), effectuer une relecture et comparer la valeur écrite pour s’assurer de la bonne prise en compte.
• Détection d’interposeur au démarrage : analyser les temps de réponse mémoire et les signaux électriques pendant le POST du serveur pour détecter une anomalie.
• Surveillance des accès physiques : mettre en place des procédures strictes d’accès aux salles serveurs, avec vidéosurveillance et scellés inviolables.
• Chiffrement de bout en bout des données : ne pas se reposer uniquement sur le chiffrement mémoire, mais ajouter une couche de chiffrement applicatif pour protéger les données sensibles même en cas de fuite mémoire.

Vérifications physiques et processus de confiance

Au-delà du logiciel, la sécurité physique reste cruciale. Les entreprises devraient exiger de leurs fournisseurs cloud des garanties sur les contrôles d’accès aux serveurs. Dans le cadre d’un déploiement sur site, il est possible d’inspecter physiquement les machines avant leur mise en service. Les schémas de l’interposeur étant publics (le projet GitHub des chercheurs fournit les designs de la carte et le firmware), les équipes sécurité peuvent évaluer la faisabilité d’une détection.

Perspectives matérielles futures

À plus long terme, l’industrie devra intégrer la vérification de fraîcheur directement dans les mécanismes de chiffrement mémoire. Intel travaille sur le « cache-line versioning », mais les chercheurs doutent qu’il contrecarre complètement DDRop. Les futures générations de processeurs et les normes mémoire comme DDR6 devront prendre en compte ce type d’attaque dès leur conception.

Encadré : Résumé des conditions de l'attaque DDRop
- Prérequis : accès physique au serveur, possibilité d'insérer un interposeur entre CPU et mémoire DDR5.
- Coût de l'équipement : environ 200 dollars.
- Temps d'installation : quelques minutes.
- Compétence requise : connaissance de l'architecture des bus mémoire et capacité à manipuler du matériel électronique.
- Détection : difficile en cours d'exécution ; aucune méthode simple de détection n'existe aujourd'hui en production.

Conclusion : repenser la sécurité des environnements confidentiels

L’attaque DDRop nous rappelle qu’aucune technologie de sécurité n’est infaillible, surtout face à une menace physique. Le confidential computing a considérablement élevé le niveau de protection des données dans le cloud, mais il ne saurait être considéré comme une solution absolue. Si votre organisation utilise des instances basées sur Intel TDX ou AMD SEV-SNP, il est impératif de prendre en compte cette nouvelle menace dans votre analyse des risques.

Nous vous conseillons d’auditer vos contrôles d’accès physique, de surveiller les éventuels signes de tampering matériel et de rester informé des évolutions que Intel, AMD et les fournisseurs cloud apporteront suite à cette découverte. Le partage des schémas et du code d’attaque par les chercheurs est une opportunité pour la communauté sécurité de développer des contre-mesures. En attendant, la confiance dans le cloud confidentiel ne peut plus reposer uniquement sur le matériel : elle doit être complétée par des processus robustes de vérification et de contrôle.

Article basé sur les recherches présentées à ACM CCS 2026 par KU Leuven, ETH Zurich, Durham University et Google.