Suite à la publication de mes billets précédents sur les failles MELTDOWN et SPECTRE, j’ai répondu à diverses questions, et je pense que certaines méritent une réponse publique.

Les attaques par canaux cachés n’ont rien de nouveau

Un de mes interlocuteurs pensait que ces failles étaient les premières failles de sécurité basées sur un problème dans le matériel. Ce n’est pas le cas — peut-être serait-il en revanche exact que ce sont les premières failles de sécurité basées sur un problème dans le matériel qui soient venues à l’attention des journalistes.

Les failles MELTDOWN et SPECTRE s’appuient sur l’exploitation de « canaux cachés » permettant de transmettre de façon indirecte des informations d’un logiciel privilégié (au sens qu’il a accès à des informations sensibles) vers un logiciel intrus, ces canaux de communication découlant de certaines fonctionnalités du matériel (mémoires caches, notamment). Les attaques par canaux cachés n’ont rien de nouveau.

Une attaque par canal caché tend à recouvrer des informations secrètes en exploitant des effets indirects de l’exécution du programme manipulant ces données. Par exemple, dans le cas de cartes à puce contenant des clefs cryptographiques secrètes et qui doivent le rester, on a appliqué des attaques consistant à mesurer finement la consommation électrique instantanée de la carte à puce ou son rayonnement électromagnétique. Dans le cas de logiciels sensibles s’exécutant sur la même machine que des logiciels malveillants (cas réaliste par exemple dans le cas de cloud computing, où des applications de plusieurs clients fonctionnent sur le même serveur), le logiciel malveillant peut notamment observer de petites fluctuations de son temps d’exécution dues à l’activité du logiciel sensible. Je n’ai pas le temps ce soir de rechercher les premières propositions de ce type d’attaques, mais je relève notamment l’attaque de Daniel J. Bernstein en 2005 contre des logiciels implantant le standard de chiffrement AES.

Ce type d’attaques est maintenant tellement représenté dans la littérature scientifique et technique que certains logiciels sont « durcis » pour éviter de laisser prise à ces observations exploitant l’isolation imparfaite fournie par les processeurs. Par exemple, pour éviter que des mesures fines du temps qu’un logiciel met à chiffrer des données ne soient exploitées pour retirer des informations sur les clefs cryptographiques, on mettra en œuvre du chiffrement en temps constant. Pour éviter que des informations ne fuient par les caches (je ne vais pas expliquer en quoi cela consiste, c’est assez technique), on va programmer les logiciels d’une façon à ne pas avoir d’action sur le cache qui permette de dériver des informations sur les données secrètes. D’ailleurs, un des buts d’une thèse que je dirige, celle de Valentin Touzeau, est d’analyser les logiciels pour détecter de telles vulnérabilités.

Il y a déjà eu des trous de sécurité importants dans le matériel, y compris d’Intel

Certains matériels Intel contiennent, en sus du processeur principal, un processeur auxiliaire nommé « moteur de gestion », caché du système d’exploitation installé sur le processeur principal et comportant son propre système d’exploitation et logiciels. En 2017 il a été révélé que ce moteur de gestion était vulnérable à des attaques.

Ce n’est pas la première fois qu’il y a des trous de sécurité importants nécessitant des mises à jour massives chez les prestataires d’hébergement

Je ne vais pas refaire l’historique de tous les trous de sécurité trouvés dans les logiciels utilisés chez les hébergeurs et me contenterai de mentionner le fait suivant. En 2008, donc à une époque où les services en ligne étaient déjà bien développés, avec beaucoup d’informations personnelles stockées chez des prestataires, on s’est aperçu que le générateur de clefs cryptographiques SSH et SSL livré notamment dans les distributions Linux Debian et Ubuntu avait été modifié, apparemment par erreur naïve et non par malice, de sorte que toutes les clefs générées étaient vulnérables. Cela voulait dire que des gens malveillants pouvaient se faire passer auprès de divers systèmes pour des utilisateurs ou administrateurs légitimes, ou encore intercepter des communications Web réputées sécurisées (le fameux logo cadenas) en se faisant passer pour un site légitime et récupérer toutes les informations secrètes transmises (mots de passe, y compris bancaires, etc.).

