in

Fuzzing d’applications dans la TrustZone Qualcomm – Par Slava Makkaveev

Une étude menée par Slava Makkaveev

La TrustZone est une extension de sécurité intégrée par ARM dans le processeur Corex-A. Cette extension crée un monde sécurisé virtuel et isolé pouvant être utilisé par le système d’exploitation principal pour fournir des fonctions de confidentialité et d’intégrité.

Aujourd’hui, ARM TrustZone fait partie intégrante de tous les appareils mobiles modernes. Comme on le voit sur les téléphones Nexus/Pixel reposant sur Android, les composants TrustZone sont intégrés dans les images Android « bootloader », « radio », « vendor » et « system ».

Voici les implémentations commerciales les plus courantes de l’environnement d’exécution sécurisé (TEE) pour les appareils mobiles reposant sur le contrôle matériel des accès ARM :

  • Environnement d’exécution sécurisé de Qualcomm (QSEE), utilisé sur les appareils Pixel, LG, Xiaomi, Sony, HTC, OnePlus, Samsung et de nombreux autres appareils.
  •  Trustronic Kinibi, utilisé sur les appareils Samsung pour les marchés d’Europe et d’Asie.
  • Le cœur de confiance de HiSilicon, utilisé sur la plupart des appareils Huawei.

Ces implémentations TEE sont des logiciels propriétaires du fabricant du processeur.

Une implémentation TEE comprend le système d’exploitation sécurisé, des pilotes, des bibliothèques du monde Normal et Sécurisé, des applications de confiance et d’autres composants.

Figure 1 : Composants de TrustZone (source : documentation ARM).

Le code TEE est extrêmement sensible aux bugs car il protège la sécurité des données critiques et dispose d’autorisations élevées. Une vulnérabilité dans un composant TEE peut entraîner une fuite de données protégées, le rootage de l’appareil, le déverrouillage du logiciel de démarrage, l’exécution de logiciels malveillants indétectables, etc. Par conséquent, un système d’exploitation du monde Normal limite l’accès aux composants TEE à un ensemble minimal de processus. Le service DRM, le service multimédia et le magasin de clés sont des exemples de composants privilégiés du système d’exploitation. Les chercheurs ne se concentrent pas uniquement sur la TrustZone.

Les cibles courantes des attaques contre le code TEE sont :

  • Les gestionnaires d’appel du superviseur de sécurité (SMC).
  • Les gestionnaires de commande des applications de confiance.

Un gestionnaire SMC est implémenté au sein du système d’exploitation de confiance. Il charge les applications de confiance et redirige les commandes du monde Normal vers une application de confiance. Chaque application de confiance implémente des fonctionnalités sécurisées spécifiques, telle que la reconnaissance d’empreintes digitales ou le déchiffrement de supports. Un fabricant d’appareils peut implémenter sa propre application de confiance pour quelque utilisation que ce soit.

Les études de sécurité sur les implémentations TEE sont extrêmement difficiles à réaliser en raison de la grande quantité de code propriétaire. Cependant, comme nous allons le voir, une application de confiance est une bonne cible pour les études utilisant le fuzzing. Le gestionnaire de commandes d’une application de confiance s’attend à recevoir un blob de données du monde Normal qui sera ensuite analysé et utilisé conformément à l’objectif de l’application et à la commande demandée. Chaque application de confiance peut prendre en charge des centaines de commandes externes.

Examinons de plus près QSEE, qui est l’implémentation TEE la plus répandue sur les appareils mobiles Android, et essayons de développer une plate-forme de fuzzing pour les applications Qualcomm de confiance.

Application de confiance

Une application de confiance (trustlet) Qualcomm est un fichier signé au format ELF. Il s’agit en fait d’un fichier ELF standard étendu par un segment de table de hachage spécial comprenant :

  • Un en-tête de table de hachage.
  • Un hachage SHA-256 de l’en-tête ELF et du bloc de données des en-têtes de programme.
  • Un hachage SHA-256 de tous les segments de programme.
  • Une signature du bloc de hachage et une chaîne de certificats.

 

