CrossTalk, ou la faille qui vient, une nouvelle fois, casser les barrières de protection de Meltdown et Spectre

Après Meltdown et Spectre, Intel s’était déjà trouvé bien embêté, à devoir balayer les pots cassés provenant de failles de sécurité issues d’implémentation d’heuristiques s’avérant finalement trop peu respectueuses des niveaux de restriction des données utilisées. Cependant, telle une boîte de Pandore — n’oubliez par le « o »... —, les vulnérabilités n’ont, par la suite, pas cessé d’être découvertes : L1TF/Foreshadow, Zombieload, TAA, Cacheout,...

Nous pouvons désormais rajouter une petite dernière à cette longue liste : CrossTalk, qui répond également au nom de CVE-2020-0543 dans le désormais célèbre index des vulnérabilité, et Special Register Buffer Data Sampling chez les bleus. Dans les grandes lignes, rien de nouveau : l’attaquant accède à un staging buffer partagé au moyen d’instructions en apparence anodines — CPUID, qui ne permettent que de renvoyer des informations sur le processeur comme son nom, son fabricant ou la taille de ses caches — et profile le comportement de la machine au moyen de compteur hardware pour récupérer les données au moyen d’une méthode spéculative nommée RIDL, déjà connue des chercheurs en sécurité.

Si seulement il n’y avait que ces deux-là...

Une grande nouveauté réside dans la localisation de ce staging buffer : non documenté (bien sûr...), le bousin est en fait partagé entre cœurs d’un même CPU, et contient entre autres le résultat des derniers nombres aléatoires générés, la clef de voute de la sécurité informatique moderne. Comprenez ainsi que désactiver l’HyperThreading ne servira absolument à rien pour pallier cette vulnérabilité. Et, évidemment, les données exécutées dans une enclave SGX accèdent également à ce même buffer, réduisant à néant les efforts de ces extensions pour garantir la confidentialité des calculs sur les machines compromises... Néanmoins, ce staging buffer n'est pas directement accessible : il faut passer par un second buffer interne, le Line File Buffer, qui est, lui, vulnérable à la faille RIDL (via un Flush+Reload).

Pour les CPU touchés, comptez tout le monde sur socket 1151 depuis Broadwell a minima... mais, étrangement, Cascade Lake ne serait pas concerné, probablement du fait de l’architecture en mesh devant modifier l’organisation microarchitecturale des composants partagés entre cœurs. Ainsi, il est probable que les CPU à base de Scalable Platform ne soient pas impactés, ce qui inclut ainsi les modèles HEDT depuis Skylake-X (mais pas Kaby Lake-X, bonjour le casse-tête !).

Au niveau des correctifs, un microcode est en déploiement (disponible depuis le 9 juin), et a pour effet de considérablement ralentir les applications reposant sur des générations aléatoires de bits — au hasard, la génération de clef RSA — des benchmarks préliminaires effectués sous Linux montrant des pertes catastrophiques : près de 97 % de réduction des débits sur l’instruction RDRAND ; sachant que RDSEED et EGETKEY sont également concernés (les autres instructions étant par contre pas impactées). Heureusement que la Scalable Platform n’est pas impactée ! Notez enfin que les appels à ces instructions depuis des cœurs différents seront désormais cloisonnés, ce qui se traduit par des ralentissements plus prononcés encore sur les programmes multicœurs. Aïe aïe aïe, vivement un fix hardware ! (Source : VUSec via Phoronix)