Vous touchez à un point sensible ...

Historiquement , les ordinateurs étaient des mainframes où de nombreux utilisateurs distincts lancaient des sessions et traitaient sur le même machine physique. Les systèmes de type Unix (par exemple Linux), mais aussi VMS et ses proches (et cette famille comprend tous les Windows de la ligne NT, donc 2000, XP, Vista, 7, 8 ...), ont été structurés pour prendre en charge le modèle mainframe.

Ainsi, le matériel fournit des niveaux de privilèges . Un élément central du système d'exploitation est le noyau qui fonctionne au niveau de privilège le plus élevé (oui, je sais qu'il y a des subtilités en ce qui concerne la virtualisation) et gère les niveaux de privilège. Les applications s'exécutent à un niveau inférieur et sont empêchées de force par le noyau de lire ou d'écrire la mémoire de l'autre. Les applications obtiennent de la RAM par pages (généralement 4 ou 8 ko) à partir du noyau. Une application qui tente d'accéder à une page appartenant à une autre application est bloquée par le noyau, et sévèrement punie ("faute de segmentation", "faute de protection générale" ...).

Lorsqu'une application n'en a plus besoin une page (notamment à la fermeture de l'application), le noyau prend le contrôle de la page et peut la donner à un autre processus. Les systèmes d'exploitation modernes "vident" les pages avant de les rendre, où "effacement" signifie "remplissage avec des zéros". Cela empêche la fuite de données d'un processus à un autre. Notez que Windows 95/98 / Millenium n'a pas de pages vierges, et des fuites peuvent se produire ... mais ces systèmes d'exploitation étaient destinés à un seul utilisateur par machine.

Bien sûr, il existe des moyens d'échapper à la colère du noyau: quelques portes sont disponibles pour les applications qui ont "assez de privilèges" (pas le même genre de privilèges que ci-dessus). Sur un système Linux, il s'agit de ptrace (). Le noyau permet à un processus de lire et d'écrire la mémoire de l'autre, via ptrace (), à condition que les deux processus s'exécutent sous le même ID utilisateur, ou que le processus qui exécute ptrace () soit un processus "root". Une fonctionnalité similaire existe dans Windows.

Le fait est que les mots de passe dans la RAM ne sont pas plus sûrs que ce que le système d'exploitation autorise. Par définition, en stockant certaines données confidentielles dans la mémoire d'un processus, vous faites confiance au système d'exploitation pour ne pas le céder à des tiers. Le système d'exploitation est votre ami , car si le système d'exploitation est un ennemi, vous l'avez complètement perdu.

Vient maintenant la partie amusante. Depuis que le système d'exploitation impose une séparation des processus, de nombreuses personnes ont essayé de trouver des moyens de percer ces défenses. Et ils ont trouvé quelques choses intéressantes ...

• La "RAM" que voient les applications n'est pas forcément une vraie "mémoire". Le noyau est un maître des illusions, et donne des pages qui n'existent pas forcément. L'illusion est maintenue en échangeant le contenu de la RAM avec un espace dédié sur le disque, où l'espace libre est présent en plus grandes quantités; cela s'appelle mémoire virtuelle. Les applications n'ont pas besoin d'en être conscient, car le noyau ramènera les pages en cas de besoin (mais, bien sûr, le disque est beaucoup plus lent que la RAM). Une conséquence malheureuse est que certaines données, prétendument conservées dans la RAM , arrivent sur un support physique où elles resteront jusqu'à ce qu'elles soient écrasées. En particulier, il y restera en cas de coupure de courant. Cela permet des attaques où le méchant attrape la machine et s'enfuit avec, pour inspecter les données plus tard. Des fuites peuvent également se produire lorsqu'une machine est mise hors service et vendue sur eBay et que l'administrateur système a oublié d'effacer le contenu du disque.

  Linux fournit un système appelé mlock () qui empêche le noyau d'envoyer des pages spécifiques vers l'espace d'échange. Puisque le verrouillage des pages dans la RAM peut épuiser les ressources RAM disponibles pour d'autres processus, vous avez besoin de certains privilèges (root encore) pour utiliser cette fonction.

  Une circonstance aggravante est qu'il n'est pas nécessairement facile de garder une trace de l'endroit où votre le mot de passe est vraiment dans la RAM. En tant que programmeur, vous accédez à la RAM grâce à l'abstraction fournie par le langage de programmation. En particulier, les langages de programmation qui utilisent Garbage Collection peuvent copier de manière transparente des objets dans la RAM (car cela aide vraiment pour de nombreux algorithmes GC). La plupart des langages de programmation sont donc impactés (ex: Java, C # /. NET, Javascript, PHP, ... la liste est presque infinie).

• Hibernation ramène les mêmes problèmes, avec une vengeance. Par nature, l'hibernation doit écrire toute la RAM sur le disque - cela peut inclure des pages qui ont été verrouillées, et même le contenu des registres du processeur. Pour éviter les fuites dues à l'hibernation, vous devez recourir à des mesures drastiques comme le cryptage de l'ensemble du disque - cela implique naturellement de taper le mot de passe de déverrouillage chaque fois que vous réveillez la machine.

• Le modèle mainframe suppose qu'il peut exécuter plusieurs processus hostiles les uns aux autres, tout en maintenant une paix et un isolement parfaits. Le matériel moderne rend cela très difficile. Lorsque deux processus s'exécutent sur le même processeur, ils partagent certaines ressources, y compris la mémoire cache; les accès à la mémoire sont beaucoup plus rapides dans le cache qu'ailleurs, mais la taille du cache est très limitée. Cela a été exploité pour récupérer des clés cryptographiques utilisées par un processus, à partir d'un autre. Des variantes ont été développées qui utilisent d'autres ressources de type cache, par ex. prédiction de branche dans un CPU. Alors que la recherche sur ce sujet se concentre sur les clés cryptographiques, qui sont des secrets de grande valeur , elle pourrait vraiment s'appliquer à n'importe quelle donnée.

  De la même manière, les cartes vidéo peuvent faire un accès direct à la mémoire. Le fait que DMA ne puisse pas être abusé pour lire ou écrire de la mémoire à partir d'un autre processus dépend de la manière dont le matériel non documenté, les pilotes à source fermée et les noyaux collaborent pour appliquer les contrôles d'accès appropriés. Je ne parierais pas ma dernière chemise dessus ...

Conclusion: oui, quand vous stockez un mot de passe dans la RAM, vous faites confiance au système d'exploitation pour garder cela confidentiel. Oui, la tâche est difficile, voire presque impossible sur les systèmes modernes. Si certaines données sont hautement confidentielles, vous ne devriez vraiment pas utiliser le modèle mainframe et ne pas autoriser des entités potentiellement hostiles à exécuter leur code sur votre machine.

(Ce qui, au fait, signifie que des machines virtuelles hébergées et le cloud computing ne peut pas être sûr. Si vous êtes sérieux en matière de sécurité, utilisez du matériel dédié.)

Je pense que le système d'exploitation fait son travail et évite aux processus d'accéder à la mémoire allouée aux autres. Mais je pense que c'est faisable.

Oui, il est possible d'accéder à la mémoire d'un autre processus. Sous Windows, cela revient à avoir SE_DEBUG_PRIVILEGE et à utiliser ReadProcessMemory () pour extraire les informations souhaitées.

Vous pouvez faites la même chose à partir d'un pilote Windows, bien qu'il soit un peu plus difficile à faire en raison de certaines complications avec la mémoire actuellement paginée dans la moitié inférieure.

Dans les deux cas, vous devez avoir accès à un compte administratif, ou à un processus mal assigné SE_DEBUG_PRIVILEGE , ou à un processus avec ce privilège qui peut être persuadé de faire ce dont vous avez besoin.

Il s'agit donc de garantir que personne peut escalader pour obtenir ces privilèges. De manière plus réaliste, nous nous assurons que seuls les utilisateurs de confiance peuvent avoir ces privilèges. Si vous avez accès à un compte administratif, vous pouvez facilement lire un mot de passe directement dans la mémoire des processus d'un autre compte.

Sous Linux, vous pouvez réaliser la même chose avec ptrace ( ) et l'option PTRACE_PEEK_DATA .

Vous pourriez vous demander pourquoi ces fonctions existent en premier lieu? En fait, ils sont incroyablement pratiques pour les processus de débogage. En théorie, c'est quelque chose qu'un utilisateur administrateur peut souhaiter faire. Par contre, les utilisateurs normaux ne devraient pas avoir besoin et devraient être isolés les uns des autres.

C'est pourquoi les gens disent, depuis un certain temps, que tout exécuter sous le compte administrateur n'est généralement pas une bonne idée.

Je travaille dans le domaine de l'électronique grand public et la sécurité ici est quelque peu différente de celle de l'environnement serveur. Ici, nous devons supposer que le produit se trouve dans un environnement hostile. Ainsi, à des fins de gestion des abonnés, les clés sont conservées en sécurité. La première ligne de défense est que le SoC a des registres cachés auxquels même le système d'exploitation ne peut pas accéder, ils sont brûlés au moment de la fabrication et des fusibles à puce sont grillés, ce qui empêche l'accès. De plus, nous ne voyons pas les clés nous-mêmes car cela ne serait pas sûr dans l'atelier de production, au lieu de cela, elles sont pré-emballées avec une clé de lot que nous ne connaissons pas, seul le fournisseur de puces et la personne qui a créé la clé le savent (le maître clé peut être détruite après utilisation dans la puce). Une fois que la puce est chargée de secrets, elle peut être verrouillée et jamais * déverrouillée.

Si vous ne pouvez pas accéder aux clés, comment décrypter quoi que ce soit? Avec un coprocesseur cryptographique sur le SoC, vous pouvez charger des positions clés sans en connaître la valeur. Vous ne voyez pas non plus le microcode du crypto-processeur, car alors même au moment de la fabrication, vous ne pouvez rien injecter.

Si vous avez des clés ou des certificats qui ne rentrent pas dans les généreux registres de puces, vous devez les stocker dans la RAM et / ou la NVM, mais à cause du crypto-processeur vous n'avez pas besoin d'exposer ces valeurs. La RAM ou la NVM elle-même peut être brouillée par la puce avec une clé qui n'est connue de personne d'autre que d'elle-même.

Enfin, contrairement aux ordinateurs, les systèmes embarqués sécurisés ont également une certaine sécurité physique. Les pistes de connexion RAM ne sont pas autorisées à être sur la surface du PCB («vias enterrés»). En effet, s'il y a des éléments qui sont en clair dans la RAM, vous devez limiter l'accès, il est possible de ralentir ou de geler le processeur, puis de sonder la RAM.

Enfin pour les cartes à puce, il a été possible d'intercepter les transactions entre le SoC et la carte. C'est ce qu'on appelle le «partage de carte», la solution à cela est de crypter les transactions entre la carte et le SoC et de les lier les unes aux autres afin qu'elles ne puissent pas être échangées ou partagées.

Je sais que DRM / La sécurité du contenu est impopulaire auprès de certaines personnes sur les interwebs, mais j'ai pensé partager quelques concepts de haut niveau d'une industrie qui a des exigences de sécurité particulières.

* En théorie.

Il y a du travail en cours sur la plate-forme Linux pour interdire l'accès à la mémoire d'un processus en cours d'exécution, même par un super-utilisateur. Avec SELinux, vous pouvez le faire à partir de Fedora 17: SELinux Deny Ptrace.

Quelle langue / plate-forme utilisez-vous?

S'il s'agit de .NET, consultez le contrôle PasswordBox et la classe SecureString.

La classe SecureString représente un moyen de stocker le mot de passe en mémoire sans le rendre accessible à quiconque, même aux pirates qui jettent un œil sur la mémoire de votre application.

Le contrôle PasswordBox est une zone de texte qui incorpore SecureString, de sorte que vous pouvez garder le mot de passe sûr et sécurisé de bout en bout.

Non, les mots de passe stockés en clair dans la RAM ne doivent pas être considérés comme sûrs. Généralement, sur les architectures x86 et x86-64 avec des interfaces telles que FireWire, ExpressCard et Thunderbolt qui accèdent directement, ces interfaces peuvent être utilisées pour contourner la protection de la mémoire du système d'exploitation, et ainsi obtenir des mots de passe en clair de la mémoire.

Utiliser FireWire pour obtenir des mots de passe en clair n'est pas simplement une attaque théorique. Des logiciels sont maintenant vendus pour obtenir des mots de passe en clair pour les disques chiffrés BitLocker, PGP et TrueCrypt ElcomSoft déchiffre les conteneurs BitLocker, PGP et TrueCrypt

Il existe un fil distinct sur security.stackexchange qui concerne comment atténuer les attaques de base DMA Désactivez en toute sécurité Firewire / Thunderbolt, corrigeant l'exposition DMA sous Linux. Microsoft a également un article de la base de connaissances pour atténuer les attaques via Firewire et Thunderbolt sur BitLocker Bloquer le pilote SBP-2 et les contrôleurs Thunderbolt pour réduire les menaces 1394 DMA et Thunderbolt DMA sur BitLocker

Plus des détails sur cette attaque peuvent être trouvés sur Wikipedia Attaque DMA.

En plus de toutes les attaques logicielles exploitant les vulnérabilités du système d'exploitation, si un attaquant a un accès physique à votre machine, il peut potentiellement lire vos clés directement depuis votre mémoire.

Comment l'impact du froid les attaques au démarrage doivent-elles être minimisées?

Vous soulevez un problème valide et en fait, cela est souvent traité dans les logiciels liés à la sécurité. Lorsque des objets sensibles tels que des clés ne sont plus nécessaires, certains programmes ne rendront pas simplement la mémoire à la bibliothèque de gestion de la mémoire ou au système d'exploitation, mais effaceront d'abord les bits sensibles en les écrasant.

Bien sûr, certains les programmes doivent maintenir les clés en permanence. Par exemple ssh-agent . Donc, ces programmes sont vulnérables. Si vous êtes un simple utilisateur sur une machine multi-utilisateurs, la mémoire dynamique de votre ssh-agent est vulnérable à quiconque possède des privilèges root et peut voir n'importe quelle partie de la mémoire de la machine.

Et de toute façon, même les programmes qui utilisent brièvement des clés ont encore une fenêtre de vulnérabilité. Une microseconde peut être une éternité en temps CPU. Un super-utilisateur malveillant pourrait même suspendre le programme indéfiniment sur certaines instructions, alors que ce programme a des données sensibles sous forme de texte brut quelque part en mémoire.

Donc, en règle générale, n'effectuez aucune opération sensible à la sécurité l'informatique sur la machine si cette machine a des utilisateurs ou des logiciels auxquels vous ne faites pas confiance, et un système d'exploitation auquel vous ne faites pas confiance pour empêcher ces utilisateurs ou logiciels d'élever leurs privilèges afin qu'ils puissent consulter vos clés ou vos données en clair.

Lorsque vous utilisez un client sécurisé, vous faites confiance à ce programme, et à toute la plate-forme sur laquelle il s'exécute jusqu'au matériel et à toutes les instructions de la machine dans chaque programme préinstallé ou installé par la suite.

(Le soi-disant "calcul de confiance" ne résout pas ce problème; il change simplement qui sont les méchants.)

Même si les clés sont chiffrées, l'attaque de démarrage par la morue peut récupérer votre mot de passe: regardez cette vidéo de l'attaque de démarrage à froid en cours. http://www.youtube.com/watch?v=JDaicPIgn9U

Il y a un certain degré de confiance qui devra toujours exister avec la sécurité du système d'exploitation et des applications en cours d'exécution, à moins bien sûr que vous n'ayez le temps de lire tout le code source et de vérifier qu'aucun exploit n'existe. Si vous aviez ce temps, aucune confiance n'est nécessaire, vous le sauriez. Mais ce n'est pas probable. Si tout cela est possible, il est préférable d'exécuter des projets propriétaires sur une machine et de conserver tout ce qui doit être approuvé en cours d'exécution sur une autre machine. La séparation physique fait très bien l'affaire par rapport aux solutions basées sur la foi.

Une étude quelque peu pertinente est ce qui doit être fait pour s'assurer que même le superutilisateur ne peut pas accéder à un secret qui est stocké dans la mémoire d'un autre processus. Je n'ai jamais vraiment terminé l'effort, donc ce n'est qu'un point de départ. Et cela ne fait rien pour empêcher les attaques physiques telles que les attaques de démarrage à froid.

Garder les secrets de root sur Linux

Cela ne résout pas votre problème, même si une astuce que vous pouvez utiliser pour minimiser le temps où un mot de passe ou un autre secret est stocké en mémoire est de le remettre à zéro par la suite.

Attention à utiliser une méthode qui garantit vous écrivez dans la même mémoire au lieu d'allouer un nouvel objet avec une valeur différente. Par exemple, en Java, vous utiliseriez un byte [] au lieu d'une String pour conserver un secret.

Étant donné que cela pourrait s'appliquer à un certain nombre de systèmes d'exploitation avec différents niveaux de protection, quelques points à garder à l'esprit:

1. Quoi qu'il en soit, vous ne pouvez pas empêcher un mot de passe d'être en mémoire à un moment donné. Si quelqu'un a un accès en direct à la mémoire de votre application, vous ne pouvez pas l'empêcher de la voir.

2. Les mots de passe ont généralement plus de valeur que ce qu'ils protègent - les utilisateurs réutilisent les mots de passe et en acceptant la connexion par mot de passe, vous assumez un certain niveau de responsabilité pour garder leur mot de passe secret, même si les données qu'il protège sont compromises. Vous pouvez quelque peu atténuer les dommages d'une attaque sur la mémoire froide (azote liquide ou hibernation) en hachant le mot de passe de vos utilisateurs avec une fonction de hachage lent (PBKDF, scrypt, bcrypt) et en utilisant le hachage pour l'authentification.

3. Effacer votre mot de passe utilisateur de la mémoire est une bonne pratique. Il y a de nombreux pièges à faire pour faire cela correctement, alors assurez-vous d'utiliser une bibliothèque appropriée: Windows Exemple Linux