plus69free - Fotolia

Bug Intel : des mécanismes de protection de la mémoire vive hautement vulnérables

Les systèmes de protection censée empêcher l’exécution de code arbitraire avec un haut niveau de privilèges sur les systèmes Intel et ARM 64 bits présentent de graves vulnérabilités. Des correctifs arrivent. Les systèmes AMD seraient épargnés.

C’est en 2016 qu’une équipe de cinq chercheurs de l’université technique de Graz, en Autriche, a levé le lièvre : les mécanismes de protection censés empêcher le détournement d’un système en forçant l’exécution de code avec les privilèges du noyau du système d’exploitation ne sont pas inviolables, au moins sur les systèmes 64 bits Intel x86 et ARMv8-A.

Emmenés par Daniel Gruss, les chercheurs ont présenté leurs travaux à l’automne 2016, à Vienne. L’occasion pour eux de dévoiler « une nouvelle classe d’attaques génériques exploitant des faiblesses majeures » dans les mécanismes d’anticipation de ces processeurs : « cela permet à des attaquants [placés dans le mode utilisateur, et donc sans privilège élevé] d’obtenir des informations d’adressage et donc de compromettre tout le système » en contournant les mécanismes de protection comme la prévention d’exécution en mode superviseur (SMEP), la prévention d’accès au mode superviseur (SMAP) et la randomisation de l’allocation de la mémoire vive (ASLR), tant en mode utilisateur qu’en mode noyau – le fameux ring-0 où tous les pouvoirs sont accessibles.

A l’occasion de cette première présentation, les chercheurs – connus pour d’autres travaux sur les vulnérabilités liées au matériel, comme Rowhammer et celles de l’enclave SGX des processeurs Intel Skylake – ont fait la démonstration de leur approche sur des machines virtuelles Amazon EC2 ou encore des systèmes Windows 10 et Linux. Interrogé par e-mail, Daniel Gruss explique que ses équipes ne se sont pas arrêtées à cela : « nous avons implémenté l’idée et l’avons évaluée dans un second papier, début 2017, avant de publier le correctif Kaiser en mai 2017 ».

C’est en effet au tout début du mois mai dernier que Daniel Gruss publie sur la liste de diffusion LKML un message au sujet de Kaiser. Celui-ci attire notamment l’attention de Jann Horn, de l’équipe du Projet Zéro de Google, ainsi que de Thomas Garnier, ingénieur sécurité chez Google, et de Mark Rutland, d’ARM. Intel n’a pas manqué non plus de s’y intéresser. Comme le souligne Daniel Gruss, le fondeur a contacté son équipe « avec une version lourdement retravaillée du correctif Kaiser au mois d’octobre, annonçant qu’il serait publié sur LKML ». Ce que Dave Hansen fit effectivement le 31 octobre dernier. De son côté, Will Deacon, d’ARM, en a publié un mi-novembre.

Depuis, le correctif a changé de nom, pour KPTI, ou Kernel Page-Table Isolation. Son principe consiste à présenter à chaque processus du mode utilisateur une copie fantôme de la table de pages du noyau : ce n’est que lors de l’entrée dans le noyau que la copy complète de la table est accessible. Mais cela implique d’intercepter tous les appels système, exceptions et interruptions conduisant au mode noyau. Ce qui ne va pas sans affecter les performances.

La dernière release candidate du noyau Linux 4.15, la rc6, embarque les correctifs nécessaires pour x86. Microsoft et Apple vont également devoir produire des correctifs, et ils ne sont pas les seuls. Sur Twitter, David Gruss souligne que « Kaiser est probablement le changement de conception de système d’exploitation le plus fondamental depuis des années ». Et de faire état d’une ironie : ses équipes ont essayé de présenter la vulnérabilité et son correctif lors de la dernière édition américaine de la conférence Black Hat, mais leur proposition a été rejetée. 

Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)

Close