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

[nicolas69001]

Monsieur Sergi est toujours au taquet quand il s'agit de critiquer les news de "notre" nouveau rédacteur! Dès que je vois les news de Mathieu, j'attends de voir où va porter la critique. Dès fois c'est très subtile!

Ce message a été modifié par nicolas69001 - 7 Feb 2013, 09:26.

[Guest_anonym_8b8d481c_*]

Monsieur Sergi est toujours au taquet quand il s'agit de critiquer les news de "notre" nouveau rédacteur! Dès que je vois les news de Mathieu, j'attends de voir où va porter la critique. Dès fois c'est très subtile!

Oh, c'est juste pour alimenter le buzz... Il est vrai que Starmat me fassine.

Parce que sans la faille de lockdownd, qui provoque un chmod 777 sur un fichier bien précis, la faille sur les liens symboliques ne serait quasiment d'aucune utilité : le lien symbolique conserve les droits d'accès du fichier vers lequel il pointe, donc si un fichier est en 600, t'auras beau faire un lien symbolique dessus, ça te donnera pas pour autant accès à ce fichier.

Mais ca je n'ai pas compris en quoi consistait la faille << lockdownd >>. Ca vient du systeme de commandes par usb, ok. Ca a parmi de changer les droits d'un fichier, d'accord, mais le trou en question est du a quoi ? une commande toute simple chmod 777 qu'on peut envoyer via le truc usb sur n'importe quel fichier qui permet d'envoyer aussi es mv, des cp, des rm et compagnie ? une injection de commande encapsulée dans des string, etc ... L'idée est de savoir mis apart que le trou etait dans le systeme d'acces USB, qu'est ce qui est generique dans cette faille qui puisse etre utile au lecteur afin de connaitre le genre de faille ou il faut faire attention.

Ce message a été modifié par anonym_8b8d481c - 7 Feb 2013, 23:20.

[SartMatt]

Mais ca je n'ai pas compris en quoi consistait la faille << lockdownd >>. Ca vient du systeme de commandes par usb, ok. Ca a parmi de changer les droits d'un fichier, d'accord, mais le trou en question est du a quoi ? une commande toute simple chmod 777 qu'on peut envoyer via le truc usb sur n'importe quel fichier qui permet d'envoyer aussi es mv, des cp, des rm et compagnie ? une injection de commande encapsulée dans des string, etc ...

Si on pouvait "envoyer via le truc usb sur n'importe quel fichier", crois-tu vraiment que les hackers se seraient emmerdés avec ce système de liens symboliques ?

lockdownd attend des commandes (pas des commandes shell, des commandes spécifiques au service lockdownd) envoyées via l'interface USB. Dans certains cas, une commande malformée (ou bien formée, selon le point de vue ) provoque un comportement anormal du service, qui résulte à faire un chmod 777 sur /var/db/timezone

Ceux qui ont analysé le fonctionnement du jailbreak n'ont pas donné plus de détail (y a un lien source dans la news, rien ne t'empêche de cliquer dessus pour aller demander plus d'informations...).