Figure 2 : Format d’image signée (source : documentation Qualcomm).

Pour ancrer la chaîne de confiance, le système d’exploitation de confiance de Qualcomm (QSEOS, pour simplifier, nous supposerons que le noyau et la partie utilisateur sont identiques) authentifie et vérifie l’intégrité d’un trustlet au moment de son chargement. QSEOS valide le certificat racine du trustlet à l’aide de la valeur de hachage gravée dans l’eFuse préprogrammé. Le dernier certificat de la chaîne est utilisé pour vérifier la signature du bloc de hachage. Si la signature est correcte, QSEOS calcule les hachages SHA-256 de l’en-tête et des segments du trustlet, puis les compare aux valeurs du bloc de hachage attesté.

Pour notre étude, le mécanisme de vérification de ces trustletssignifie deux choses simples :

  • Il est impossible de charger un trustlet corrigé même si nous avons totalement accès à ses fichiers.
  • Il est impossible de charger un trustlet signé par un autre fabricant.

Les applications de confiance Qualcomm, ainsi que d’autres images logicielles Qualcomm, sont divisées en plusieurs fichiers qui sont fusionnés en un seul fichier ELF signé juste avant le chargement. Une application de confiance comprend :

  • Un fichier .mdt (en-tête) contenant l’en-tête ELF, la table d’en-tête du programme et le segment de la table de hachage.
  • Plusieurs fichiers .bXX contenant des segments : un fichier par programme ou segment de table de hachage.

La bibliothèque Android libQSEEComAPI.so est chargée de fusionner les fichiers. Pour constituer manuellement un trustlet, le fichier ELF est suffisant pour concaténer tous ses fichiers .bXX en un seul fichier.

Les trustlets suivants font partie du Nexus 6 :

  • /firmware/image/isdbtmm
  • /firmware/image/playready
  • /firmware/image/prov
  • /firmware/image/sampleapp
  • /firmware/image/securemm
  • /firmware/image/tqs
  • /system/vendor/firmware/keymaster/keymaster
  • /system/vendor/firmware/widevine

Regardons le point d’entrée d’un simple trustlet 32 bits. prov étant le plus petit trustlet de la liste précédente, nous allons donc l’utiliser dans notre exemple.

QSEOS exécute le trustlet prov à partir du premier octet de son segment de code. La fonction start enregistre l’application via l’appel système -0x100. Un pointeur sur la fonction de gestion du trustlet est utilisé comme argument de l’appel système.

Figure 3 : Fonction d’entrée du trustlet prov.

La fonction de gestion est chargée de :

  • L’initialisation spécifique au trustlet, y compris l’allocation des éléments pertinents dans son segment de données.
  • L’écoute des commandes, implémentée sous forme de boucle while(1) à la fin du gestionnaire.

À la réception d’une nouvelle commande provenant du monde Normal, l’écouteur appelle la fonction cmd_handler pour traiter la requête. Le tampon de requête du monde Normal est placé en tant que premier argument et un tampon de réponse en tant que troisième argument du gestionnaire de commandes.

Figure 4 : Fonction de gestion de commandes du trustlet prov.

Généralement, le corps du gestionnaire de commandes est un grand bloc switch/case de l’ID de commande demandé. L’ID de commande est le premier double mot du tampon d’entrée. Dans notre exemple, le trustlet prov s’attend à des ID de commande 0x70001 – 0x7000F.

Nous pouvons noter que le trustlet prov utilise la bibliothèquecmnlib.so du monde Sécurisé. La bibliothèque fait partie de QSEE et intègre le format ELF signé en tant que trustlet. QSEOS charge automatiquement la bibliothèque cmdlib en mémoire. Tous les trustlels pertinents seront reliés à cette instance unique lors de leur chargement.

Tous les trustlets ainsi que la bibliothèque cmnlib sont chargés dans la région d’application sécurisée spéciale (région secapp) de la mémoire physique, inaccessible depuis le monde Normal. L’adresse de départ et la taille de la région peuvent être facilement trouvées dans le journal du noyau Android.

