Attaque DDRop : le blindage du calcul confidentiel Intel TDX et AMD SEV-SNP fissuré pour 160 €

Une découverte choc ébranle les fondations du confidential computing tel qu’il est déployé dans les plus grands datacenters mondiaux. Des chercheurs des universités KU Leuven, ETH Zurich, Durham et de Google ont publié les détails d’une attaque DDRop qui permet de corrompre et de lire la mémoire de machines virtuelles protégées par Intel TDX et AMD SEV-SNP. Le vecteur d’attaque ? Un minuscule circuit interposeur, coûtant moins de 200 euros, qui s’infiltre entre le processeur et la mémoire DDR5 d’un serveur. Pour la première fois, une technique active exploite l’absence de vérification de fraîcheur des données dans les mémoires DDR5 pour prendre le contrôle de l’état d’une machine virtuelle, sans laisser de trace logicielle. Cette vulnérabilité matérielle, présentée à l’ACM CCS 2026, rebat les cartes de la sécurité cloud.

Attaque DDRop : le chaînon manquant de la sécurité mémoire

Les fondamentaux du calcul confidentiel

Le confidential computing (ou calcul confidentiel) est une promesse forte des cloud providers. Il garantit que les données d’un client sont chiffrées non seulement au repos (stockage) et en transit (réseau), mais également en cours d’utilisation (mémoire vive). Pour ce faire, des technologies matérielles comme Intel TDX (Trust Domain Extensions) ou AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) chiffrent l’intégralité de la mémoire d’une machine virtuelle (VM). Même un administrateur du cloud disposant d’un accès physique au serveur ne peut, en théorie, lire les données d’une VM cliente. L’ANSSI elle-même encourage l’adoption de ces technologies pour les environnements les plus sensibles, ce qui rend la découverte de DDRop d’autant plus critique pour les acteurs français.

Le talon d’Achille : l’absence de vérification de fraîcheur (freshness)

Le problème réside dans un compromis d’ingénierie inévitable à grande échelle. Pour gérer la très grande quantité de mémoire d’un serveur moderne (plusieurs centaines de Go, voire des To), les technologies de chiffrement mémoire sacrifient la vérification de la fraîcheur (freshness). Autrement dit, le processeur peut vérifier qu’une donnée lue est bien chiffrée (et donc confidentielle), mais il ne peut pas garantir qu’il s’agit de la version la plus récente de cette donnée. Si un attaquant remplace une donnée chiffrée par une version plus ancienne, le processeur la déchiffrera sans broncher, car le chiffrement est mathématiquement correct. C’est exactement ce qu’exploite l’attaque DDRop.

“L’absence de fraîcheur est le prix à payer pour protéger de grandes quantités de mémoire. L’attaque DDRop transforme cette lacune architecturale en une arme de compromission massive des machines virtuelles en environnements cloud.” - Extrait de l’article de recherche des auteurs.

Fonctionnement technique de l’interposeur malveillant

Un interposeur actif pour mémoire DDR5

L’innovation de DDRop réside dans l’utilisation d’un interposeur (interposer) actif. Il ne s’agit pas d’une simple sonde passive. La carte, équipée de commutateurs électroniques, se glisse physiquement entre le socket du processeur et le module de mémoire DDR5. Son coût de fabrication est dérisoire, estimé à environ 150 dollars (environ 160 euros) en pièces détachées, sans compter le temps de recherche et de développement.

Contrairement aux attaques passives précédentes comme TEE.fail, qui se contentaient d’écouter le bus mémoire en le ralentissant, l’interposeur de DDRop est actif et fonctionne à la pleine vitesse de la DDR5. Il n’a pas besoin de dégrader les performances pour opérer, ce qui le rend indétectable par les sondes de performances logicielles. Son installation ne prend que quelques minutes et est entièrement pilotable par le logiciel serveur une fois en place. Dans la pratique, cela signifie qu’un attaquant ayant un accès physique bref à un serveur peut y laisser une porte dérobée matérielle quasi invisible.

Le mécanisme de “drop” des écritures mémoire

Le principe est d’une simplicité redoutable. L’interposeur n’a pas besoin de modifier les données. Il lui suffit d’empêcher certaines écritures d’arriver à destination.

1. Forcer une erreur : Lorsque le processeur envoie une commande d’écriture à la mémoire, l’interposeur force une erreur sur le bus de commande.
2. Masquer l’erreur : Simultanément, il coupe le fil de signalisation que la mémoire utilise pour remonter l’erreur au processeur. Le module mémoire n’exécute donc pas l’écriture et la jette.
3. Persistance de l’ancienne donnée : Le processeur, n’ayant reçu aucun rapport d’erreur, pense que l’écriture a réussi. Il continue son exécution normalement.
4. Exploitation : Lorsqu’une instruction lit la zone mémoire concernée, le processeur récupère l’ancienne donnée (celle qui était présente avant l’écriture “droppée”). Comme la donnée est correctement chiffrée avec l’ancienne version, le déchiffrement fonctionne parfaitement. L’unité de chiffrement mémoire ne détecte aucune anomalie.

