ZenHammer : une attaque Rowhammer visant les plateformes AMD Zen
(comsec.ethz.ch)- Des bit flips Rowhammer se produisent même sur des systèmes DDR4 AMD Zen 2 et Zen 3 dotés de mesures d’atténuation TRR, ce qui montre que les plateformes AMD peuvent elles aussi constituer une surface d’attaque réelle
- L’équipe de recherche a rétroconçu les fonctions secrètes d’adressage DRAM au moyen d’une technique DRAMA adaptée à AMD, et a confirmé qu’il fallait prendre en compte un décalage d’adresse physique en raison du remappage des adresses système
- Le fuzzer ZenHammer a provoqué des bit flips sur 7 appareils avec Zen 2 et 6 avec Zen 3 parmi 10 appareils DDR4, dont Samsung, Micron et SK Hynix ; les appareils Zen 3 se sont révélés plus vulnérables qu’avec Intel Coffee Lake
- Les attaques existantes sur les tables de pages, la corruption de clés publiques RSA-2048 et
sudoers.soont pu être mises en place sur respectivement 7/6/4 appareils, avec un temps moyen de recherche d’un bit flip exploitable de 164/267/209 secondes - Lors de l’évaluation de la DDR5 sur Zen 4, environ 42 000 bit flips ont été observés sur 1 appareil sur 10, mais les 9 autres ont résisté, ce qui indique que des recherches supplémentaires sur les motifs d’accès sont nécessaires pour la DDR5
Des bit flips Rowhammer aussi sur AMD Zen
- ZenHammer provoque des bit flips Rowhammer sur des systèmes AMD Zen 2 et Zen 3 équipés de modules DDR4 avec atténuation TRR
- Il est confirmé que les systèmes AMD, comme les systèmes Intel, peuvent présenter des vulnérabilités Rowhammer
- La surface d’attaque n’est pas négligeable, AMD représentant environ 36 % du marché des CPU x86 desktop
- Les dispositifs DRAM sont difficiles à corriger une fois déployés, et des travaux antérieurs ont montré que les attaques Rowhammer peuvent être pratiques dans divers environnements
Rétro-ingénierie des fonctions d’adressage DRAM d’AMD et optimisation du hammering
- La technique DRAMA a été adaptée aux systèmes AMD afin de rétroconcevoir les fonctions secrètes d’adressage DRAM
- Les routines de timing ont été modifiées pour obtenir des résultats plus stables
- En raison du remappage des adresses système, il a fallu appliquer un décalage d’adresse physique avant de récupérer les fonctions d’adressage DRAM, ce qui a permis de les reconstituer entièrement
- Une approche n’utilisant que les fonctions d’adressage récupérées produisait un nombre limité de bit flips
- Sur Zen 2, des bit flips n’ont été observés que sur 5 appareils sur 10
- Sur Zen 3, aucun bit flip n’a été observé sur les 10 appareils
Synchronisation du rafraîchissement et séquences de commandes
- Comme dans des travaux antérieurs tels que SMASH et Blacksmith, la synchronisation du rafraîchissement s’est révélée être un facteur important pour provoquer des bit flips
- Sur AMD, effectuer des mesures de timing continues sur des lignes non répétées s’est avéré efficace pour une synchronisation du rafraîchissement précise et fiable
- Sur les systèmes AMD Zen+/3, le taux d’activation des motifs Rowhammer non uniformes était nettement inférieur à celui observé sur Intel Coffee Lake
- La séquence optimale de commandes de hammering utilisait le chargement classique
MOVetCLFLUSHOPTpour vider les aggressors du cache, dans un style « scatter » consistant à flusher juste après l’accès à l’aggressor - Contrairement à Zen 2, Zen 3 ne nécessitait pas de fence explicite après le flush
- Le type de fence et la politique de planification des fences influaient aussi sur les résultats ; l’équipe a proposé 6 politiques de reconnaissance de motifs et d’évitement du cache, testées 6 heures par appareil
- Sur la plupart des appareils Zen 2,
SP_noneétait optimal - Dans la plupart des cas sur Zen 3,
SP_pairétait plus adapté
- Sur la plupart des appareils Zen 2,
Résultats de l’évaluation DDR4 et exploitabilité
- L’évaluation a porté sur 10 appareils DRAM DDR4, dont Samsung, Micron et SK Hynix
- Le fuzzer ZenHammer a été exécuté 3 heures pour chaque combinaison de type de fence,
mfenceousfence, et de politique de planification des fences - Après chaque exécution, un minisweep a été réalisé sur une plage de 4 MiB avec tous les motifs trouvés afin de déterminer le motif optimal, puis le meilleur motif de la meilleure politique a été sweepé sur une zone mémoire contiguë de 256 MB
- Résultat : des bit flips ont été provoqués sur 7 des 10 appareils DRAM DDR4 avec Zen 2, et 6 avec Zen 3
- L’exploitabilité des bit flips a été évaluée au moyen de trois attaques issues de travaux antérieurs
- Une attaque visant le page frame number d’une entrée de table de pages afin de pivoter vers une page de table de pages contrôlée par l’attaquant
- Une attaque sur la clé publique RSA-2048 permettant de récupérer la clé privée associée utilisée pour l’authentification d’hôte SSH
- Une attaque sur la logique de vérification du mot de passe de la bibliothèque
sudoers.so, permettant d’obtenir les privilèges root
- Les attaques existantes ont pu être mises en place sur respectivement 7/6/4 appareils, et le temps moyen pour trouver un bit flip exploitable était de 164/267/209 secondes
Évaluation DDR5, code public et calendrier de présentation
- Les fonctions DRAM DDR5 ont également été rétroconçues sur AMD Zen 4, et 10 appareils DDR5 ont été évalués
- ZenHammer a provoqué environ 42 000 bit flips sur 1 des 10 appareils DDR5
- Il s’agit du premier cas publiquement rapporté de bit flips DDR5 sur un système commercial standard
- Sur les 9 autres appareils DDR5, aucun bit flip ne s’est produit ; des recherches supplémentaires sont donc nécessaires pour trouver des motifs plus efficaces sur les appareils DDR5
- Tous les détails figurent dans l’article qui sera présenté à USENIX Security 2024 en août 2024
- Le code du fuzzer ZenHammer est disponible sur GitHub et peut être utilisé pour évaluer la présence de bit flips sur des appareils DRAM avec des CPU AMD Zen 2/3/4
- Rowhammer étant un problème connu à l’échelle de l’industrie, l’équipe a estimé qu’une procédure de divulgation classique n’était pas nécessaire, mais AMD a été informé le 26 février 2024 et, à la demande d’AMD, la divulgation a été reportée jusqu’au 25 mars 2024
- Cette page a été brièvement mise en ligne par erreur le 21 mars 2024
Limites pratiques issues de la FAQ
- Les systèmes AMD avaient été moins étudiés auparavant parce que les recherches initiales sur Rowhammer trouvaient beaucoup plus de bit flips sur les systèmes Intel, que les travaux ultérieurs se sont eux aussi surtout concentrés sur Intel, et que les informations sur les microarchitectures des CPU Intel étaient plus largement disponibles que celles concernant AMD
- Sur les 10 appareils DDR4, aucun bit flip n’a été observé sur 3 appareils avec Zen 2 et 4 avec Zen 3, mais ces appareils produisaient également peu de bit flips sur Intel Coffee Lake ; les chercheurs estiment donc qu’un réglage plus fin du fuzzer pourrait en révéler
- L’évaluation a été limitée à 10 appareils parce que le laboratoire disposait d’un nombre restreint de machines AMD Zen 2/3 et que certaines expériences prenaient longtemps ; le sous-ensemble aléatoire incluait des appareils des trois fournisseurs de DRAM
- À propos du fait que JEDEC n’ait pas encore corrigé le problème, l’équipe explique que résoudre Rowhammer est difficile mais pas impossible, comme l’ont montré des travaux antérieurs tels que ProTRR et REGA
- Des travaux antérieurs sur la DDR3 ont montré que l’ECC n’empêche pas Rowhammer, et comme les appareils DDR4 actuels présentent davantage de bit flips, l’ECC est considéré non comme une protection complète, mais comme un mécanisme qui rend l’exploitation plus difficile
- Doubler le taux de rafraîchissement entraîne un surcoût de performances et une hausse de la consommation d’énergie ; des travaux antérieurs de Mutlu et al. et Frigo et al., entre autres, l’ont présenté comme une solution faible qui n’offre pas une protection complète
1 commentaires
Avis sur Hacker News
Je suis l’un des co-auteurs de l’exploit Rowhammer original. L’ECC reste très efficace pour transformer ce problème, dans l’ensemble, d’un enjeu de sécurité en un enjeu de fiabilité.
Si vous possédez un serveur personnel, que celui-ci dispose d’ECC et que vous pensez pouvoir remarquer un arrêt de la machine dû à une erreur ECC non corrigeable, l’impact sur la sécurité n’est pas majeur.
En revanche, si vous êtes un fournisseur cloud proposant des VM sur des hôtes multi-tenant, le modèle de menace peut être différent.
Dans tous les cas, il faut éviter les machines sans ECC. TRR était déjà une défense défaillante lorsque Rowhammer venait à peine d’être rendu public, et tant que l’économie de fabrication de la DRAM ne changera pas, les bit flips en DRAM ne disparaîtront pas.
Les Ryzen ne prennent en charge que l’ECC unbuffered, qui est plus lente ou plus chère, voire les deux, que la mémoire non-ECC de même capacité.
Les dernières gammes Threadripper prennent en charge l’ECC Registered, mais pour un utilisateur domestique comme moi, c’est excessif en coût, en nombre de threads et en lignes PCIe.
Le risque de sécurité est trop important et tout est trop intégré pour qu’il soit facile de repousser ce changement. Même un joueur avec un ordinateur uniquement dédié au jeu y laissera probablement des informations importantes ; je ne comprends pas que ce changement n’ait pas encore eu lieu.
Je me demande aussi si seule la SRAM est vraiment immunisée.
Seuls les Pro et les Threadripper sont garantis, et certains Ryzen desktop ne le permettent qu’avec certaines cartes mères.
Avec quelle agressivité un moteur de patrol read doit-il scanner la DRAM pour devancer en toute sécurité les bit flips provoqués par Rowhammer ?
Des mots ECC plus grands que le traditionnel 64+8 et une correction d’erreurs multibit changent-ils suffisamment la donne pour permettre de construire des systèmes plus fiables, même avec de la DRAM présentant des vulnérabilités liées à certains motifs ?
Dire que « l’ECC ne bloque pas Rowhammer » est très trompeur. L’article cité dit aussi que « même lorsque la détection ECC est utilisée correctement, 0,65 % à 7,42 % de l’ensemble des bit flips provoquent une corruption silencieuse… dans la configuration AMD-1, les erreurs non corrigeables font planter le système ».
Pour obtenir un seul bit flip exploitable, un attaquant doit provoquer des dizaines d’arrêts de la machine. Des dizaines d’arrêts de machine, ce n’est pas quelque chose qui passe inaperçu.
C’est bien de souligner que la réponse de JEDEC à Rowhammer est médiocre, mais il ne faut pas sous-estimer l’ECC comme solution à court terme.
C’est une plateforme Zen2 TR, et cette formulation m’a fait avoir un coup au cœur pendant un instant. C’est assez trompeur.
Je me demande si les problèmes de sécurité matérielle comme Rowhammer, Spectre ou Meltdown représentent un risque réel pour les gens ordinaires.
J’avais compris que Spectre et Meltdown posaient surtout problème pour des attaques comme l’évasion de VM, donc quelque chose dont les ingénieurs AWS doivent se soucier, mais pas vraiment les particuliers.
Et puisque vous serez coupé de la société moderne, autant aller vivre dans une cabane en forêt et devenir autosuffisant.
Personnellement, j’aime bien NoScript. Sur Chrome, je ne sais pas trop quoi choisir.
Pour le reste… on ne lance quand même pas souvent des programmes arbitraires trouvés sur Internet, si ?
Pour ce genre de bugs, on n’a encore fait qu’effleurer la surface. Le matériel moderne est si complexe qu’il est difficile de croire qu’on puisse tous les trouver.
C’est pourquoi tout le monde peut être concerné.
Je ne comprenais que très vaguement les attaques par bit flip sur DDR, mais en lisant l’article Hammertime original, il est en fait facile à lire
Je ne l’ai pas encore lu en entier, mais il explique les choses de façon très accessible. J’avais entendu parler de bit flip un nombre incalculable de fois sans jamais vraiment comprendre, et là j’ai eu le déclic
https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
J’ai l’impression d’avoir suivi un cours d’introduction à l’électronique. Je ne savais absolument pas que c’était lié à de véritables défauts de fabrication matériels
Le nom Rowhammer s’explique alors enfin. J’étais peut-être complètement à la traîne et c’est peut-être quelque chose que tout le monde sait déjà
« En raison de la densité extrême des matrices DRAM modernes, de petits défauts de fabrication peuvent créer un faible couplage électrique entre des cellules adjacentes. Combiné à la capacité extrêmement faible de ces cellules, cela fait que, chaque fois qu’une ligne de DRAM est lue dans une banque, les cellules mémoire des lignes adjacentes perdent une petite quantité de charge. Si cela se produit assez souvent entre deux cycles de rafraîchissement, les cellules affectées peuvent perdre suffisamment de charge pour que la valeur de bit stockée s’inverse ; on appelle cela une “disturbance error”, ou plus récemment Rowhammer »
C’est parce que les fabricants de DRAM ont poussé les limites à l’extrême. C’est la recherche du profit
Ce n’est pas différent de Ford concluant que le coût des règlements dans les procès liés aux blessures et décès du Pinto serait inférieur au coût de modification de la conception du véhicule
Je me demande si Secure Memory Encryption aide dans ce cas
https://www.amd.com/en/developer/sev.html
Un seul bit flip peut suffire à provoquer une erreur fatale
Je connais très mal la sécurité matérielle, et je me demande si c’est l’une des nombreuses vulnérabilités inévitables liées aux optimisations CPU, du genre peu réaliste à exploiter en pratique
Ça se produit à un niveau bien plus bas qu’un cas limite d’une fonctionnalité qui fuit des informations via un canal auxiliaire
Les données sont stockées sous forme de petites charges dans une grille ; si l’on fait basculer beaucoup de points de grille voisins, on peut faire fuir une partie de la charge vers la charge ciblée
Plus les charges sont petites et proches les unes des autres, plus une attaque Rowhammer est facile. En même temps, plus les charges sont petites et proches, plus la RAM est rapide, bon marché, dense et efficace
Il existe des mesures d’atténuation, mais on est déjà allé jusqu’aux limites
Je me demande si cela fonctionne même avec le chiffrement complet de la mémoire, le poisoning et le XOR des adresses activés
Donc utiliser le chiffrement mémoire rend le système plus sûr
Si « ZenHammer n’a pas réussi à provoquer de flips sur 9 appareils sur 10… des recherches supplémentaires sont nécessaires pour trouver des motifs plus efficaces sur les appareils DDR5 », alors il semble que DDR5 ait encore un peu de répit
Je me demande si quelqu’un sait si cela affecte aussi LPDDR5x
Donc la question essentielle n’est pas vraiment de savoir s’il s’agit de DDR5, LPDDR5(x), GDDR6(x) ou HBM3(e)
Ce qui compte, ce sont les détails d’implémentation laissés à la discrétion du fabricant, comme l’ECC on-die
Zen 2 et 3 sont mentionnés, mais je me demande s’il existe des informations sur Zen 1
Est-ce que cela s’applique tout simplement de la même manière ?