q1f3/triple_fetchCeci est un exploit pour CVE-2017-7047, fonctionne sur 10.3.2 et versions antérieures.
triple_fetch - ianbeer [https://bugs.chromium.org/p/project-zero/issues/detail?id=1247]
Ceci est un exploit pour CVE-2017-7047, une erreur de logique dans libxpc qui permettait aux expéditeurs de messages malveillants d'envoyer des objets xpc_data soutenus par de la mémoire partagée. Les consommateurs de messages xpc ne semblaient pas s'attendre à ce que les tampons de support des objets xpc_data puissent être modifiés par l'expéditeur pendant leur traitement par le récepteur.
Ce projet exploite CVE-2017-7047 pour construire une preuve de concept de stub debugserver distant lldb capable de s'attacher à et de permettre le débogage à distance de tous les processus espace utilisateur sur iOS.
Ceci est un aperçu de haut niveau de l'exploit, un article détaillé pourrait suivre ultérieurement. Pour l'instant, veuillez consulter le code pour plus de détails :)
Partie I
L'exploit cible NSXPC, une implémentation d'appel de procédure distante Objective-C utilisée par de nombreux services iOS (1). Un message NSXPC consiste en un objet sérialisé bplist16 à l'intérieur d'un objet xpc_data sérialisé xpc à l'intérieur d'un message mach.
Entre autres, l'objet bplist16 contient une chaîne d'encodage de type Objective-C (2) qui sera analysée par la fonction ___NSMS1 de CoreFoundation. Cette fonction ne s'attend pas à ce que le contenu de la chaîne qu'elle analyse change et cet exploit utilise cela pour construire une primitive de débordement de tas en exploitant le fait qu'une certaine partie de la chaîne sera récupérée de la mémoire trois fois. En alternant entre trois valeurs différentes soigneusement choisies, nous pouvons déborder d'une taille d'allocation de tas choisie avec des octets arbitraires.
minibplist16.c contient une implémentation minimale de la sérialisation bplist et une discussion sur son fonctionnement.
Le message xpc externe contient le toilettage du tas. Il utilise une implémentation personnalisée du protocole de sérialisation XPC pour toiletter le tas en créant des dictionnaires xpc avec des clés en collision afin de construire des primitives d'allocation et de libération.
Le message xpc externe contient également un spray de tas (en utilisant plusieurs copies d'un objet mémoire partagée pour maintenir une faible utilisation mémoire) et un spray de noms de droits d'envoi de port mach.
Le débordement pointe le pointeur de classe isa d'un objet Objective-C vers un objet factice pulvérisé sur le tas, de sorte que lorsqu'une méthode est appelée sur cet objet factice, la pile est pivotée vers une petite pile ROP. Le ROP force brute à travers les noms de droits d'envoi de port mach pulvérisés en essayant d'envoyer le droit d'envoi de la cible vers son propre port de tâche à chacun des noms de droits d'envoi pulvérisés candidats. L'exploit écoute sur tous les ports pulvérisés et si l'exploit réussit, il reçoit un droit d'envoi vers le port de tâche de la cible, à ce moment il a un contrôle total sur la tâche cible.
Interlude
L'exploit cible le service com.apple.CoreAuthentication.daemon hébergé par le démon coreauthd qui s'exécute en tant que root. Ce service peut être atteint depuis le bac à sable de l'application. Un peu d'expérimentation après avoir initialement fait fonctionner l'exploit a révélé que depuis le contexte de coreauthd, l'API processor_set_tasks peut obtenir des droits d'envoi vers les ports de tâche pour tous les processus espace utilisateur en cours d'exécution sur l'appareil. Cela est de notoriété publique depuis au moins 2012 et l'historique est couvert en profondeur par le célèbre chercheur en internals iOS Jonathan Levin sur son site (3). Le code que Levin a téléchargé en 2015 fonctionne encore aujourd'hui - il ne nécessite pas un appareil jailbreaké, simplement root sur un appareil standard.
Partie II
L'objectif principal du débogueur que je voulais construire avec cet exploit était de pouvoir s'attacher à un processus arbitraire, définir des points d'arrêt et inspecter et modifier l'état des registres et de la mémoire lorsqu'ils sont atteints. Plutôt que d'implémenter le protocole distant gdb ou lldb à partir de zéro, j'ai décidé d'apporter les modifications nécessaires au projet debugserver de lldb, puis d'utiliser l'exploit pour l'exécuter.
Plutôt que d'utiliser des points d'arrêt logiciels qui nécessitent soit de désactiver, soit de contourner la signature de code, le debugserver est patché pour utiliser exclusivement des points d'arrêt matériels. ARM64 dispose de 16 registres de points d'arrêt matériels, ce qui signifie que vous ne pouvez avoir qu'un maximum de 16 points d'arrêt actifs.
Un support prototype pour les points d'arrêt matériels ARM existait dans le code debugserver de lldb mais il nécessitait quelques bidouilles pour le faire fonctionner. Par exemple, j'ai dû ajouter du code qui patche le pointeur de fonction pthread_introspection_hook dans le débogué pour qu'il plante toujours afin de pouvoir détecter la création de nouveaux threads et propager l'état des points d'arrêt matériels dans les threads nouvellement créés et continuer comme s'il n'avait jamais planté.
J'ai également patché le code d'attachement et de continuation pour suspendre et reprendre directement la tâche via le port de tâche plutôt que d'utiliser ptrace et les signaux.
Conseils de construction
Tout devrait fonctionner pour tous les appareils iOS exécutant 10.0 à 10.3.2 inclus. J'ai testé sur :
J'ai inclus un binaire debugserver pré-construit que je suggère d'utiliser, mais le patch pour le debugserver de lldb est également inclus dans debugserver.diff.
Construire le debugserver n'est pas trop difficile. Je travaillais à partir des révisions git suivantes : lldb: 0db640c4cd1ec4e4c2580336fa5f53be029c5bc7 llvm: ec48fd127774a4b67c72ea7c3057b5c964375e77 clang: b6e778e0bfa2fc32f8821c6b33762f5cb6724659
appliquer le debugserver.diff fourni.
Pour la construction, vous avez besoin de cmake (récent) et ninja, vous pouvez les obtenir depuis les sources ou les binaires depuis votre gestionnaire de paquets mac préféré.
(4) contient un guide pour configurer une construction llvm normale sur MacOS qui peut être utile.
Vous aurez besoin de créer des liens symboliques vers un tas de fichiers d'en-tête dans votre SDK iOS, au moins :
xpc/ launchd.h libproc.h sys/proc_info.h sys/kern_control.h net/route.h mach/mach_vm.h mach/shared_region.h sys/ptrace.h crt_externs.h
l'incantation cmake suivante devrait vous donner tous les indices dont vous avez besoin :
cmake -G "Ninja" -DCMAKE_OSX_ARCHITECTURES="armv7;armv7s;arm64" -DCMAKE_TOOLCHAIN_FILE=../cmake/platforms/iOS.cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_RUNTIME=Off -DLLVM_INCLUDE_TESTS=Off -DLLVM_INCLUDE_EXAMPLES=Off -DLLVM_ENABLE_BACKTRACES=Off ../
ninja debugserver
Vous devrez ensuite signer ou fakesigner le binaire debugserver et remplacer celui du projet xcode fourni.
Signature de code
Le projet d'exploit installera par défaut une version améliorée du hook amfid de mach_portal (cette fois avec un support fonctionnel pour les fichiers fat et pas de décalages codés en dur :) )
Si vous voulez simplement déboguer des trucs, vous devriez pouvoir signer le binaire debugserver avec votre propre certificat et désactiver le hook amfid.
Si vous utilisez le hook amfid, gardez à l'esprit que l'application dans laquelle il s'exécute est toujours soumise aux limites d'exécution de code en arrière-plan. L'application demande plus de temps via beginBackgroundTaskWithName.
Utilisation :
Connectez votre hôte et l'iDevice cible au même réseau sans fil et notez l'adresse IP de l'iDevice.
Construisez et exécutez l'application d'exploit. Je recommande de le faire dans xcode mais cela fonctionnera de manière autonome.
Attendez un peu. Si cela ne fonctionne pas après quelques minutes, redémarrez l'appareil, attendez un peu puis réessayez.
Si cela fonctionne, il devrait afficher « patched debugserver listening on port 1234 »
Si vous cliquez sur le bouton « get process listing », vous devriez voir la sortie de ps
(c'est plus facile de voir la sortie si vous utilisez xcode mais l'exploit affichera aussi la sortie)
Recherchez le processus cible que vous souhaitez déboguer et notez son pid.
sur l'hôte, lancez lldb depuis la ligne de commande : $ lldb (lldb)
définir la plateforme sur ios remote : (lldb) platform select remote-ios
se connecter au stub debugserver : (lldb) process connect connect://192.168.0.172:1234
(où 192.168.0.172 est l'adresse IP de l'iDevice)
s'attacher au processus qui vous intéresse : (lldb) attach 55
...attendez un peu, debugserver est en mode verbeux...
Process 55 stopped
Executable module set to "/usr/libexec/backboardd".
vous êtes attaché :)
définir un point d'arrêt : (lldb) break set --name malloc Breakpoint 1: 4 locations.
continuer : (lldb) c Process 55 resuming Process 55 stopped
malloc libsystem_malloc.dylibmalloc:
-> 0x1936161e0 <+0>: stp x20, x19, [sp, #-0x20]!
0x1936161e4 <+4>: stp x29, x30, [sp, #0x10]
0x1936161e8 <+8>: add x29, sp, #0x10 ; =0x10obtenir une trace arrière : (lldb) bt
malloc frame #1: 0x0000000100099648 backboardd_mh_execute_header + 71240
frame #2: 0x00000001945bf218 CoreFoundation__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 56 frame #3: 0x00000001945be9cc CoreFoundation__CFRunLoopDoSource1 + 436
frame #4: 0x00000001945bc4b0 CoreFoundation__CFRunLoopRun + 1840 frame #5: 0x00000001944ea2b8 CoreFoundationCFRunLoopRunSpecific + 444
frame #6: 0x0000000194537b44 CoreFoundationCFRunLoopRun + 112 frame #7: 0x00000001000a5ba8 backboardd_mh_execute_header + 121768
frame #8: 0x00000001000a5bec backboardd_mh_execute_header + 121836 frame #9: 0x00000001936a5850 libsystem_pthread.dylib_pthread_body + 240
frame #10: 0x00000001936a5760 libsystem_pthread.dylib_pthread_start + 284 frame #11: 0x00000001936a2d94 libsystem_pthread.dylibthread_start + 4Dépannage :
Installez la dernière version de XCode (développé et testé avec 8.3.3) Si la connexion lldb échoue, assurez-vous d'avoir installé le SDK pour la version iOS cible
Mises en garde :
J'espère corriger cela mais je suis très occupé pour le moment, désolé!
Exécuter d'autres PoC :
Si vous déposez un binaire dans le dossier pocs de ce projet, vous pouvez faire exécuter l'exploit en le sélectionnant dans l'interface sur l'appareil et en cliquant sur « exec bundle binary ».
Il s'exécutera toujours dans le bac à sable de l'application, mais si l'application a un symbole appelé privileged_task_port, elle recevra un droit d'envoi vers le port de tâche de launchd. Le dossier triple_fetch_sdk contient un projet exemple montrant comment vous pouvez utiliser cela pour construire des PoC, par exemple pour déclencher un comportement dans des processus intéressants que vous pouvez ensuite déboguer à l'aide du debugserver.
Il contient également les API d'appel/ports/fichiers/mémoire distants qui vous permettent d'appeler facilement des fonctions dans d'autres processus et de déplacer des descripteurs de fichiers, des ports mach et de la mémoire.
(1) [https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html] (2) [https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtTypeEncodings.html] (3) [http://newosxbook.com/articles/PST2.html] (4) [https://gist.github.com/thlorenz/a068c202f2487ec13809]
Ce projet contient du code (debugserver.diff) et un binaire (debugserver) basés sur lldb qui sont soumis à la licence suivante :
University of Illinois/NCSA Licence Open Source
Copyright (c) 2010 Apple Inc. Tous droits réservés.
Développé par :
LLDB Team
L'autorisation est par la présente accordée, gratuitement, à toute personne obtenant une copie de ce logiciel et des fichiers de documentation associés (le « Logiciel »), de traiter le Logiciel sans restriction, y compris sans limitation les droits d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et/ou vendre des copies du Logiciel, et de permettre aux personnes à qui le Logiciel est fourni de le faire, sous réserve des conditions suivantes :
Les redistributions du code source doivent conserver l'avis de droit d'auteur ci-dessus, cette liste de conditions et les clauses de non-responsabilité suivantes.
Les redistributions sous forme binaire doivent reproduire l'avis de droit d'auteur ci-dessus, cette liste de conditions et les clauses de non-responsabilité suivantes dans la documentation et/ou d'autres documents fournis avec la distribution.
Ni les noms de l'équipe LLDB, des titulaires du droit d'auteur, ni les noms de ses contributeurs ne peuvent être utilisés pour approuver ou promouvoir des produits dérivés de ce Logiciel sans autorisation écrite préalable spécifique.
LE LOGICIEL EST FOURNI « TEL QUEL », SANS GARANTIE D'AUCUNE SORTE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER LES GARANTIES DE QUALITÉ MARCHANDE, D'ADÉQUATION À UN USAGE PARTICULIER ET D'ABSENCE DE CONTREFAÇON. EN AUCUN CAS LES CONTRIBUTEURS OU TITULAIRES DU DROIT D'AUTEUR NE POURRONT ÊTRE TENUS RESPONSABLES DE TOUTE RÉCLAMATION, DOMMAGES OU AUTRE RESPONSABILITÉ, QUE CE SOIT DANS LE CADRE D'UNE ACTION CONTRACTUELLE, DÉLICTUELLE OU AUTRE, DÉCOULANT DE, OU EN RELATION AVEC LE LOGICIEL OU SON UTILISATION OU D'AUTRES INTERACTIONS AVEC LE LOGICIEL.