S'attaquer au Rowhammer dans la sécurité DRAM
Explorer de nouvelles approches pour améliorer la sécurité du DRAM contre les menaces Rowhammer.
― 7 min lire
Table des matières
- Techniques traditionnelles de mitigation
- Défis d'espace et de temps
- Défauts des traceurs à bas coût
- La conception Panopticon et ses vulnérabilités
- Entrée de MOAT : une nouvelle approche
- Analyse de performance
- Charges de travail bénignes et malveillantes
- Répondre aux attaques de performance
- Conclusion et recommandations
- Source originale
RowHammer est un problème de sécurité qui surgit dans la mémoire des ordinateurs modernes, surtout la DRAM. Quand certaines lignes de mémoire sont activées plusieurs fois en peu de temps, ça peut provoquer des changements de bits dans des lignes voisines de manière non intentionnelle. Ça peut mener à des situations dangereuses où un hacker pourrait accéder à des données sensibles ou même augmenter ses privilèges dans un système.
Au cours des dix dernières années, la technologie de la DRAM a fait des progrès significatifs, mais ça a aussi facilité l'exploitation de Rowhammer. Le nombre d'Activations nécessaires pour provoquer ces changements de bits a diminué de manière spectaculaire. Par exemple, le nombre d'activations requises est passé d'environ 140 000 à un peu moins de 5 000 activations au cours de la dernière décennie.
Techniques traditionnelles de mitigation
Pour contrer Rowhammer, diverses solutions ont été proposées. Ces solutions consistent généralement à suivre quelles lignes de mémoire sont activées fréquemment et à rafraîchir les lignes voisines pour maintenir leur intégrité. Ces mécanismes peuvent être mis en œuvre soit par le contrôleur de mémoire, qui fait partie du système gérant l'accès à la mémoire, soit directement dans la puce DRAM elle-même.
Les solutions intégrées dans la puce DRAM sont particulièrement intéressantes car elles fonctionnent sans avoir besoin d'aide d'autres parties du système. Cependant, l'utilisation de méthodes à l'intérieur de la DRAM présente ses propres défis concernant la mémoire limitée disponible pour le suivi et les contraintes de temps imposées par les opérations de rafraîchissement de la mémoire.
Défis d'espace et de temps
La mitigation en DRAM fait face à deux problèmes principaux : l'espace et le temps. D'abord, la quantité de mémoire disponible pour suivre ces lignes agressives est assez limitée, souvent juste quelques octets par banque de mémoire. Cela signifie que les dispositifs ne peuvent pas suivre toutes les lignes potentiellement nuisibles, ce qui entraîne des vulnérabilités significatives.
Ensuite, la gestion de la mémoire doit être efficace. Il y a un calendrier de temps strict pour rafraîchir la mémoire afin d'assurer l'intégrité des données, rendant crucial de gérer les lignes agressives sans perturber ce calendrier. Les conceptions actuelles ne peuvent pas prendre de temps supplémentaire s'il y a de nombreuses lignes agressives, car cela violerait les règles de timing.
Défauts des traceurs à bas coût
De nombreux traceurs utilisés dans les implémentations actuelles de la DRAM sont à bas coût et ont des entrées limitées. De ce fait, ils peuvent facilement être submergés par des attaques délibérées qui exploitent leurs faiblesses. Un attaquant pourrait utiliser des motifs astucieux pour submerger ces traceurs à bas coût, les faisant oublier quelles lignes protéger. En conséquence, les systèmes restent vulnérables aux attaques Rowhammer, même avec des mitigations intégrées dans la DRAM.
La conception Panopticon et ses vulnérabilités
L'un des designs plus avancés pour le suivi des activations est connu sous le nom de Panopticon. Cette méthode tente de résoudre les défis d'espace et de temps en ajoutant des compteurs dans chaque ligne de la mémoire. Quand une ligne dépasse une limite d'activation définie, elle est signalée pour Atténuation.
Cependant, même Panopticon a montré des faiblesses. De nouveaux motifs d'attaque peuvent permettre à un adversaire de générer plus d'activations que le seuil, contournant ainsi les protections mises en place. Par exemple, un motif d'attaque appelé "Jailbreak" peut entraîner beaucoup plus d'activations que le seuil conçu par Panopticon, exposant les problèmes de sécurité sous-jacents de sa mise en œuvre.
Entrée de MOAT : une nouvelle approche
En réponse à ces défis, un nouveau design appelé MOAT a été créé. MOAT utilise deux Seuils internes importants pour améliorer la sécurité contre les attaques Rowhammer. Le premier seuil, appelé Seuil d'Éligibilité (ETH), décide si une ligne nécessite une atténuation. Le second, le Seuil ALERT (ATH), détermine quand un signal ALERT doit être envoyé pour interrompre les opérations de mémoire pour une protection supplémentaire.
MOAT est conçu pour atténuer les comptes d'activation de manière plus efficace que les conceptions précédentes, se concentrant sur le suivi d'une seule entrée pour chaque banque de mémoire plutôt que plusieurs entrées. Cela minimise les besoins en ressources tout en maintenant la sécurité.
Analyse de performance
À travers diverses évaluations de Charge de travail, il a été constaté que MOAT fonctionne bien dans des conditions normales. Pour des charges de travail comme SPEC et GAP, MOAT a montré un ralentissement moyen léger de seulement 0,28 % tout en utilisant seulement une petite quantité de SRAM pour le suivi.
Le design permet quelques activations entre les ALERT, ce qui nécessite une attention particulière. Cette flexibilité peut parfois être exploitée par des attaquants qui profitent des courtes fenêtres d'opportunité entre les signaux ALERT pour dépasser les seuils d'activation. Cependant, MOAT a des mécanismes en place pour contrer ce potentiel.
Charges de travail bénignes et malveillantes
MOAT a démontré son efficacité sous différents types de charges de travail. Dans des charges de travail décontractées-définies comme celles qui n'ont pas pour objectif d'exploiter des vulnérabilités-le nombre moyen d'activations reste significativement plus bas, contribuant à pratiquement aucun ralentissement. En revanche, lorsqu'un motif d'attaque est déployé, les activations moyennes peuvent augmenter considérablement, mais MOAT minimise efficacement les dommages durant ces tentatives malveillantes.
Répondre aux attaques de performance
Les attaques de performance sont un autre risque associé aux signaux ALERT. En coordonnant soigneusement les accès à la mémoire, un attaquant peut potentiellement ralentir le système. Cependant, l'impact sur la performance de telles attaques sous MOAT n'est pas aussi élevé qu'il pourrait l'être, avec une perte de débit maximum d'environ 52 % démontrée lors d'attaques bien coordonnées. Cela indique que, bien que les attaques de performance soient un problème potentiel, elles ne sont pas particulièrement dangereuses par rapport à d'autres types de problèmes de contention de mémoire.
Conclusion et recommandations
Alors que la technologie progresse, de nouvelles méthodes comme MOAT montrent une promesse d'amélioration de la sécurité de la DRAM contre les attaques Rowhammer. Les problèmes qui ont surgi avec les conceptions traditionnelles, y compris leurs vulnérabilités à des motifs d'attaque astucieux, mettent en évidence la nécessité d'une innovation continue dans les mécanismes de protection de la mémoire.
Il est essentiel que les fabricants de mémoire prennent en compte les implications pratiques de leurs conceptions, y compris s'assurer que leurs mises en œuvre soient sécurisées même dans des conditions d'attaque persistantes. Les conceptions futures doivent également trouver un équilibre entre performance, utilisation des ressources et sécurité pour s'assurer qu'elles puissent efficacement contrer les menaces émergentes dans le paysage en constante évolution de la cybersécurité.
En résumé, bien que les méthodes de mitigation actuelles aient progressé, il reste encore beaucoup de travail à faire pour rendre les systèmes DRAM entièrement sécurisés. La recherche et le développement continus seront cruciaux pour construire de futurs systèmes de mémoire capables de résister à la fois aux attaques existantes et nouvelles, protégeant finalement les données sensibles et maintenant l'intégrité du système.
Titre: MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters
Résumé: The security vulnerabilities due to Rowhammer have worsened over the last decade, with existing in-DRAM solutions, such as TRR, getting broken with simple patterns. In response, the DDR5 specifications have been extended to support Per-Row Activation Counting (PRAC), with counters inlined with each row, and ALERT-Back-Off (ABO) to stop the memory controller if the DRAM needs more time to mitigate. Although PRAC+ABO represents a strong advance in Rowhammer protection, they are just a framework, and the actual security is dependent on the implementation. In this paper, we first show that a prior work, Panopticon (which formed the basis for PRAC+ABO), is insecure, as our Jailbreak pattern can cause 1150 activations on an attack row for Panopticon configured for a threshold of 128. We then propose MOAT, a provably secure design, which uses two internal thresholds: ETH, an "Eligibility Threshold" for mitigating a row, and ATH, an "ALERT Threshold" for initiating an ABO. As JEDEC specifications permit a few activations between consecutive ALERTs, we also study how an attacker can exploit such activations to inflict more activations than ATH on an attack row and thus increase the tolerated Rowhammer threshold. Our analysis shows that MOAT configured with ATH=64 can safely tolerate a Rowhammer threshold of 99. Finally, we also study performance attacks and denial-of-service due to ALERTs. Our evaluations, with SPEC and GAP workloads, show that MOAT with ATH=64 incurs an average slowdown of 0.28\% and 7 bytes of SRAM per bank.
Auteurs: Moinuddin Qureshi, Salman Qazi
Dernière mise à jour: 2024-07-13 00:00:00
Langue: English
Source URL: https://arxiv.org/abs/2407.09995
Source PDF: https://arxiv.org/pdf/2407.09995
Licence: https://creativecommons.org/licenses/by/4.0/
Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.
Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.