Des chercheurs du Groupe de Sécurité Informatique de l’ETH Zürich ont présenté Phoenix, une nouvelle variante de Rowhammer qui contourne les mécanismes de mitigation en-DRAM des mémoires DDR5 de SK Hynix — le plus grand fabricant de DRAM — et parvient à provoquer des flips de bits exploitables sur les 15 DIMMs analysés. L’équipe démontre une élévation de privilèges en seulement 109 secondes (avec une moyenne de 5 minutes et 19 secondes) sur un PC avec paramètres par défaut, et fournit un exploitable fonctionnel ainsi que des artefacts d’expérimentation accessibles au public. La vulnérabilité a été enregistrée sous la référence CVE-2025-6202.

Contextualisation : Rowhammer à l’ère DDR5

Rowhammer est une faille physique de la DRAM dans laquelle l’accès répété (hammering) à des rangées “agresseuses” induit des flip de bits dans une rangée “victime” adjacente. Les générations récentes de mémoire incorporent des mécanismes de mitigation in-DRAM tels que Target Row Refresh (TRR) et ECC intégrée (ODECC) pour contenir ce phénomène. Cependant, Phoenix montre que DDR5 n’a pas “résolu” le problème de Rowhammer : ces protections présentent des angles morts et l’ODECC n’empêche pas que les flips s’accumulent avec le temps.

Ce que le décryptage a révélé : angles morts dans TRR et synchronisation auto-corrective

Les chercheurs ont rétro-ingénieré le mécanisme TRR de SK Hynix à l’aide d’expériences FPGA et d’un canal latéral basé sur erreurs de retention pour observer quelles rangées la logique interne rafraîchit selon différents motifs de hammering :

• Période d’échantillonnage : le TRR répète un motif d’échantillonnage tous les 128 intervalles de rafraîchissement (tREFI), soit 8× plus long que celui considéré par d’anciens motifs Rowhammer.
• Zoom : durant les premiers 64 tREFI, l’échantillonnage est inconstant ; dans les derniers 64, un pattern en groupes de 4 intervalles émerge, où presque jamais ne sont échantillonnés les deux premiers (“échantillonnage léger”). Ces lacunes représentent les angles morts.

À partir de là, deux nouveaux motifs ont été créés pour éviter ces fenêtres d’échantillonnage et frapper lors des phases de faible échantillonnage :

• Motif court (P128) : 128 tREFI, ciblant uniquement la seconde moitié, en insistant sur les deux intervalles “légèrement échantillonnés” et jamais sur les deux derniers ; répété 16×.
• Motif long (P2608) : 2 608 tREFI pour un autre type de dispositif.

Résultats :

• Sur 15 DIMMs DDR5 de SK Hynix (fabriqués entre 12/2021 et 12/2024), tous étaient vulnérables à l’un des deux motifs.
• P128 s’est révélé 2,62× plus efficace que P2608 (moyenne de 4 989 flips), mais tous deux contournent les mécanismes de mitigation.

Synchronisation “auto-corrective”

Les motifs font jusqu’à 163× plus longs que les méthodes classiques, rendant la synchronisation avec les cycles périodiques (tREFI) difficile sur des systèmes classiques. Phoenix introduit une synchronisation auto-corrective capable de détecter les décalages et de réaligner l’exécution en fonction de la périodicité des rafraîchissements, assurant une stabilité sur des milliers d’intervalles (supplantant des systèmes de synchronisation antérieurs comme celui de Zenhammer, même en modes multithread).

Alignement et parallélisme entre banques

Seuls 2 offsets de rafraîchissement sur 128 sont vulnérables (1,56 %). Phoenix déploie des instances décalées du motif en parallèle sur 4 banques, multipliant par 16× la probabilité de toucher l’offset vulnérable (≈ 25 %).

Exploits démontrés : PTE, RSA et sudo

Les chercheurs ont testé trois attaques complètes exploitant les flips :

1. Attaque PTE : modification des entrées de la table de pages pour obtenir lecture et écriture arbitraires en mémoire.
   • Tous les DIMMs vulnérables.
2. Exfiltration de clés RSA-2048 d’une machine virtuelle collatérale pour compromettre l’authentification SSH.
   • 73 % des DIMMs vulnérables.
3. Attaque sudo : corruption du binaire sudo pour obtenir une élévation de privilèges à la racine localement.
   • 33 % des DIMMs vulnérables.

Au-delà d’un temps même minimal de 109 secondes, ils rapportent une moyenne d’exploitabilité PTE entre 5 et 10 minutes, et prouvent la première élévation de privilèges Rowhammer sur DDR5 reproduite sur un PC avec paramètres par défaut.

ODECC ne suffit pas : pourquoi TRR échoue

• ODECC: corrige les bits lors de l’écriture ou après un certain temps (par exemple, toutes les 24h). Phoenix montre que les flips s’accumulent si l’on martèle suffisamment, ce qui contourne ODECC (§5.2 du papier).
• TRR: protège contre des motifs connus, mais Phoenix exploite un désign pas “principled” (échantillonnage non uniforme et longue périodicité) pour viser précisément là où TRR ne regarde pas.