“L’attaque DDRop ne modifie pas les données dans la mémoire, elle les fige dans le temps. C’est une arme redoutable car elle contourne tous les mécanismes de détection d’intégrité basés sur le chiffrement, qui ne voient que des données mathématiquement valides.” - Note d’analyse accompagnant la publication.

Impact réel sur Intel TDX, AMD SEV-SNP et les infrastructures cloud

Compromissions totales des VM Intel TDX

Sur Intel TDX, l’impact est maximal. Les chercheurs ont démontré que le fait de “dropper” des écritures lors de la configuration des tables de pages d’une VM permet à une VM malveillante de mapper sa propre mémoire sur des adresses physiques protégées d’une VM victime.

Scénario d’attaque démontré :

• Lecture mémoire espionne : La VM attaquante peut lire l’intégralité de la mémoire de la VM victime, compromettant la confidentialité de toutes les données en cours de traitement.
• Contournement du mode debug : L’attaquant peut activer le mode debug d’une VM protégée pour en déverser toute la mémoire en clair, puis restaurer l’état initial pour effacer toute trace de l’intrusion.
• Falsification de la preuve d’attestation (Attestation Forgery) : L’attaque permet de modifier la launch measurement (mesure de lancement) de la VM. Cela signifie qu’une VM malveillante peut se faire passer pour une VM de confiance lors de la procédure d’attestation à distance, un mécanisme crucial pour la confiance des clients du cloud. Intel précise que ces attaques fonctionnent en mode “intégrité logique” par défaut de TDX. Le mode “intégrité cryptographique” (optionnel) bloque la lecture mémoire et le mode debug, mais pas nécessairement la falsification de l’attestation, car celle-ci opère au sein de la VM attaquante elle-même.

Portée démontrée sur AMD SEV-SNP

L’impact sur AMD SEV-SNP est plus ciblé mais tout aussi inquiétant. En faisant “dropper” les écritures lors de la fonction de relocalisation de pages d’AMD, les chercheurs ont pu dupliquer le contenu d’une page mémoire d’une VM victime vers une autre page, corrompant ainsi l’isolation mémoire. Les attaques de falsification d’attestation et de mode debug sont quant à elles spécifiques à Intel TDX.

Tableau comparatif des impacts de l’attaque DDRop sur les principales technologies de confidential computing :

Pourquoi les anciens SGX clients sont-ils épargnés ? Parce qu’ils utilisent un arbre d’intégrité matériel (integrity tree) qui vérifie la fraîcheur de chaque ligne de cache. Mais Intel a depuis retiré cette technologie de ses produits grand public pour se concentrer sur TDX, moins cher à implémenter à grande échelle.

Et les autres technologies ?

Les GPU de confidential computing de NVIDIA sont inaccessibles, car leur mémoire est intégrée dans le package de la puce, rendant impossible la pose d’un interposeur. Les chercheurs n’ont pas testé Arm CCA (Confidential Compute Architecture), mais estiment qu’elle pourrait être affectée selon son implémentation mémoire.

Message aux cloud providers : AWS, Azure et Google Cloud proposent des instances basées sur Intel TDX et AMD SEV-SNP. DDRop ne démontre pas une intrusion de ces services en production, mais il démontre que la barrière de sécurité qu’ils vendent peut être contournée avec un accès physique et un investissement minime. Pour un RSSI français, c’est un signal d’alarme fort.

Parades et correctifs : une solution complexe

Il n’existe pas de correctif simple. La racine du problème est architecturale et touche les générations actuelles de processeurs Xeon et Epyc.

• Correctif matériel à long terme : Intel et AMD devront concevoir de nouvelles générations de processeurs intégrant une vérification de la fraîcheur (freshness check) en standard, par exemple via un mécanisme de cache-line versioning (versionnage de ligne de cache) sur le bus mémoire. Intel a reconnu le problème, déclarant que l’attaque sort du périmètre de protection de son chiffrement mémoire actuel, mais que le sujet est “out of scope, but not out of mind” (hors périmètre, mais pas hors de notre esprit). Leur mode d’intégrité cryptographique, disponible sur certains Xeon, bloque déjà une partie des attaques.

• Mitigations logicielles immédiates : Les chercheurs proposent plusieurs pistes pour relever la barrière, sans supprimer la cause racine.

  • Restreindre les fonctionnalités mémoire exploitées par DDRop (relocalisation de pages, certaines commandes de table de pages).
  • Vérification par double écriture (write-verify) : forcer une relecture des données critiques après chaque écriture pour détecter les “drops”.
  • Détection matérielle au boot : tenter de détecter la présence d’un interposeur au démarrage du serveur en analysant les timings du bus.
  • Activer le mode Cryptographic Integrity dès que possible.