Figure 5 : Informations sur la région secapp.

Les segments prov du trustlet sont situés dans la plage secapp0xapp600000 – 0xdb00000.

Les points suivants importants devraient être notés :

  • QSEOS protège la région mémoire d’un trustlet contre les accès effectués à partir d’un autre trustlet.
  • Toutes les allocations de mémoire demandées par un trustletseront effectuées dans la région du segment de données du trustlet lui-même.
  • La région de la pile d’un trustlet fait partie de la région de son segment de données.

Cela signifie que toutes les données liées à un trustlet sont concentrées au même endroit : sa propre région de segment de données. Le registre R9 pointe toujours sur l’adresse initiale du segment de données.

Comment exécuter une application de confiance dans le monde Normal

Maintenant que nous avons les informations nécessaires sur QSEE, réfléchissons à la façon d’exécuter le fichier ELF du trustlet dans le monde Normal. Pour simplifier les choses, supposons que nous puissions détecter les adresses de début du code et des segments de données du trustlet dans le monde Sécurisé, puis les enregistrer. De cette façon, nous pouvons implémenter un programme Android simple (chargeur de trustlet) pour :

  • Allouer des blocs de mémoire avec des autorisations de lecture/écriture/exécution pour le code et les segments de données du trustlet. Les adresses virtuelles de ces blocs doivent être identiques aux adresses des segments de la région secapp. Il est tout à fait possible d’allouer de la mémoire virtuelle près de l’adresse 0xd600000.
  • Lire le contenu des segments enregistrés dans la mémoire allouée.
  • Préparer des tampons qui seront utilisés en entrée et en sortie pour le gestionnaire de commandes du trustlet.
  • Faire pointer le registre R9 sur le segment de données et appeler la fonction de gestion de commandes du trustlet.

Pour le trustlet prov, nous allouons 0x6ED0 octets pour son segment de code et 0x103F0 octets pour les données. Le décalage de la fonction du gestionnaire de commandes dans le code est de 0x2056 octets. Le tampon de requête le plus simple est le suivant.

Figure 6 : Exemple de tampon de requête pour le trustlet prov.

La fonction du gestionnaire de commandes démarre. Les opcodes ARM du trustlet sont les mêmes que dans le programme Android classique. Si nous avons de la chance, la commande demandée sera traitée avec succès. Cependant, une telle exécution entraînera très probablement le plantage du code du trustlet. Cela pour deux raisons :

  • Le gestionnaire de commandes a appelé une fonction de la bibliothèque cmnlib lors de son exécution mais nous n’avons pas chargé la bibliothèque.
  • Le gestionnaire de commandes a effectué un appel système lié à QSEOS qui ne peut être reconnu par le noyau Linux.

Les segments de la bibliothèque cmnlib peuvent être simplement alloués dans le processus du chargeur de trustlet de la même manière que les segments du trustlet étaient alloués précédemment. Cependant, le problème de l’appel système n’est pas simple à résoudre.

Pour résumer, il nous reste à déterminer comment :

  • Détecter les adresses de base d’un trustlet et de la bibliothèquecmnlib dans le monde Sécurisé.
  • Enregistrer les segments de données d’un trustlet et de la bibliothèque cmnlib.
  • Exécuter l’appel système d’un trustlet dans le monde Normal.

Tous ces problèmes peuvent être résolus en corrigeant un trustletchoisi avant de le charger dans le monde Sécurisé. Dans ce cas, nous pouvons obliger sa fonction de gestion de commandes à prendre en charge un autre ID de commande, par exemple 0x99. Le gestionnaire de la nouvelle commande peut effectuer les opérations suivantes :

  • Renvoyer l’adresse de base du trustlet.
  • Lire des données dans la région secapp.
  • Écrire des données dans la région secapp.
  • Effectuer l’appel système demandé.
Figure 7 : Correctif du Trustlet. Gestionnaire de l’ID de commande injecté.

