Comme vous le savez, le code exécuté dans l'enclave est sérieusement limité dans sa fonctionnalité. Il ne peut pas faire d'appels système. Il ne peut pas effectuer d'opérations d'E / S. Il ne connaît pas l'adresse de base du segment de code hôte. Il ne peut pas jmp et appeler le code hôte. Il n'a aucune idée de la structure de l'espace d'adressage qui guide l'application hôte (par exemple, quelles pages sont promues ou quel type de données sont placées sur ces pages). Il ne peut pas demander au système d'exploitation d'ajouter un morceau de mémoire à l'application hôte (par exemple, via / proc / pid / maps). Des tentatives naïves de lire une zone de mémoire arbitraire aveugle de l'application hôte - sans parler des tentatives d'écriture - tôt ou tard (plutôt la première) conduiront à l'achèvement forcé du programme enclave. Cela se produit chaque fois que la zone d'espace d'adressage virtuel demandée par l'enclave est inaccessible à l'application hôte.
Avec des réalités aussi dures, l'auteur du virus pourra-t-il utiliser les enclaves SGX pour réaliser ses objectifs malveillants?
- Hack pour sonder les adresses pour la possibilité de les lire
- Hack pour sonder des adresses pour l'écriture
- Hack pour rediriger le flux de contrôle
- De quoi donner au méchant les trois hacks listés ci-dessus
- Comment le méchant utilise ces hacks pour créer ranzomvari
Sur la base de tout ce qui précède, il est généralement admis que l'enclave est uniquement capable de servir l'application hôte et que l'enclave ne peut pas prendre sa propre initiative, y compris malveillante. Cela signifie que les enclaves ne représentent pas une valeur pratique pour les auteurs de virus. Cette hypothèse hâtive est l'une des raisons pour lesquelles la protection SGX est asymétrique: le code de l'application hôte ne peut pas accéder à la mémoire de l'enclave, tandis que le code de l'enclave peut lire et écrire sur n'importe quelle adresse mémoire de l'application hôte.
Par conséquent, si le code d'enclave malveillant réussit à effectuer des appels système arbitraires au nom de l'application hôte, à exécuter du code arbitraire en son nom, à analyser la mémoire de l'application hôte et à trouver les chaînes ROP appropriées pour les abus, il pourra prendre le contrôle complet de application hôte en mode furtif. Il peut non seulement voler et crypter les fichiers utilisateur, mais également agir au nom de l'utilisateur. Par exemple, envoyez des e-mails de phishing en son nom ou menez des attaques DoS. Dans le même temps, vous n'avez même pas peur des mécanismes de protection les plus modernes, tels que les canaris de pile et la désinfection des adresses.
Nous allons montrer quelques hacks à travers lesquels les méchants surmontent les limitations ci-dessus, en essayant de profiter des avantages de SGX à leurs fins malveillantes: en effectuant des attaques ROP. Soit pour exécuter du code arbitraire déguisé en un processus de sciage de l'hôte (similaire au processus d'évidage, qui est souvent utilisé par les logiciels malveillants), soit pour masquer un logiciel malveillant déjà préparé (pour sauver son logiciel malveillant de la persécution par les antivirus et autres mécanismes de protection).
Hack pour sonder des adresses pour la possibilité de les lire
Étant donné que l'enclave ne sait pas quelles plages de l'espace d'adressage virtuel sont disponibles pour l'application hôte, et parce que lorsque vous essayez de lire une adresse inaccessible, l'enclave est fermée de force, le méchant est confronté à la tâche de trouver un moyen de numériser l'espace d'adressage à sécurité intégrée. Trouvez un moyen de mapper les adresses virtuelles disponibles. Le méchant résout ce problème en faisant un mauvais usage de la technologie TSX d'Intel. Il utilise l'un des effets secondaires de TSX: si la fonction d'accès à la mémoire est placée dans une transaction TSX, les exceptions résultant de l'accès à des adresses invalides sont supprimées par TSX avant d'atteindre le système d'exploitation. Lorsque vous essayez d'accéder à une adresse mémoire non valide, seule la transaction en cours est interrompue, et non l'ensemble du programme enclave. T.O. La TSX permet à l'enclave d'accéder en toute sécurité à toute adresse depuis la transaction - sans risque d'effondrement.
Si l' adresse spécifiée est disponible pour l' application hôte, la transaction TSX réussit le plus souvent. Dans de rares cas, il peut échouer en raison d'influences externes, telles que des interruptions (par exemple, des interruptions du planificateur), une éviction du cache ou des modifications simultanées des cellules de mémoire par plusieurs processus. Dans ces rares cas, TSX renvoie un code d'erreur indiquant que la panne s'est produite est temporaire. Dans ces cas, il vous suffit de redémarrer la transaction.
Si l' adresse spécifiée n'est pas disponible pour l' application hôte, TSX supprime l'exception (le système d'exploitation n'est pas notifié) et annule la transaction. Un code d'erreur est renvoyé au code d'enclave afin qu'il puisse répondre au fait que la transaction a été annulée. Ces codes d'erreur indiquent que l'adresse en question n'est pas disponible pour l'application hôte.
Une telle manipulation de TSX de l'intérieur de l'enclave a une fonctionnalité intéressante pour le méchant: puisqu'au moment de l'exécution du code de l'enclave, la plupart des compteurs de performances matérielles ne sont pas mis à jour, il est impossible de suivre les transactions TSX effectuées à l'intérieur de l'enclave en les utilisant. Ainsi, les fraudes malveillantes avec TSX'om restent totalement invisibles pour le système d'exploitation.
De plus, étant donné que le piratage décrit ci-dessus ne repose sur aucun appel système, il ne peut pas être détecté ou empêché en bloquant simplement les appels système; ce qui donne généralement un résultat positif dans la lutte contre la «chasse aux œufs».
Le méchant utilise le hack décrit ci-dessus pour rechercher des gadgets dans le code de l'application hôte adaptés à la formation d'une chaîne ROP. Cependant, il n'a pas besoin de sonder chaque adresse. Il suffit de sonder une adresse de chaque page de l'espace d'adressage virtuel. L'analyse des 16 gigaoctets de mémoire prend environ 45 minutes (sur Intel i7-6700K). En conséquence, le méchant obtient une liste de pages exécutables qui conviennent à la construction d'une chaîne ROP.
Hack pour sonder des adresses pour l'écriture
Pour implémenter une version enclave d'une attaque ROP, le méchant doit pouvoir rechercher des parties inutilisables inscriptibles de la mémoire de l'application hôte. Le méchant utilise ces sections de mémoire pour injecter un faux cadre de pile et pour injecter une charge utile (shellcode). En fin de compte, une enclave malveillante n'est pas en mesure d'exiger que l'application hôte lui alloue de la mémoire, mais à la place, elle peut utiliser à d'autres fins la mémoire allouée par l'application hôte. À moins, bien sûr, qu'il parvienne à trouver de tels sites sans effondrer l'enclave.
Le méchant effectue cette recherche en exploitant un autre effet secondaire du TSX. Tout d'abord, il, comme dans le cas précédent, sonde l'adresse pour son existence, puis vérifie si la page correspondant à cette adresse est accessible en écriture. Pour ce faire, le méchant utilise le hack suivant: place la fonction d'écriture dans la transaction TSX, et après qu'elle soit terminée, mais même avant qu'elle ne soit terminée, elle rompt de force la transaction (abandon explicite).
En regardant le code retour d'une transaction TSX, le méchant se rend compte s'il est accessible en écriture. S'il s'agit d'un «avortement explicite», le méchant se rend compte que l'enregistrement serait réussi s'il le terminait. Si la page est en lecture seule, la transaction échoue avec une erreur autre que «abandon explicite».
Une telle manipulation de TSX a une autre caractéristique qui est agréable pour le méchant (en plus de l'impossibilité de suivre les compteurs de performances matérielles): puisque toutes les commandes d'écriture dans la mémoire ne sont enregistrées que si la transaction a réussi, forcer la transaction à se terminer garantit que la cellule de mémoire sondée reste inchangée.
Contrôlez le hack de redirection de flux
Lors de l'exécution d'une attaque ROP à partir d'une enclave - contrairement aux attaques ROP traditionnelles - le méchant peut prendre le contrôle du registre RIP sans exploiter aucun bogue dans le programme attaqué (débordement de tampon ou quelque chose comme ça). Le méchant peut directement écraser la valeur du registre RIP stocké sur la pile. Il peut notamment remplacer la valeur de ce registre par sa chaîne ROP.
Cependant, si la chaîne ROP est longue, la réécriture d'une grande partie de la pile d'application hôte peut entraîner une corruption des données et un comportement inattendu du programme. Un méchant qui cherche à mener son attaque furtivement, cet état de fait ne convient pas. Par conséquent, il crée un faux cadre de pile temporaire pour lui-même et y stocke sa chaîne ROP. Un faux cadre de pile est placé dans un endroit arbitraire de la mémoire qui est accessible en écriture, de sorte que la vraie pile reste intacte.
De quoi donner au méchant les trois hacks listés ci-dessus
(1) Tout d'abord, une enclave malveillante, via un hack pour sonder les adresses pour la possibilité de les lire , recherche dans l'application hôte des gadgets ROP qui peuvent être utilisés abusivement.
(2) Ensuite, en utilisant un hack pour sonder les adresses pour l'écriture , l'enclave malveillante identifie dans les zones de mémoire de l'application hôte appropriées pour injecter la charge utile.
(3) Ensuite, l'enclave crée une chaîne ROP à partir des gadgets trouvés à l'étape (1) et injecte cette chaîne dans la pile d'application hôte.
(4) Enfin, lorsque l'application hôte rencontre la chaîne ROP créée à l'étape précédente, la charge utile malveillante commence à s'exécuter, avec les privilèges de l'application hôte et la possibilité de faire des appels système.
Comment le méchant utilise ces hacks pour créer Ranzomvari
Une fois que l'application hôte a transféré le contrôle à l'enclave via l'un des ECALL (sans soupçonner que cette enclave est malveillante), l'enclave malveillante recherche de l'espace libre dans la mémoire de l'application hôte pour l'injection de code (pour ces endroits, elle prend ces séquences de cellules qui rempli de zéros). Ensuite, en utilisant un hack pour sonder les adresses pour la lisibilité , l'enclave recherche les pages exécutables dans l'application hôte et génère une chaîne ROP qui crée un nouveau fichier appelé «RANSOM» dans le répertoire courant (dans une attaque réelle, l'enclave crypte les fichiers utilisateur existants) et affiche un message de demande de rançon. Dans le même temps, l'application hôte estime naïvement que l'enclave additionne simplement deux nombres. À quoi cela ressemble-t-il dans le code?
Pour faciliter la perception, nous introduisons quelques mnémoniques à travers définit:
Nous conservons les valeurs initiales des registres RSP et RBP afin de restaurer le fonctionnement normal de l'application hôte après avoir effectué la charge utile:
Nous recherchons un cadre de pile approprié (voir le code dans la section «hack pour rediriger le flux de contrôle»).
Trouvez les gadgets ROP appropriés:
Trouvez un endroit pour injecter la charge utile:
Construire une chaîne ROP:
C'est ainsi que la technologie SGX d'Intel, conçue pour résister aux programmes malveillants, est exploitée par les méchants pour atteindre des objectifs opposés.