Pourquoi chiffrer des données en mémoire?
J'ai vu que KeePass non seulement crypte son fichier de base de données de mots de passe, mais qu'il peut également crypter les mots de passe qu'il contient en mémoire. C'est juste un exemple. Je pense à un nouveau projet traitant des données sensibles/personnelles et maintenant je me demande si je dois aussi crypter les données conservées en mémoire. Ce projet serait implémenté avec Java SE et une application supplémentaire Android. Il n'y aura aucune donnée stockée dans le cloud ou sur un serveur dans ce cas particulier). Les données de Android seront importées par l'application Java SE Desktop via une connexion par câble).
Mais pourquoi est-ce nécessaire? Les systèmes d'exploitation modernes ne fonctionnent-ils pas avec la gestion de la mémoire virtuelle de sorte qu'il n'est pas possible pour les processus espace utilisateur/mode utilisateur d'accéder à la mémoire des autres processus?
S'agit-il simplement d'une autre ligne de défense s'il existe une vulnérabilité de système d'exploitation rendant possible l'accès à la mémoire étrangère? Dans ce cas, je pense qu'il serait beaucoup plus facile de voler le fichier de données et d'utiliser un enregistreur de frappe pour attraper le mot de passe que l'utilisateur entre au lieu de voler les données via l'accès à la mémoire.
Dans un monde parfait, vous avez raison: il ne devrait pas être utile de conserver les données cryptées dans la RAM. Le système d'exploitation doit conserver une forte séparation entre les processus, effacer RAM lorsqu'il est réaffecté à un autre processus et, si le modèle d'attaque permet à un attaquant de voler l'appareil par la suite et de faire une analyse du disque dur, chiffrer le swap (ou n'utilisez aucun swap du tout, ce qui peut avoir plus de sens pour un appareil doté d'un stockage Flash).
Dans un monde réaliste, où les systèmes d'exploitation et l'administration des systèmes sont des tâches humaines et donc intrinsèquement imparfaites, vous voudrez peut-être ajouter quelques garanties, y compris le maintien des données chiffrées en RAM et l'instruction du système d'exploitation pas pour écrire des données dans l'espace de swap (sur les systèmes de type Unix, cela se fait avec mlock()). Les choses RAM sont plus un rituel psychologique qu'une véritable défense; sa principale vertu est de faire en sorte que le développeur se sente mieux.
Ne vous embêtez pas à le faire en Java, de toute façon. Le garbage collector copiera les objets dans RAM de manière transparente (cela fait partie des algorithmes GC les plus efficaces et vous ne pouvez pas l'empêcher) donc aucun niveau de cryptage par votre application ne sera garantir qu'aucune version claire des clés n'existe à tout moment dans RAM.
Les systèmes d'exploitation modernes fonctionnent avec la gestion de la mémoire virtuelle de sorte que par défaut, il n'est pas possible pour les processus espace utilisateur/mode utilisateur d'accéder directement à la mémoire des autres processus.
Mais sous Windows (je ne sais pas si cela s'applique également à Linux), il existe des interfaces qui permettent aux utilisateurs standard d'accéder à la mémoire de processus d'autres processus exécutés avec les mêmes informations d'identification.
Il existe de nombreux programmes qui utilisent cette interface. Un exemple très simple est HxD - un éditeur hexadécimal gratuit qui permet de visualiser et même d'éditer la mémoire de processus d'autres processus.
La mémoire peut devenir visible pour d'autres processus en:
- être disponible une fois que le processus d'origine l'utilisant l'a renvoyé au système d'exploitation. La mémoire n'est pas effacée et un processus successif pourrait effectuer une
malloc()et récupérer des informations appartenant à un processus en cours d'exécution (note chapitre 8 des pilotes de périphériques Linux - en particulier la note de bas de page sur le premier page) - pages échangées sur le disque par le système d'exploitation. Ceux-ci peuvent alors devenir disponibles pour un processus qui regarde le disque/stockage.
Par conséquent, la mémoire non chiffrée peut devenir visible pour d'autres processus.
This est un lien très intéressant, et notez cette citation:
Cette volatilité dépend cependant beaucoup de l'ordinateur en question - car lorsqu'un ordinateur ne fait rien, la mémoire anonyme peut persister pendant de longues périodes. Par exemple, dans certains ordinateurs, les mots de passe et autres données précalculées ont été facilement récupérés plusieurs jours après avoir été saisis ou chargés en mémoire
Il y a certains problèmes spécifiques au monde Java Java que vous devez prendre en compte. C'est une pratique normale que l'on fait des vidages de tas de la JVM si un problème technique survient. Je fais face à une application qui a même une interface utilisateur dédiée pour cela. Cela pourrait être incroyablement précieux, par exemple pour trouver des fuites de mémoire. Et bien sûr - oui - les informations sensibles vont dans le vidage. Donc, si quelqu'un casse dans l'application (par exemple, contourne la connexion avec un SQL Injection :)) ...: X. Ou si l'utilisateur administratif est une personne curieuse ...: X
Je sais que cela ne devrait pas se produire dans le "monde idéal".
Vous pouvez également configurer la JVM pour effectuer un vidage sur les exceptions de mémoire insuffisante. Depuis Java 1.4 cela pourrait ressembler à ceci:
-XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to dump file>
Un attaquant peut trouver un exploit qui fait planter l'application sans mémoire et peut trouver un autre exploit (par exemple, bogue de traversée de chemin de fichier) pour voler votre vidage!
L'autre chose à laquelle vous devriez penser est que certaines données sensibles devront se retrouver dans votre application. Donc, à certains moments, vous l'avez en mémoire. Il n'y a rien ou presque rien à faire à ce sujet. Mais ce que vous pouvez faire, c'est de le nettoyer plus rapidement. Par exemple, prenez un mot de passe utilisateur. Si vous le stockez dans une instance de chaîne, vous n'avez pas beaucoup de contrôle sur le moment où il sera récupéré. Ainsi, les API Nice traitent généralement ces données dans des tableaux de caractères (char []) qui peuvent être mis à zéro après utilisation.
Google a un exploit appelé RowHammer qui permet à un utilisateur de lire le contenu de RAM qui est adjacent aux données en cours d'écriture. Cryptage du RAM rendrait cet exploit beaucoup plus difficile.
"Rowhammer" est un problème avec certains périphériques DRAM récents dans lesquels l'accès répétitif à une ligne de mémoire peut provoquer des retournements de bits dans les lignes adjacentes. Nous avons testé une sélection d'ordinateurs portables et avons constaté qu'un sous-ensemble d'entre eux présentait le problème. Nous avons construit deux exploits d'escalade de privilèges de travail qui utilisent cet effet. Un exploit utilise des retournements de bits induits par des coups de bélier pour obtenir les privilèges du noyau sur Linux x86-64 lorsqu'il est exécuté comme un processus utilisateur non privilégié. Lorsqu'il était exécuté sur une machine vulnérable au problème du marteau-piqueur, le processus était capable d'induire des retournements de bits dans les entrées de table de pages (PTE). Il a pu l'utiliser pour obtenir un accès en écriture à sa propre table de pages, et donc un accès en lecture-écriture à l'ensemble de la mémoire physique.
Nous ne savons pas avec certitude combien de machines sont vulnérables à cette attaque, ni combien de machines vulnérables existantes sont réparables. Notre exploit utilise l'instruction CLFLUSH x86 pour générer de nombreux accès à la DRAM sous-jacente, mais d'autres techniques peuvent également fonctionner sur des systèmes non x86.
Nous nous attendons à ce que notre exploit basé sur PTE puisse fonctionner sur d'autres systèmes d'exploitation; il n'est pas intrinsèquement spécifique à Linux. Causer des flips de bits dans les PTE n'est qu'une des voies d'exploitation; d'autres voies pour exploiter les retournements de bits peuvent également être pratiques. Notre autre exploit le démontre en s'échappant du sandbox Native Client.
KeePass a spécifiquement une extension chrome, donc d'autres extensions Chrome pourraient lire la même mémoire que celle utilisée par KeePass. Les protections de la mémoire du système d'exploitation ne vont pas aider dans ce sens) D'où le chiffrement.
Une autre famille de raisons pour le chiffrement de la mémoire, en général, est qu'il existe des attaques matérielles où quelqu'un peut accéder à la mémoire:
- Attaques de démarrage à froid permet à un attaquant de redémarrer la machine tout en gardant la mémoire intacte. Ils démarrent ensuite sur un autre système d'exploitation sans protection de la mémoire et effectuent une analyse.
- Le gel des puces RAM les oblige à conserver leur contenu même après une panne de courant. Un pirate disposant d'un accès physique pourrait donc supprimer le RAM et placez-le dans un conteneur de stockage d'azote liquide, déplacez le RAM vers un autre emplacement, réinstallez-le et scannez-le.
- Différents bus matériels tels que PCI et Firewire prennent en charge DMA qui permet au périphérique d'accéder directement à la mémoire. Ainsi, un pirate pourrait insérer un appareil dans la machine qui lit la RAM.
Note latérale: Intel et AMD offrent tous les deux RAM en tant que fonctionnalité maintenant.
La raison pour laquelle cela semble être une bonne idée est que vous souhaiterez protéger les données contre le vol alors qu'elles résident en mémoire. Cela repose sur l'hypothèse que les données de la base de données réelle sont cryptées (comme tous les PII devraient l'être) mais restent non cryptées en mémoire lors de leur traitement. Cela serait assez difficile à faire pour diverses raisons soulignées par d'autres commentateurs et introduirait une grande complexité en termes de fonctionnement des applications avec les données chiffrées en mémoire.
Une solution meilleure et plus réalisable consiste à assurer un contrôle d'accès approprié à la base de données/au système et également à ce que le SGBD s'exécute sous un compte d'utilisateur "normal" et non avec un compte élevé tel que SYSTEM, etc. peut mettre en place, comme un outil de surveillance de SGBD que vous pouvez configurer pour regarder de grandes sélections sur des tables sensibles, etc. et rapporter tout ce qui sort de l'ordinaire. De cette façon, vous pouvez voir si certains processus de sélection tentent d'extraire de grandes quantités de données.