Le correctif du trustlet nous permet de demander l’adresse de base et le bloc mémoire du segment de données du trustlet du monde Normal. L’adresse de base de la bibliothèque cmnlib peut être extraite à partir des données du trustlet. prov stocke le pointeur vers la bibliothèque cmnlib au décalage 0x83D4. Chaque trustlet a accès à la mémoire de la bibliothèque cmnlib et est en mesure de renvoyer son segment de données comme étant le sien.

 

Il s’agit donc maintenant de savoir comment rediriger une demande d’appel système du monde Normal vers le monde Sécurisé pendant l’exécution du gestionnaire de commandes du trustlet. Pour cette tâche, nous pouvons utiliser Quick Emulator (QEMU), après avoir étendu ses appels système. Les commandes ARM SVC 0x1400 et SVC 0x14F9 doivent déclencher une nouvelle demande d’appel système vers un trustlet corrigé.

Figure 8 : Correctif QEMU. Interception des appels système liés à QSEOS.

Le schéma d’émulation ressemblera à ceci :

 

Figure 9 : Schéma d’émulation du trustlet.

 

Le dernier ajustement important concerne la pile. L’appel système à QSEOS s’attend à recevoir jusqu’à six arguments. Cela signifie qu’une demande d’appel système, que nous enverrons à un trustletcorrigé, contient six paramètres. Un argument peut être un pointeur vers des données situées dans une pile. Cependant, le chargeur detrustlet du monde Normal et le trustlet du monde Sécurisé possèdent des piles différentes. Pour la pile, nous devons utiliser une plage d’adresses accessible aux deux. La solution la plus simple consiste à étendre le segment de données du trustlet et faire pointer le registre SP du chargeur vers la fin du segment de données avant de passer à la fonction de gestion de commandes.

Figure 10 : Appel du gestionnaire de commandes du trustlet à partir du chargeur.

Le correctif pour le trustlet prov :

  • Le segment de code est étendu de 0x6ED0 à 0x7000 octets.
  • Le code du gestionnaire d’ID de commande 0x99 est écrit à 0x6ED0.
  • 4 octets à 0x2060 sont corrigés en BL 0x6ED0 (saut vers le nouveau gestionnaire d’ID de commande).
  • Le segment de données est étendu de 0x103F0 à 0x11000 octets.

 

La configuration préparée nous permet d’exécuter une application de confiance dans le monde Normal. Mais nous devons résoudre un dernier problème.

Comment charger une application de confiance corrigée dans le monde Sécurisé

Un démarrage sécurisé est défini comme étant une séquence de démarrage dans laquelle l’image logicielle à exécuter est authentifiée comme ayant été précédemment vérifiée. Sur les appareils mobiles, le chargeur de démarrage principal (PBL) en ROM charge et authentifie le chargeur de démarrage secondaire (SBL) comme prochaine image à exécuter. Le SBL charge et authentifie le chargeur de démarrage d’applications Little Kernel et la partition TrustZoneprésentée par QSEOS. QSEOS charge et authentifie les applications de confiance. Cette chaîne de confiance ne peut pas être rompue de manière légitime, telle que le déverrouillage du chargeur de démarrage. Même si nous avons des permissions root sur Android, nous ne pouvons pas appliquer de correctifs aux composants de laTrustZone. Cela signifie que le seul moyen de briser la chaîne est d’exploiter une vulnérabilité.

La cible de notre attaque est l’algorithme de vérification de trustlet. Nous voulons contourner le code QSEOS chargé du calcul de la signature du bloc de hachage ou de la comparaison des hachages réels des segments avec ceux vérifiés. Le code QSEOS est protégé en écriture par le composant matériel XPU. Par conséquent, le contournement du code n’est possible que dans le cas de l’exploitation d’une vulnérabilité associée à SBL pour interrompre la vérification de la partition TrustZone. Une exploitation de vulnérabilité dans le code QSEOS ne peut conduire qu’à un correctif de segment de données. Cependant, comme nous le verrons plus tard, c’est suffisant pour infiltrer le processus de vérification.

