Meltdown et Spectre : scandale technologique ou fatalité ?

Les failles de sécurité d'Intel, c'est l'heure de gloire des responsables sécurité des fabricants de puces. Ils l'attendaient depuis des années.  Car la faille Intel n'est pas un problème de compétence, mais de culture de sûreté. C'est l'obsession, pour tous ces fabricants, de la course à la performance qui en est à l'origine. Pour prendre la mesure du spectacle qui se déroule sous nos yeux, il faut comprendre la nature de ces failles pour en tirer les leçons car d'autres vont suivre.

Spectre

Les microprocesseurs modernes anticipent les instructions qu'ils doivent effectuer. Ils n'attendent pas qu'elles arrivent de la mémoire, ce qui à l'échelle de temps des microprocesseurs, représente une éternité. A ce niveau élémentaire, les microprocesseurs sont souvent dans le bon et ils gagnent ainsi du temps et en performance. Si le microprocesseur s'est trompé, il fait marche arrière et exécute la bonne instruction qui lui est entretemps parvenue. Il est censé tout effacer des effets de l'instruction qui n'était pas la bonne. C'est là qu'est la faille Spectre : il reste des traces exploitables. Or, aucune sécurité ne contrôle leur absence.

Les chercheurs ont eu l'idée de forcer le microprocesseur à anticiper une instruction venant d'un autre programme donnant accès à des informations confidentielles de ce dernier.

Au niveau logiciel, un tel accès est impossible : ce sont les techniques d'isolation entre programmes qui tournent sur un même ordinateur. Ainsi, plusieurs utilisateurs ou plusieurs programmes peuvent se partager le même microprocesseur en toute sécurité.

Ce que ces techniques connues depuis longtemps n'avaient pas prévu, c'est que, à un niveau inférieur, ces violations peuvent avoir lieu au niveau matériel, mais surtout que les conséquences de ces violations ne seraient pas annihilées complètement lorsque le microprocesseur réalise son erreur.

Ceci dit, il faudrait que l'attaquant ait accès au même microprocesseur que la victime, qu'il sache où le programme utilisé par la victime stockera les informations intéressantes ou qu'il en connaisse les instructions sensibles. Car les chercheurs ont décortiqué le programme tiers qu'ils avaient, en fait, écrits eux-mêmes, puis ils se sont mis dans la peau d'un hacker... à ceci près : ils savaient déjà ce qu'ils cherchaient !

Ce n'est pas seulement Intel qui est impacté: ARM et AMD le sont aussi. Des remèdes sont possibles mais coûteux comme interdire toute anticipation d'instruction, au prix d'une sérieuse dégradation des performances. La seule bonne nouvelle est que seul le secret des données peut être violé, par leur intégrité.

Meltdown

Avec Meltdown, c'est une autre vulnérabilité qui viole le principe de séparation entre la mémoire système (kernel), qui contient tous les secrets du PC, et mémoire utilisateur. Quand le PC doit répondre à une sollicitation système (écriture d'un fichier, ouverture d'une connexion réseau...), le microprocesseur passe en mode kernel avant de revenir au mode utilisateur. Le passage d'un mode à l'autre est extrêmement coûteux en temps car il faut passer d'une zone mémoire dite « kernel » à la zone mémoire du mode utilisateur. Dans les microprocesseurs modernes, on protège le mode « kernel » au niveau matériel par un bit inviolable. Grâce à cette protection, les modes « kernel » et « utilisateur » peuvent alors coexister sans risque.

Là aussi, l'anticipation des instructions est la source du problème : il suffit d'envoyer au microprocesseur des instructions normalement réservées au mode kernel. Comme l'instruction est anticipée, elle pourrait très bien être exécutée avant celle qui lui donne le droit d'accéder au kernel. Le microprocesseur ne se pose pas de questions car si ce n'est pas la bonne instruction (il n'avait pas le droit d'accéder au kernel), il effacera de toute façon tout de ce qu'il vient de faire « illégalement ». Erreur : il reste aussi des traces matérielles exploitables.

Il y a des remèdes contre Meltdown :  mettre fin à la coexistence des modes kernel et utilisateur, imposer une stricte séparation entre les zones mémoire utilisateur et « kernel » qu'on distribue aléatoirement dans toute la mémoire du PC. Ainsi, les modes « kernel » et utilisateur  s'ignorent à nouveau mais au prix de performances dégradées. Les clouds sont les plus impactés : la mémoire kernel y est partagée entre plusieurs utilisateurs et a donc les secrets de tous. Or, les chercheurs ont été capables de faire une copie de la mémoire « kernel » sans y être autorisés. Voilà qui explique la panique chez Amazon et Microsoft.

Meltdown et Spectre : un très mauvais signal pour l'IoT

Alors, scandale technologique ? Non, hypocrisie : il y a vingt ans, quand ces optimisations matérielles ont été mises au point, on ne pouvait pas encore tout savoir de leur impact sur la sécurité. Mais, depuis, ceux qui l'ont appréhendée prêchent dans le désert chez les fabricants.

Il s'agit d'un bug matériel : les spécialistes de sécurité software ont le beau rôle en expliquant qu'ils ont toujours pris pour acquis que, au niveau matériel, tout était isolé et sécurisé. Ce n'est pas leur faute, disent-ils.

Ce faisant, ils nient les attaques corrélées matérielles et logicielles, dont la combinaison peut mettre à plat deux couches parfaitement sécurisées... en isolation. Enfin, on sait depuis longtemps que l'optimisation des performances des microprocesseurs a un impact sur la configuration matérielle. Or, les algorithmes de cryptographie ne sont pas considérés comme sûrs, si, au niveau du microprocesseur, des configurations matérielles sont modifiées, comme le font Meltdown et Spectre.

Il faut plutôt craindre la boîte de Pandore : il y aura d'autre déconvenues dès lors qu'on sait qu'au niveau microprocesseur se passent des choses que les programmes au-dessus considéraient comme impossibles. C'est très mauvais pour l'IoT (l'Internet des objets) qui reposera amplement sur ces couches matérielles.

___

POUR ALLER PLUS LOIN :

• Meltdown, par Moritz Lipp et al. : https://meltdownattack.com/meltdown.pdf
• Spectre Attacks: Exploiting Speculative Execution, par Paul Kocher et al. :
  https://spectreattack.com/spectre.pdf