De multiples failles pour un jailbreak, Réactions à la publication du 07/02/2013

[Rédaction]

Maintenant que le jailbreak evasi0n est disponible, l'analyse du fonctionnement de l'outil donne de nombreux détails sur le fonctionnement de ce jailbreak, détails qui étaient jusqu'à présent jalousement gardés par les hackers, pour être certains que les failles nécessaires ne seraient pas corrigées par Apple dans iOS 6.1.

Il ressort de ces analyses que les hackers ont dû déployer des trésors d'ingéniosité pour exploiter plusieurs failles en série, jusqu'à parvenir au noyau du système.

La clé de la réussite est un bug dans le système de gestion des sauvegardes/restaurations d'iOS via iTunes, qui autorise à restaurer des liens symboliques pointant quasiment n'importe où dans l'arborescence système.

Ce bug est exploité une première fois pour injecter un lien symbolique de /var/mobile/Media/Recordings (dossier contenant normalement des fichiers audio) vers /var/mobile. Le processus peut ainsi profiter de ce lien symbolique pour restaurer une application dans /var/mobile, tout en faisant croire au processus de restauration qu'il s'agit d'un simple fichier média, qui subit des contrôles moins stricts.

Cette application ne contient pas de binaire, mais un faux script shell, dont la ligne définissant l'interpréteur est en fait une commande demandant à launchctl de remonter la partition système en lecture et en écriture, alors qu'elle est normalement montée en lecture seule. L'application comporte également un fichier positionnant la variable d'environnement LAUNCHD_SOCKET pour la faire pointer vers la socket UNIX du processus launchd de l'utilisateur root.

Après redémarrage, un nouveau backup est injecté, avec cette fois deux liens symboliques. Un premier vers /var/db, un second de /var/db/timezone (dont la création est rendue possible grâce au premier lien) vers /var/tmp/launchd. À ce stade, un second bug entre en jeu : affectant lockdownd, le service système traitant les commandes reçues par USB, ce bug provoque lors de l'envoi d'une certaine commande un changement de droits sur /var/db/timezone, le rendant exécutable par tous les utilisateurs. Vous l'aurez compris, grâce au lien symbolique précédément injecté, ce bug donne en fait le droit d'exécuter launchd.

Sur le même principe, le lien /var/db/timezone est modifié pour pointer vers /var/tmp/launchd/sock, et donner ainsi à tous les utilisateurs l'accès à la socket UNIX utilisée pour communiquer avec launchd.

L'utilisateur peut alors lancer l'application DemoApp. Comme elle ne contient pas de binaire, elle peut être exécutée bien qu'elle ne soit pas signée (de fait, il n'y a rien à signer...) et l'exécution de son script déclenche la commande launchtl décrite plus haut. Normalement, une application utilisateur qui appelle la commande launchtl va communiquer avec le processus launchd de l'utilisateur mobile... Mais pas avec DemoApp, qui surcharge la variable pointant vers la socket de launchd pour la faire mointer vers celle du processus launchd root. Cette opération est rendue possible grâce à la manipulation sur le fichier timezone, qui a donné à tous les utilisateurs l'accès à la socket du root.

L'exécution de DemoApp va ainsi permettre de remonter la partition système en la rendant accessible en écriture : c'est cette opération qui va permettre de rendre le jailbreak untethered, en allant modifier la partition système.

Il ne reste donc plus qu'à faire ces modifications, ce qui va être fait, encore une fois, via une injection de liens symboliques dans le processus de restauration. L'opération va créer un répertoire /var/evasi0n contenant une librairie amfi.dylib, un exécutable evasi0n et un nouveau fichier de configuration pour launchd (qui ira remplacer le fichier original via un lien symbolique). Ce nouveau fichier de configuration va permettre d'effectuer à chaque démarrage de l'appareil le remontage en lecture/écriture de la partition système, le chargement de la librairie amfi.dylib (qui sert à désactiver la vérification de signature du code), l'exécution du binaire evasi0n et la création d'un lien de /private/var/evasi0n/sock vers la socket root de launchd, pour la rendre accessible à toutes les applications.

Curieusement, la librairie amfi.dylib fonctionne grâce à une astuce déjà documentée depuis plus de trois ans : elle ne contient aucun code exécutable, ce qui lui permet d'être chargé sans vérification de signature, mais elle redéfinit les fonctions de validation de signature en les remplaçant par d'autres fonctions de l'API iOS. Par exemple, la fonction MISValidateSignature est redirigée vers une autre fonction renvoyant toujours 0, la valeur de retour de MISValidateSignature quand une application est correctement signée.

 

Vu la complexité de l'ensemble du processus, on ne peut que saluer le travail des hackers, qui ont dû se casser les dents sur iOS pendant un bon paquet de fois avant de parvenir à trouver cet enchaînement parfait. Et on comprend mieux pourquoi ils ont tenu à attendre la sortie d'iOS 6.1, les failles en jeu n'étant probablement pas très difficiles à corriger. Le simple fait de vérifier que le processus de restauration ne tente pas de créer des liens symboliques "suspects" permettrait par exemple de casser tout l'édifice.
Par Matthieu Sarter