Une exploitation de vulnérabilité 1-day convenable et bien décrite peut être facilement trouvée via une recherche sur Internet : https://github.com/laginimaineb/cve-2016-2431. Plus précisément, une chaîne de deux exploitations de vulnérabilité, CVE-2015-6639 et CVE-2016-2431, nous offre un moyen possible de corriger le segment de données QSEOS sur un appareil Nexus 6 avec une version d’Android allant jusqu’à MOB30D. Nous pouvons y utiliser des primitives préparées pour attaquer le mécanisme de vérification avant de charger un trustlet corrigé.

 

Figure 11 : Schéma du correctif QSEOS.

 

La fonction qsee_load_and_auth_elf_image de QSEOS s’occupe du chargement et de la vérification du fichier ELF du trustlet. Il appelle la fonction tzbsp_pil_init_image pour l’analyse du fichier et la validation de la signature du bloc de hachage.

 

Figure 12 : Vérification de la signature du trustlet.

Nous devons faire attention à ce qui suit :

  • L’objet base_info est alloué dans le segment de données. Il contient les résultats de l’analyse de l’en-tête du fichier, y compris le bloc de hachage vérifié.
  • L’état actuel du processus de chargement est enregistré en tant que global à 0xFE82C358. L’état passe à la valeur 2 après vérification de la signature du bloc de hachage.
  • La vérification réelle des hachages des segments n’est pas implémentée dans cette fonction.

À partir de là, le bloc de hachage est considéré comme étant vérifié et est poussé vers l’objet base_info. Le calcul et la validation des hachages des segments du programme seront effectués un peu plus tard dans la fonction tzbsp_pil_auth_reset. Si nous écrasons l’entrée de bloc de hachage située dans base_info par une autre adaptée au trustlet corrigé, la fonction tzbsp_pil_auth_reset s’exécutera correctement et chargera avec succès ce trustlet corrigé.

L’exploitation de vulnérabilité 1-day choisie nous permet de corriger le segment de code QSEOS 0xFE806000 – 0xFE80FFB0. Nous devons faire ce qui suit :

  • Injecter du code qui corrigera l’objet base_info par un bloc de hachage pertinent au lieu d’un blob de chaînes à 0xFE80D774.
  • Injecter un saut vers notre shellcode dans la fonctionmap_region, qui sera appelé plusieurs fois avant la fonctiontzbsp_pil_auth_reset, au lieu, par exemple, d’une vérification de limites à 0xFE8066F8.
Figure 13 : Correctif QSEOS. Contournement de la vérification des trustlets.

En conséquence, nous avons maintenant la possibilité de remplacer le bloc de hachage d’un trustlet après vérification, mais avant de l’utiliser pour valider les segments. Nous pouvons désormais calculer manuellement le bloc de hachage d’un trustlet corrigé et l’utiliser au lieu de celui d’origine. Ce trustlet sera vérifié avec succès. Il est intéressant de noter que nous pouvons également charger destrustlets provenant d’un autre appareil. Il suffit de remplacer la table de hachage, la signature et la chaîne de certificats dans le fichier .mdt dutrustlet par ceux extraits du trustlet du fabricant de l’appareil.

Fuzzing d’une application de confiance

Nous pouvons maintenant exécuter une application de confiance dans le monde Normal. Nous avons trouvé un moyen de charger une version corrigée d’un trustlet signé dans le monde Sécurisé, et avons adapté l’émulateur pour communiquer avec ce dernier. En d’autres termes, nous avons émulé le gestionnaire de commandes d’untrustlet sur le système d’exploitation Android. Il ne reste plus qu’à appeler le gestionnaire de commandes de manière répétée avec différentes entrées générées à partir des paramètres du code. L’émulateur QEMU peut être utilisé pour produire ces paramètres.

