Et zou, un canal auxiliaire découvert sur les processeurs modernes : de nouvelles failles en vue ?

Au centre des failles de la série Meltdown et Spectre se trouve la notion de canal auxiliaire : la possibilité pour deux processus de communiquer sans contrôle de l’OS. Le plus souvent, il s’agit de mémoires tampons, typiquement le cache dans le cas des premières vulnérabilités, dont la mesure du temps d’accès permet de remonter à la présence ou non d’une adresse dans ledit cache. Cependant, d’autres canaux existent, comme cette pseudo-faille sur le M1 de chez Apple ; et c’est à peu près un bis repetita dans notre papier du jour.

Découverte en partie par des chercheurs de l’Université de Rennes dans le cadre du projet MIAOUS — oui, on a beaucoup d’humour dans la recherche académique — associés à l’Université de Ben-Gurion (Israël), le concept consiste ici non pas à laisser des traces dans une mémoire, mais en occupant les unités de calcul du CPU : les fameux ports d’exécution. Testés sur un i5-8365U, le bousin a pu transmettre des informations à la vitesse démentielle de 200 bits/s, ce qui représente toutefois un facteur 10 par rapport aux autres canaux possibles non-patchés à ce jour.

Dans les détails, le concept n’est pas si complexe : puisque le processeur, en interne, est composé d’unités spécialisées, tournant en parallèle afin d’exécuter simultanément plusieurs instructions assembleur (il est alors question d’ILP : Instruction-Level Parallelism), il « suffit » alors pour un processus attaquant de surcharger individuellement chacun des ports pour obtenir notre joli canal auxiliaire. En effet, le temps d’exécution des instructions floodant les ports peut être mesuré : dans le cas où le temps pris est plus élevé qu’attendu, c’est que le thread attaqué a exécuté quelque chose sur cette unité de calcul. Pour cela, par contre, il faut que l’attaquant se situe sur l’autre cœur logique d’un CPU hyperthreadé : pas si facile ! Techniquement, le tout est réalisé en WebAssembly, un format de binaire utilisé sur le web et exécuté dans une sandbox par les navigateurs.

Bien que la vulnérabilité ne soit qu’un canal auxiliaire de communication (bien qu’important, le profil des calculs effectués ne permet pas directement de remonter aux données sources, sauf cas extrêmes), la chose est toutefois fortement inquiétante puisqu’exploitable directement depuis un navigateur web, y compris à travers les barrières de protection des VM. Cependant, il faut que les deux processus communiquant ainsi s’exécutent sur le même cœur physique via l’HyperThreading : un correctif simple est ainsi de le désactiver, quitte à perdre de la performance. Si jamais vous souhaitez exécuter le bousin, le code nécessaire est en libre accès juste ici, sur GitHub. Avis aux experts en la matière ?