Vous êtes ici
Après Meltdown et Spectre, comment sécuriser les processeurs?
Un logiciel sans bug est-il toujours résistant aux attaques quand on l’utilise sur notre ordinateur ou notre smartphone ? On serait plus rassurés de répondre par l’affirmative, et pourtant, en regardant de très près le fonctionnement de nos machines, la situation est loin d’être garantie.
La course à la performance…
Il existe en informatique différentes couches d’abstraction. Il y a d’abord les programmes que l’on connaît, à destination des utilisateurs finaux. Ceux-ci tournent sur un système d’exploitation, lequel communique avec le matériel par le biais d’un driver (pilote). Le matériel lui-même comprend un ensemble d’instructions, et peut être implémenté de plusieurs façons différentes, appelées micro-architectures.
Pour écrire un programme, un développeur a besoin de communiquer avec le système d’exploitation, mais pas de comprendre 100 % de ce système d’exploitation. De manière similaire, pour écrire un système d’exploitation, un développeur a besoin de communiquer avec le matériel, mais pas de comprendre 100 % des composants matériels. Ainsi, chaque couche est conçue pour avoir une interface avec la couche du dessus, utilisable sans avoir besoin de maîtriser parfaitement son fonctionnement. Cela rend plus faciles le développement d’applications ainsi que les changements concernant le matériel : il est possible pour les fabricants de modifier la façon dont le matériel fonctionne sans nécessité de réécrire tous les programmes.
Cela tombe bien, car les fabricants changent sans cesse le matériel pour l’améliorer. En effet, le principal argument de vente d’un ordinateur ou d’un smartphone, c’est sa performance : nous voulons que nos programmes préférés s’ouvrent rapidement, et qu’ils soient réactifs. À cet égard, s’il est un composant de nos appareils à avoir particulièrement évolué, c’est le processeur. Il constitue le cerveau de la machine. C’est lui qui reçoit toutes les instructions et qui les traite : il effectue les calculs, les accès en mémoire pour chercher des données, et vérifie les autorisations pour chacune de ces opérations. Afin de rester dans la course, les fabricants ont rendu les processeurs de plus en plus complexes. Ils ont ajouté, d’une part, des unités matérielles pour optimiser toutes ces opérations et, d’autre part, plusieurs « astuces » pour éviter que le processeur ne perde du temps.
… En dépit de la sécurité ?
Début janvier 2018, deux importantes attaques au niveau des processeurs, nommées Meltdown et Spectre, ont été révélées et ont beaucoup fait parler d’elles. Ces failles critiques ont en réalité été découvertes à quelques mois d’intervalle et de manière indépendante par plusieurs groupes de chercheurs – incluant Google et Graz University of Technology, en Autriche. Les attaques Meltdown et Spectre exploitent les « astuces » du processeur. Ce dernier a parfois besoin d’informations qu’il n’a pas immédiatement à sa disposition pour pouvoir effectuer la prochaine opération. Pour ne pas perdre de temps à attendre ces informations, et donc pour gagner en rapidité, le processeur anticipe les prochaines opérations à exécuter. Il peut arriver qu’il se trompe, auquel cas le processeur revient en arrière sur ses calculs afin de ne pas rendre un mauvais résultat. Les attaques révélées consistent à duper le processeur, pour lui faire commencer à exécuter des opérations qu’il n’est pas censé effectuer. Au final, le processeur se rend compte qu’il n’aurait pas dû faire cela, et le programme ne verra aucun effet direct. Cependant, même si le monde extérieur ne voit pas le résultat de ces opérations, celles-ci ont quand même été effectuées, laissant des traces dans chacune des unités du processeur. Un attaquant peut donc récupérer de manière indirecte des traces d’une « exécution fantôme », et ce même si le programme ne contient aucune faille logicielle.
Des problèmes loin d’être nouveaux
Si l’exploitation de cette exécution fantôme est une nouveauté dans Spectre et Meltdown, la récupération de traces d’opérations secrètes au niveau de la micro-architecture n’est en réalité pas nouvelle. Cela fait plus de vingt ans que des attaques exploitant la micro-architecture ont été théorisées et une dizaine d’années que les premières attaques ont été montrées en pratique. Spectre et Meltdown se fondent sur l’ensemble de ces travaux de recherche.
Ces dernières années, une communauté de chercheurs s’est en particulier intéressée aux attaques exploitant une petite mémoire très rapide située au niveau du processeur, appelée le cache. Les processeurs contiennent un cache car la mémoire principale – aussi appelée RAM – est en fait assez lente par rapport à la vitesse de calcul du processeur. Le cache, même s’il est très rapide, est très limité en capacité : sur un processeur récent, il ne renferme que quelques mégaoctets, à peine plus qu’une photo en haute définition. Évidemment, au vu de sa taille, nos photos ne sont pas stockées dessus. Le processeur y garde les dernières données utilisées afin que les accès suivants soient les plus rapides possible.
Cela pose déjà beaucoup de problèmes de sécurité, car un attaquant peut deviner ce que fait un autre programme en espionnant le temps que prennent ses propres accès mémoire. Il est ainsi possible d’attaquer certaines implémentations d’algorithmes de chiffrement pourtant sûrs comme AES ou RSA.
Changer de paradigme pour mieux sécuriser les processeurs
Si les différentes couches d’abstraction ont des effets bénéfiques en facilitant le développement et la rétro-compatibilité des logiciels, elles constituent un inconvénient sur le plan de la sécurité. On a en effet longtemps considéré la sécurité informatique comme étant surtout la sécurité des logiciels, en écartant complètement le matériel du tableau.
Or, au final, le logiciel tourne bel et bien sur le matériel : il n’est donc pas possible de dissocier entièrement les deux. Le fait de ne pas devoir comprendre toutes les subtilités du matériel – par ailleurs de plus en plus complexe – pour développer des logiciels, laisse donc la porte ouverte à des vulnérabilités comme les attaques sur le cache décrites précédemment, ou encore Spectre et Meltdown. On en arrive à la conclusion que ce paradigme, pourtant largement répandu, doit être changé pour garantir la sécurité de nos systèmes d’information..
Cela ne va pas sans poser problème. Tout d’abord, il n’existe aujourd’hui pas de méthode efficace pour détecter si de telles attaques ont lieu sur un système – car elles ne laissent aucune trace sur les logiciels ou les fichiers présents dans la machine –, ou pour vérifier si un programme comme un logiciel de chiffrement laisse fuiter des informations secrètes au travers de la micro-architecture. Pour corser le tout, ces attaques ont pour cause des optimisations de performance qui non seulement sont présentes depuis quinze ou vingt ans dans les processeurs, mais se révèlent en outre extrêmement critiques pour la performance de ceux-ci. Or, il n’est simplement pas possible pour les constructeurs de se passer de ces optimisations. En clair, les attaques étant dues à des optimisations de performance, pouvoir se passer des attaques sans se passer des performances relève de la gageure !
Les points de vue, les opinions et les analyses publiés dans cette rubrique n’engagent que leur auteur. Ils ne sauraient constituer une quelconque position du CNRS.
Les autres points de vue
Clémentine Maurice est chargée de recherche CNRS en sécurité informatique à l’Irisa (Institut de recherche en informatique et systèmes aléatoires)...