AFL (American Fuzzy Lop) est un moteur de fuzzing open source populaire intégré à l’émulateur QEMU pour le fuzzing de fichiers binaires propriétaires. Les versions suivantes d’AFL, de l’émulateur en mode utilisateur QEMU et de bibliothèques tierces ont été créées et utilisées dans le fuzzer :

  • libiconv 1.14
  • libffi 3.2.1
  • gettext 0.19.7
  • glib 2.48.1
  • AFL 2.52b
  • QEMU 2.10.0

Le fuzzer préparé a facilement découvert que le trustlet prov peut être planté par le paquet suivant.

Figure 14 : Tampon d’entrée malformé pour le trustlet prov.

Le gestionnaire de commandes 0x7000D ne s’attend pas à recevoir un premier argument supérieur à 9999.

Le fuzzer nous a aidé à trouver des vulnérabilités dans l’application de confiance Qualcomm prov sur un appareil Nexus 6 avec la dernière ROM officielle (Android 7.1.2 N6F27M). Le bug prov est également reproductible sur les appareils Moto G4/G4 Plus (XT1643 et XT1640).

Et maintenant ? À ce stade, il serait intéressant de trouver le moyen de fuzzer des applications de confiance extraites d’un autre appareil, pas uniquement celles du Nexus 6. Bien sûr, nous pouvons essayer de trouver une nouvelle exploitation de vulnérabilité 1-day qui nous permettrait de corriger QSEOS, par exemple sur un appareil Samsung, comme nous l’avons fait sur le Motorola Nexus 6. Dans ce cas, nous pouvons utiliser un modèle de fuzzing préparé, sans aucune modification, pour les trustlets des nouveaux appareils. Il est cependant beaucoup plus facile d’adapter un trustlet Samsung pour l’utiliser sur un Nexus 6 que de rechercher et d’adapter une nouvelle exploitation de vulnérabilité QSEOS.

Correction d’une application de confiance

Comme indiqué précédemment, notre plate-forme de fuzzing utilise deux exemplaires d’un trustlet. L’un est destiné au chargement dans le monde Sécurisé et le second est destiné à l’exécution par le fuzzerdans le monde Normal. Le premier exemplaire doit être corrigé pour contourner la vérification de QSEOS au chargement et intégrer notre ID de commande dans le monde Sécurisé. L’exemplaire du monde Normal sera corrigé principalement pour fournir les liens d’importation corrects vers la bibliothèque cmnlib associée à l’appareil.

Nous avons déjà corrigé le trustlet prov et il peut être utilisé à nouveau comme serveur du monde Sécurisé, quel que soit le trustletfuzzé. Mais dans ce cas, nous devons appliquer plusieurs correctifs au trustlet prov en fonction des paramètres du nouveau trustlet :

  • Correction de la taille des segments de programme.
  • Correction des paramètres de pile utilisés pour l’enregistrement du trustlet.
  • Liens cmnlib contournés et code d’auto-initialisation.

Néanmoins, nous mettons prov de côté et essayons d’adapter un trustlet d’un autre appareil. Cela fournira quelques détails supplémentaires sur le processus de chargement du trustlet.

Nous avions précédemment indiqué que l’exploitation de vulnérabilité QSEOS utilisée nous permettait de contourner la vérification d’untrustlet au chargement afin de remplacer la table de hachage, la signature et la chaîne de certificats dans son fichier .mdt par ceux extraits d’un trustlet Nexus 6 standard. C’est un correctif obligatoire. Par ailleurs, QSEOS sur Nexus 6 limite le nombre de segments de programme du trustlet. Un seul segment de données est autorisé. Un trustlet ne sera pas chargé s’il est composé de plus de quatre fichiers .bXX. Pour contourner cette limitation, vous pouvez fusionner tous les segments de données du trustlet (.b03, …) dans un seul fichier. N’oubliez pas de modifier le fichier d’en-tête en conséquence.

Après vérification, QSEOS appelle la fonction start du trustlet, dans laquelle il s’enregistrera dans le système via l’appel système -0x100. Il fournit la taille de la pile, le pointeur de pile, le pointeur sur son nom et le pointeur sur sa fonction de gestion en tant qu’arguments. Les nouvelles versions des applications de confiance utilisent quatre arguments supplémentaires. Ce code peut être contourné à l’aide d’un script IDA sans nuire à l’exécution d’un trustlet. Par exemple, le trustlet kmota du LG G4 (Android 6.0 MRA58K) peut être corrigé à l’aide du simple script suivant.