Conclusion : les protections actuelles réduisent la vulnérabilité à des attaques triviales mais ne résolvent pas le problème ; DDR5 reste exposé au Rowhammer via des motifs et synchronisations adaptés.

Portée et limites

• L’étude s’est concentrée sur SK Hynix (“le plus grand fabricant”) en raison des coûts de rétro-ingénierie ; elle ne garantit pas que d’autres fournisseurs soient protégés.
• Le PoC de Phoenix (open source) est adapté aux plateformes AMD Zen 4 ; si des flips apparaissent sur votre équipement, il est vulnérable à l’un des motifs.
• Phoenix a été divulgué de façon responsable (via NCSC Suisse) depuis le 6 juin 2025 à SK Hynix, aux fournisseurs de CPU et grands clouds ; embargo jusqu’au 15 septembre 2025.
• Une mise à jour du firmware pour les clients AMD (12 septembre) a été signalée, mais non vérifiée indépendamment par les auteurs.

Mitigations pratiques actuelles (et leurs coûts)

• Tripler la fréquence de rafraîchissement (tREFI ≈ 1,3 μs, soit 3×) : cela a arrêté Phoenix dans les systèmes de test.
  • Overhead mesuré : 8,4 % (SPEC CPU2017).
• Recommandations opérationnelles :
  • Pour les charges sensibles (nuages multi-tenant, VDI, VMs collatérales, environnements de haute sécurité), envisager un rafraîchissement accru comme mitigation temporaire.
  • Surveiller et segmenter les environnements avec contenu partagé entre locataires ; minimiser la proximité physique en mémoire entre le(s) attaquant(s) et la/victime.
  • Maintenir un firmware/BIOS à jour et suivre les avis du constructeur.
  • Renforcer la sécurité des binaires sensibles (p. ex., sudo) avec checksums/validation accrues et réduction de la surface d’attaque.
• À moyen/long terme : l’industrie de la DRAM doit développer des mitigations “principled” intégrant une vérification vérifiable de la périodicité et du schéma de sampling, plutôt que de se limiter à des listes de motifs.

Rôles des équipes sécurité et cloud

1. Inventaire précis des DIMMs DDR5 (fabricant, lot, ECC intégré, géométrie).
2. Évaluation du risque par contexte : présence de multi-tenancy, d’accès code arbitraire (ex. utilisateurs sans privilèges), charges de travail tierces, frontières sensibles (PTE, clés, binaires SUID).
3. Tests contrôlés : utilisation du PoC (Zen 4) dans des laboratoires dédiés pour valider l’impact réel.
4. Politiques de rafraîchissement : envisager 3× tREFI sur les systèmes à risque élevé, en mesurant l’impact et en définissant des exceptions.
5. Surveillance et réaction : détecter des corruptions mémoire inhabituelles, des pannes inexpliquées de PTE ou des binaires protégés.

Questions fréquemment posées (FAQ)

Ça signifie que DDR5 d’autres fabricants est sûr ?
Pas nécessairement. L’étude ne couvre que SK Hynix en raison des coûts de rétro-ingénierie. D’autres fournisseurs pourraient présenter des vulnérabilités similaires.

Rowhammer n’était pas “résolu” avec DDR5 grâce à TRR et ODECC ?
Phoenix montre que non : TRR possède des  exploitables et l’ODECC peut être contourné par accumulation de flips sur une longue période.

Quel est l’impact d’augmenter la fréquence de rafraîchissement 3× ?
Dans nos tests, cela bloque Phoenix avec un coût de performance d’environ 8,4 % (SPEC CPU2017). C’est une mitigation temporaire utile pour les environnements sensibles.

Comment vérifier si mes modules SK Hynix DDR5 sont vulnérables ?
Les auteurs proposent un PoC (pour AMD Zen 4) qui tente d’induire des flips avec Phoenix. Si des flips apparaissent, le DIMM est vulnérable aux motifs P128 ou P2608.

La synchronisation auto-corrective fonctionne-t-elle aussi sur DDR4 ?
Les auteurs pensent que oui. Bien qu’ils n’aient pas quantifié précisément l’amélioration en DDR4, il est probable que cela soit bénéfique.

Références et disponibilité

• Phoenix sera présenté au Symposium IEEE sur la Sécurité et la Vie Privée 2026.
• Code et artefacts de recherche : GitHub (comsec-group/phoenix).
• CVE-2025-6202.
• Publication conjointe avec Google Security Blog.

Conclusion

Phoenix redéfinit la norme : il démontre que DDR5 reste vulnérable au Rowhammer malgré les protections en-DRAM avancées. La combinaison de motifs longs, synchronisation auto-corrective et exploits réels (PTE/RSA/sudo) obligent à réévaluer les hypothèses de sécurité pour PCs, serveurs et particulièrement les clouds multi-tenant. En l’absence de solutions hardware, la mitigation opérationnelle (comme le 3× refresh) et la défense en profondeur restent, aujourd’hui, les options les plus efficaces.

source : comsec.ethz.ch