LVI : une faille de plus chez Intel, mais elle ne devrait pas vous gêner

Si jamais Meltdown et Spectre ne vous faisaient pas assez peur, voici qu’une nouvelle faille se dessine à l’horizon : Load Value Injection, ou LVI pour les intimes. Répertoriée comme CVE-2020-0551, Intel la juge « medium » du fait d’un accès de données en lecture seulement et indique qu’il est fortement improbable qu’une exploitation ait eu lieu. Néanmoins, puisque l’attaque ne laisse aucune trace, difficile d’en être certain !

Qu’on donne un cookie à cette équipe !

Pour plonger dans le technique, LVI se décompose en quatre phases. Dans un premier temps, l’attaquant doit remplir un buffer interne (par exemple le Store Buffer ou le cache L1). Immédiatement ensuite, le programme attaqué doit effectuer un chargement utilisant le buffer incriminé. Dans le cas ou une page fault — une faute bénigne sur nos processeurs signifiant que l’endroit demandé n’est pas encore connu de l’unité de gestion de la mémoire (MMU) — ou en cas d’action spécifiques du microcode, le CPU peut utiliser la (mauvaise) donnée présente dans le buffer. Selon les instructions suivantes, la donnée peut être utilisée directement ou encodée, puis nettoyée puisque son chargement s’est révélé être une spéculation invalide. Néanmoins, le procédé a laissé des traces dans les canaux auxiliaires habituels... et donc retrouvables dans un dernier temps.

L'explication, avec une animation incompréhensible et bien trop rapide !

Du coup, il devient possible d’extraire les données non plus des instructions LOAD seules, mais également de toutes les autres instructions utilisant de manière implicite des valeurs présentes en mémoire, par exemple... RET, l’instruction de terminaison d’une fonction ! Néanmoins, il faut une connaissance extrême du programme cible et soit un microcode corrompu, sous un kernel véreux pour réussir à obtenir un résultat exploitable : autant dire que Mme Michu n’est pas à risque. C’est moins le cas des applications utilisant SGX, les extensions d’Intel permettant justement d’exécuter du code lorsque l’environnement tout entier n’est pas digne de confiance (OS et hyperviseur compris). Dans ce cas, il faut exécuter une barrière mémoire pour vider les buffers incriminés après chaque instruction susceptible de fuiter des données, ce qui est, vous l’imaginez, très coûteux.

Du fait du degré extrême d’accès nécessaire sur la machine infectée, il est effectivement difficile de penser à un scénario crédible d’exploitation de la vulnérabilité. Néanmoins, un correctif a été rendu disponible par Intel, qui se situe au niveau du compilateur, nécessitant donc de repasser son programme par cette moulinette pour être protégé. De plus, ce correctif est extrêmement lourd, puisqu’il agit au niveau de chaque appel de fonction, chargement mémoire et branchement indirect... des instructions très courantes dans les programmes x86. Phoronix a testé l’impact de ces rustines, et la sentence est dure : lorsque toutes les protections sont activées, les performances chutent d’un facteur 4 en moyenne (géométrique). Fort heureusement pour Intel, Ice Lake est indemne du massacre du fait d’une communication avec les chercheurs en amont de la diffusion publique... reste à attendre la déclinaison pour PC du bureau et serveurs !