Malgré l’importance et la stupidité de ce bug, qui a nécessité une mise à jour d’urgence dans un très grand nombre de systèmes (y compris des systèmes non basés sur Debian ou Ubuntu, puisque ce qui compte c’est la machine qui avait généré les clefs), la presse grand-public n’en a pas parlé.

Il existe de la recherche universitaire en sécurité informatique

Il existe dans les universités, ou des organismes tels que le CNRS ou l’INRIA, de la recherche en sécurité informatique. Celle-ci n’est l’apanage ni des entreprises privées telles que Google, ni des organismes très orientés applications industrielles tels que le CEA, ni des services gouvernementaux spécialisés comme l’ANSSI ou la DGA-MI. D’ailleurs, les vulnérabilités MELTDOWN et SPECTRE ont été découvertes conjointement par des chercheurs de l’université technique de Graz, en Autriche, et une jeune chercheuse de cette équipe a rejoint le CNRS l’an dernier.

Ce qui est en revanche exact, c’est que les entreprises comme Google, Amazon, Facebook ou Microsoft ont des moyens sans commune mesure avec les laboratoires universitaires. Ainsi, il y a quelques années, j’ai vu un collègue recruter pour une des équipes de sécurité chez Google ; il « faisait son marché », envisageait de débaucher des universitaires (dont moi), etc., avec un budget pour 20 personnes. Par comparaison, le CNRS, tous laboratoires confondus, recrute cette année, est c’est exceptionnellement généreux, 2 jeunes chercheurs en sécurité informatique.

Où est la nouveauté ?

La nouveauté consiste en l’utilisation active de l’exécution spéculative des processeurs à hautes performances, conjointement aux canaux cachés.

Quel impact ?

À lire certains, la vulnérabilité MELTDOWN aurait permis de lire à volonté n’importe quelle portion de la mémoire de la machine attaquée. Or, après lecture plus approfondie des documents publiés par Intel et Google, on s’aperçoit que les données attaquables sont celles résidant en mémoire cache de niveau 1 au moment de l’attaque, ce qui est une infime portion de la mémoire de la machine. Un des codes de démonstration de la faille qui circule publiquement fait juste avant l’attaque un appel au système qui a pour effet secondaire de charger dans le cache de niveau 1 des informations qu’il va ensuite lire via MELTDOWN ; ce code de démonstration se contente cependant de provoquer le chargement de données absolument pas sensibles. Il n’est pas évident pour moi qu’il soit possible de forcer le système d’exploitation à manipuler des données sensibles de façon à ce qu’elles soient disponibles en cache de niveau 1 au moment de l’attaque (il est cependant possible qu’il y ait un autre volet de l’attaque qui n’ait pas encore été rendu public au 8 janvier et que la présence dans le cache L1 ne soit pas nécessaire).

En l’état de mes informations, je ne comprends donc pas trop l’urgence qu’il y a à mettre en œuvre des contre-mesures, éventuellement mal maîtrisées ou occasionnant des pertes notables de performance, contre l’attaque MELTDOWN.

J’insiste cependant que je ne suis pas un expert en sécurité informatique de bas niveau, et que je n’ai accès à aucune information secrète.

En revanche, les attaques MELTDOWN et SPECTRE m’inquiètent en ce qu’elles démontrent que les processeurs actuels, avec leurs nombreux dispositifs destinés à augmenter les performances, notamment les mémoires cache et l’exécution spéculative, sont devenus d’une telle complexité qu’il existe des interactions insoupçonnées des créateurs de ces systèmes. La compartimentation proposée par ces processeurs est très imparfaite et il est difficile de penser à tous les biais possibles d’attaque. On peut également se poser des questions sur le modèle de sécurité basé sur la séparation mémoire matérielle entre processus, et des processus entre utilisateurs : est-il adapté à une époque où le navigateur Web exécute des logiciels de toute provenance à l’aide de mécanismes complexes et donc potentiellement vulnérables ? Je n’ai évidemment pas de réponse à ces questions.

PS: L'hyperthreading peut sans doute aussi aboutir à ce que certaines données sensibles soient chargées en cache...