# Note de sécurité pour les équipes d'exploitation
# Activer le mode Cryptographic Integrity sur Intel Xeon (si supporté par le BIOS)
# Permet de bloquer les attaques cross-VM de DDRop.
# Consulter la documentation Intel pour la compatibilité des workloads.

Position officielle des constructeurs : Intel et AMD ont été informés via le processus de coordinated disclosure. AMD a déclaré que l’attaque nécessitant un accès physique, elle sortait du modèle de menace standard de SEV/SNP. Intel partage cette position concernant les attaques physiques sur la mémoire serveur. Les deux constructeurs devaient publier des bulletins de sécurité en septembre 2026. Aucun correctif microcode n’est attendu ; la parade est dans les mains des opérateurs et des futures générations de silicium.

Recommandations pour les DSI et RSSI français

Face à l’attaque DDRop, les équipes sécurité françaises doivent adopter une posture proactive et pragmatique.

1. Analyse de Risque Contextualisée : Auditez vos workloads cloud critiques. Identifiez si vos VM (conformité RGPD, données de santé HDS, paiement PCI-DSS) reposent sur Intel TDX ou AMD SEV-SNP. L’attaque nécessite un accès physique, ce qui réduit la surface d’exposition mais ne l’annule pas. Posez-vous la question : qui a accès à mes racks serveurs ?

2. Renforcement du Contrôle d’Accès Physique : La sécurité des datacenters doit être aussi stricte que la sécurité logique. Un technicien malveillant, un maillon faible dans la chaîne d’approvisionnement du matériel, ou une saisie judiciaire sous contrainte légale sont des vecteurs d’accès réalistes pour poser un interposeur.

3. Défense en Profondeur : Ne comptez pas uniquement sur le confidential computing. DDRop montre que le chiffrement mémoire peut être contourné. Combinez-le avec du chiffrement de bout en bout applicatif (comme le format-preserving encryption ou le chiffrement côté client), une surveillance comportementale (UEBA) et une segmentation réseau stricte.

4. Mise à Jour et Veille : Activez le mode Cryptographic Integrity si vos serveurs le supportent. Suivez les publications des constructeurs et de l’ANSSI. Le code et les designs de l’interposeur seront rendus publics pour la recherche, ce qui permet aux équipes offensives de mieux comprendre le vecteur, mais exige aussi une vigilance accrue.

5. Contrats Cloud et Transparence : Lors de vos négociations avec les cloud providers (AWS, Azure, OVHcloud, Scaleway), interrogez-les sur leur exposition à ce vecteur d’attaque. Quelles mesures physiques et logicielles prennent-ils pour mitiger DDRop ? Quelles versions de leurs firmwares et hyperviseurs intégrent les recommandations des chercheurs ?

Conclusion : une faille architecturale qui redéfinit la confiance dans le cloud

L’attaque DDRop marque un tournant dans la cybersécurité des infrastructures cloud. Elle démontre que le calcul confidentiel, bien qu’étant une avancée majeure, n’atteint pas encore la maturité suffisante pour garantir une isolation parfaite face à un adversaire disposant d’un accès physique et de compétences électroniques de base. Le coût dérisoire de l’interposeur (moins de 200 €) combiné à l’absence de vérification de fraîcheur dans les technologies Intel TDX et AMD SEV-SNP crée une fenêtre de vulnérabilité que les RSSI ne peuvent ignorer.

Pour les DSI et RSSI français, le message est clair : la confiance dans le cloud ne doit jamais être aveugle. La transparence sur les couches de sécurité, l’audit continu, la défense en profondeur et une saine dose de scepticisme face aux promesses marketing restent les meilleures alliées pour protéger les données les plus critiques de la République. La route vers une vérification de fraîcheur généralisée est encore longue, mais cette attaque DDRop en accélère certainement la nécessité et rappelle que la sécurité est un processus, jamais un état final.

Mini-cas contextualisé au marché français : Prenons l’exemple d’un éditeur de logiciel de santé français hébergeant des données patients (DPO, HDS) sur un cloud souverain utilisant Intel TDX pour l’isolation des traitements. Un administrateur malveillant du cloud provider pourrait, avec un interposeur DDRop, non seulement lire les données en clair lors de l’exécution, mais aussi falsifier l’attestation de la VM pour déployer un code malveillant que le client pense être sa propre application. Cet exemple souligne l’importance de ne pas faire du confidential computing un point unique de défaillance, mais de le considérer comme une couche renforcée dans une stratégie de défense en profondeur. En pratique, nous recommandons de coupler cette isolation matérielle avec une gestion rigoureuse des secrets applicatifs via un coffre fort numérique (HSM/Vault) et une surveillance réseau continue.