Exécution en mode protégé SMM par empoisonnement du cache mémoire sur une plateforme matérielle Intel

Par Xavier Poli, secuobs.com
Le 20/03/2009

---

Résumé : Une nouvelle attaque vient d'être publiée par Invisible Things afin de permettre à un attaquant d'abuser du mode protégé SMM par empoisonnement de la mémoire cache des processeurs Intel et d'exécuter du code arbitraire avec les privilèges les plus hauts. - Lire l'article



Comme ils l'avaient annoncé ( lien ), les chercheurs d'Invisible Things ( lien ), Rafal Wojtczuk et Joanna Rutkowska ( BluePill, lien ) viennent de publier un papier ( Attacking SMM Memory via Intel® CPU Cache Poisoning - lien ) présentant une nouvelle attaque à destination du mode protégé SMM ( System Management Mode - lien & lien ) dont l'insécurité avait déjà été abordée, entre autres, par Loïc Duflot ( lien ) pour les systèmes OpenBSD ( lien ).

Concrètement, le code SMM chargé par le BIOS réside dans une partie protégée de la mémoire appelée la SMRAM ( System Management Random Access Memory - lien ), le contrôleur en charge de la mémoire ( Chipset - lien ) inclut lui des blocages spécifiques pour limiter au seul BIOS l'accès à la SMRAM. Ainsi, même les hyperviseurs ( lien ) ou les noyaux des systèmes d'exploitation ne peuvent y avoir accès.

Une nouvelle faille a néanmoins été identifiée, elle permet un accès non autorisé en écriture à la SMRAM et l'exécution de code avec des privilèges SMM en contournant l'ensemble des protections du système. La SMRAM sert à stocker des registres système ( voir la thèse de Loïc Duflot - lien ) lors d'un événement SMI ( System Management Interrupts - lien ) comme la mise en veille, elle sert alors à restaurer les statuts processeur, périphériques et programmes lors de la réactivation du système( RSM - lien ).

Cette attaque repose sur l'empoisonnement du cache mémoire au sein des cartes mère DQ35 ( lien ) équipées de processeurs Intel x86 ( lien ). Elle autorise une élévation de privilèges du mode noyau ( Ring 0 - lien ) vers SMM, en offrant à l'attaquant les privilèges les plus élevés de ces architectures. SMM est considéré comme de niveau Ring -2, il autorise l'exécution de code avec plus de privilèges que les hyperviseurs matériel ( type 1 - lien ) ne le permettent via la technologie de virtualisation Intel VT ( lien ) en Ring -1.

Invisible Things avait déjà identifié par le passé ( lien ) une faille affectant les micro-logiciels ( Firmware - lien ) de type BIOS ( lien ) pour les plateformes Intel. Ils exploitaient alors le remappage ( lien ) de la mémoire pour accéder à la SMRAM. En février 2009, une défaillance des protections SMRAM était également exploitée par eux pour contourner ( voir notre article – lien ) Intel Trusted Execution Technology ( lien ) et exécuter du code avec les privilèges SMM. L'Intel DQ35 supportant Intel vPro ( lien ) était déjà concernée.

Par ailleurs, Intel avait déjà été prévenu en octobre 2008 par Loïc Duflot de problèmes similaires d'empoisonnement du cache pour abuser des privilèges SMM, un accord ayant été trouvé afin que la divulgation des détails de chacun soit réalisée à la date de la présentation de Loic Duflot à CanSecWest ( lien ). Un problème du même ordre avait de plus été reporté par des employés d'Intel il y a quelques années déjà, sans pour autant que cela n'ait été pris en compte depuis alors que ces informations sont disponibles publiquement ( lien ).

Avant d'effectuer l'empoisonnement du cache et d'obtenir l'accès au couple SMRAM/SMM, il est nécessaire que l'attaquant ait accès aux registres système MSR ( Model Specific Register - lien ) pour modifier les registres de plage mémoire ( MTRR - lien ). Cette opération visant à marquer le segment de la SMRAM comme « Write-back cacheable » ( lien ) pour accéder par la suite en écriture aux adresses physiques relatives à la SMRAM.

Les systèmes GNU/Linux autorisent nativement ( /proc/mtrr - lien ) la manipulation des registres MTRR depuis le mode utilisateur (Ring 3). Pour les systèmes Microsoft Windows, l'attaquant doit modifier le mappage MTRR via les instructions WRMSR ( lien ). Une fois « WB cacheable » spécifié pour le segment SMRAM dans la table relative ( TSEG - lien ), l'attaquant doit écraser le point d'entrée du sous-programme SMI ( Handler/Callback - lien ) en plaçant un pointeur ( ptr - lien ) vers son code malicieux, une adresse virtuelle mappée vers une adresse physique de TSEG par exemple.

Une interruption SMI est ensuite déclenchée par l'attaquant afin de forcer le mode SMM et le passage en SMRAM, le flux d'exécution processeur est redirigé vers le sous-programme SMI et les instructions malicieuses placées précédemment. Dans ce contexte, le processeur privilégie bien les accès aux instructions placées malicieusement en cache au détriment des instructions SMM légitimes contenues initialement dans la DRAM ( lien ). Le code malicieux est ici exécutée en tant que sous-programme SMI avec des privilèges SMM.

La preuve de concept mise à disposition ( PoC o68-2.tgz - lien ) par Invisible Things contient des adresses constantes qui sont codées en dur, il est donc nécessaire pour l'attaquant d'ajuster préalablement ces adresses lors de l'utilisation d'une plateforme matérielle autre qu'une carte mère Intel DQ35, ou lorsque celle-ci présente une quantité de mémoire RAM différente de deux gigaoctets.

Le code actuel de cette preuve de concept utilise de plus un module (phys.c) noyau dédié qui facilite l'allocation du tampon du Shellcode ( voir notre dossier - lien et le calcul de son adresse physique. Le Shellcode inclus (mtrr.c) par défaut n'effectue cependant aucune opération malveillante, il incrémente juste un compteur via un pseudo fichier /proc/mymem en s'assurant que le code SMM original soit bien exécuté ensuite.

L'attaquant peut également effectuer une attaque en lecture pour s'assurer préalablement de la fiabilité de son code d'exploitation qui nécessite l'obtention des déplacements mémoire ( Offsets - lien ) spécifiques au Firmware, notamment entre SMM et le sous-programme SMI. La lecture, réalisée depuis le sous-programme SMI exécuté, doit être effectuée de préférence via une instruction non évasive ( MOVNTI - lien ) afin de ne pas polluer les données du cache.

L'ensemble de ces avancées laisse le champ libre à la recherche sur les Rootkits SMM ( Sherri Sparks et Shawn - lien ) et plus globalement à la compromission des hyperviseurs. L'exploitation étant réalisable directement depuis les systèmes d'exploitation qui permettent les opérations d'entrées/sorties et la manipulation de registres MTRR depuis le mode utilisateur (Ring 3), les élévations de privilèges de Ring3 vers Ring0 sont également envisageables afin de contourner les protections noyau en place.

Source : The Invisible Things Lab's blog ( lien )