Figure 15 : Correction de la fonction d’entrée kmota du trustlet.

 

Dans le cas du trustlet authnr du Samsung S7 Edge (Android 8.0 G935UUES8CRK2), il est plus facile de construire manuellement les arguments d’appel système que d’utiliser les structures d’origine préparées.

Figure 16 : Correction de la fonction d’entrée authnr du trustlet.

 

Après enregistrement, QSEOS sur Nexus 6 appelle la fonction de gestion du trustlet et fournit des pointeurs vers les segments de code et de données de la bibliothèque cmnlib comme arguments. Regardons la fonction de gestion du trustlet tzpr25 du Samsung S5 (Android 6.0 G900FXXU1CRH1).

 

Figure 17 : Fonction de gestion du trustlet tzpr25.

 

Cette fonction comprend deux parties logiques : initialisation et écouteur de commandes. La partie initialisation n’affecte pas le chargement du trustlet et doit être contournée à partir de l’exemplaire du monde Sécurisé. Inversement, l’écouteur de commandes doit être reproduit dans les versions les plus récentes des trustlets dans lesquels il a été contourné par le gestionnaire. L’écouteur de commandes minimal ressemble à ceci :

Figure 18 : Écouteur de commande généré du trustlet authnr.

La partie initialisation du gestionnaire du trustlet est chargée de :

  • L’allocation des données initiales du trustlet dans son segment de données.
  • La liaison avec la bibliothèque cmnlib extraite du même appareil que le trustlet. Le code d’allocation de la table d’importation dans les données du trustlet est implémenté dans la fonction cmnlib à l’offset 0. Le trustlet appelle simplement la fonction et fournit les pointeurs de données pertinents sous forme d’arguments.

La fonction de gestion doit être exécutée dans le monde Normal avant le fuzzing. L’écouteur de commande devrait être contourné s’il se présente.

La toute dernière version de QSEOS comporte une fonctionnalité supplémentaire permettant de corriger l’exemplaire d’un trustlet du monde Normal. Les trustlets sur les appareils Android 8 et 9 n’utilisent plus le registre R9 comme pointeur sur le segment de données. Ces trustlets utilisent des pointeurs de données qui supposent que l’adresse de base du segment de code est 0. Pour corriger ce problème, tous les pointeurs alloués dans le segment de données doivent être étendus avec l’adresse du trustlet de la région secapp.

 

Le script IDA suivant trouve les pointeurs à corriger dans le trustletesecomm du Samsung S7 Edge.

 

Figure 19 : Recherche des xref dans le segment de données dutrustlet esecomm.

En conclusion, nous avons répertorié tous les correctifs globaux à appliquer aux trustlets hors Nexus 6. Quand bien même, chaque trustlet peut nécessiter une approche individuelle. Au cours de nos recherches, nous avons adapté avec succès plusieurs applications de confiance extraites d’appareils LG et Samsung.

Voici une liste partielle des vulnérabilités détectées par la plate-forme de fuzzing : dxhdcp2, kmota, tzpr25, sec_store, authnr et esecomm.

Morgane
Morgane Palomo

Diplômée d'un master un brand management marketing, sa curiosité et sa soif de savoir ne sont étanchées. De nature créative, elle a su diversifier ses expériences. De la création graphique, à l'événementiel en passant par la communication interne et le marketing digital, elle s’est construit un savoir pluriel et avant tout polyvalent.

Written by Morgane Palomo

Diplômée d'un master un brand management marketing, sa curiosité et sa soif de savoir ne sont étanchées. De nature créative, elle a su diversifier ses expériences. De la création graphique, à l'événementiel en passant par la communication interne et le marketing digital, elle s’est construit un savoir pluriel et avant tout polyvalent.