Attaque sur Intel SGX permettant d'extraire des données confidentielles ou d'exécuter du code dans l'enclave

Des chercheurs de l'Université scientifique et technologique de défense de l'Armée populaire de libération de la Chine, de l'Université nationale de Singapour et de l'École polytechnique fédérale de Zurich ont développé une nouvelle méthode d'attaque sur les enclaves isolées Intel SGX (Software Guard eXtensions). Cette attaque, nommée SmashEx, est causée par des problèmes de réentrance lors du traitement des exceptions dans les composants runtime d'Intel SGX. La méthode d'attaque proposée permet, en ayant le contrôle du système d'exploitation, de déterminer les données confidentielles stockées dans l'enclave ou d'organiser la copie de son propre code dans la mémoire de l'enclave et son exécution.

Des prototypes d'exploits ont été préparés pour les enclaves avec runtime basé sur Intel SGX SDK (CVE-2021-0186) et Microsoft Open Enclave (CVE-2021-33767). Dans le premier cas, la possibilité d'extraction de la clé RSA utilisée sur le serveur web pour HTTPS a été démontrée, tandis que dans le second cas, il a été possible de déterminer le contenu obtenu via l'outil cURL exécuté à l'intérieur de l'enclave. La vulnérabilité a déjà été corrigée par un correctif dans les versions Intel SGX SDK 2.13 et Open Enclave 0.17.1. En plus des paquets Intel SGX SDK et Microsoft Open Enclave, la vulnérabilité se manifeste également dans les SDK de Google Asylo, EdgelessRT, Apache Teaclave, Rust SGX SDK, SGX-LKL, CoSMIX et Veracruz.

Rappelons que la technologie SGX (Software Guard Extensions) est apparue dans les processeurs Intel Core de sixième génération (Skylake) et propose une série d'instructions permettant de définir des zones de mémoire sécurisées — enclaves — pour les applications de niveau utilisateur, dont le contenu ne peut pas être lu ou modifié même par le noyau et le code s'exécutant en modes ring0, SMM et VMM. Il n'est pas possible de transmettre le contrôle au code dans l'enclave par des fonctions de transition traditionnelles et des manipulations avec les registres et la pile — la transmission du contrôle à l'enclave utilise de nouvelles instructions spécifiquement créées, EENTER, EEXIT et ERESUME, qui effectuent une vérification des autorisations. Le code placé dans l'enclave peut utiliser des méthodes d'appel classiques pour accéder aux fonctions à l'intérieur de l'enclave ainsi qu'une instruction spéciale pour appeler des fonctions externes. Pour protéger contre les attaques matérielles, telles que le branchement au module DRAM, un chiffrement de la mémoire de l'enclave est appliqué.

Le problème réside dans le fait que la technologie SGX permet au système d'exploitation d'interrompre l'exécution de l'enclave en générant une exception matérielle, et que l'enclave ne met pas correctement en œuvre les primitives pour le traitement atomique de telles exceptions. Contrairement au kernel du système d'exploitation et aux applications ordinaires, le code à l'intérieur des enclaves n'a pas accès aux primitives pour organiser des actions atomiques pendant le traitement des exceptions asynchrones. Sans ces primitives atomiques, l'enclave peut être interrompue à tout moment et renvoyée à l'exécution, même lorsque des sections critiques sont en cours d'exécution et qu'elle se trouve dans un état non sécurisé (par exemple, lorsque les registres du CPU ne sont pas sauvegardés/restaurés).

Pour un fonctionnement normal, la technologie SGX permet d'interrompre l'exécution de l'enclave par des exceptions matérielles configurables. Cette caractéristique permet aux environnements d'exécution des enclaves de traiter les exceptions intra-enclave ou les signaux, mais cela peut également provoquer des erreurs de réentrance. L'attaque SmashEx repose sur l'exploitation des lacunes dans le SDK qui ne gèrent pas correctement la situation d'appel répété du gestionnaire d'exception. Il est important de noter que, pour exploiter cette vulnérabilité, l'attaquant doit avoir la capacité d'interrompre l'exécution de l'enclave, c'est-à-dire qu'il doit contrôler l'environnement système.

Après la génération d'une exception, l'attaquant obtient une petite fenêtre de temps pendant laquelle il peut intercepter le flux d'exécution en manipulant les paramètres d'entrée. En particulier, s'il a accès au système (environnement à l'extérieur de l'enclave), il peut créer une nouvelle exception immédiatement après l'exécution de l'instruction d'entrée dans l'enclave (EENTER), ce qui entraînera le retour du contrôle au système à un stade où la configuration de la pile pour l'enclave n'est pas encore terminée, état dans lequel est également sauvegardé le statut des registres CPU.

Le système peut ensuite rendre le contrôle au sein de l'enclave, mais comme la pile de l'enclave n'a pas été configurée pendant l'interruption, l'enclave s'exécutera avec la pile qui se trouve dans la mémoire du système, ce qui peut être utilisé pour appliquer des méthodes d'exploitation basées sur la programmation orientée retour (ROP - Return-Oriented Programming). Lors de l'utilisation de la technique ROP, l'attaquant ne tente pas de placer son code en mémoire, mais utilise déjà des morceaux d'instructions machine présents dans les bibliothèques chargées, se terminant par une instruction de retour au contrôle (généralement, ce sont les terminaisons de fonctions de bibliothèque). Le fonctionnement de l'exploitation se résume à construire une chaîne d'appels de blocs similaires (« gadgets ») pour obtenir la fonctionnalité désirée.

Source : opennet.ru