- tachy0n est un cas de publication d’un exploit de jailbreak 0day récent pour iOS 13.0 à 13.5
- Ce bug est une condition de concurrence (race condition) dans l’appel système
lio_listio, appelée Lightspeed, exploitant une vulnérabilité LPE (élévation de privilèges) du noyau
- Cette vulnérabilité a été effectivement utilisée dans plusieurs projets de jailbreak, dont Spice et unc0ver, et le texte explique la méthode d’exploitation ainsi que des techniques de hacking liées aux problèmes de gestion mémoire
- Après la publication de cet exploit, Apple a déployé un correctif et introduit des tests de régression, tout en renforçant fortement l’isolation des objets du noyau (Zone, kheap, etc.) et les mécanismes de protection des pointeurs
- À partir d’iOS 14, l’environnement des jailbreaks et des exploits noyau a fondamentalement changé, au point qu’il n’existe plus aujourd’hui d’exploit noyau public
0. Introduction
- tachy0n est un ancien exploit applicable à iOS 13.0 à 13.5
- Il a été publié comme 0day le 23 mai 2020 dans unc0ver v5.0.0, et Apple l’a corrigé en urgence une semaine plus tard à peine
- Cette vulnérabilité avait déjà été exploitée auparavant comme 1day, ce qui en fait un cas jugé significatif du point de vue des techniques d’exploitation
- Il s’agit d’un article qui explique en détail la source de la vulnérabilité et les circonstances de sa découverte
1. Lightspeed
- Cette vulnérabilité est le bug Lightspeed (CVE-2020-9859, etc.) présenté par Synacktiv, où un problème de race condition survient lors de la libération de la mémoire du contexte d’E/S asynchrone de l’appel système
lio_listio
- En ajustant le timing des opérations d’E/S pour créer une condition de double free mémoire, il devient possible de superposer plusieurs objets dans la même zone mémoire via deux libérations d’objet
- la structure d’allocation mémoire dynamique de la zone
kalloc.16 du noyau est exploitée dans l’exploit
- il s’agit fondamentalement d’une méthode qui augmente la probabilité de succès en répétant la race à de nombreuses reprises
2. Spice
- Cet exploit a été utilisé dans le jailbreak Spice créé autrefois par l’équipe Jake Blair
- Des variantes différentes de l’exploit ont été implémentées dans racoon et dans l’app, avec comme objectif principal la falsification de port mach
- À l’époque d’iOS 11.x, le contournement de PAN (Protection Against Null dereference) était facile, et diverses techniques de hacking étaient tentées en combinaison avec un infoleak noyau et un sandbox escape
- Dans le cas de racoon, en raison des restrictions d’accès à IOKit, des objets cibles pour le spray dans la zone du noyau étaient créés à l’aide de OSUnserializeXML
- Les différences de détail autour de sysctl_procargsx, des fuites de mémoire noyau non initialisée, des politiques de sandbox et des évolutions techniques ultérieures sont également décrites
3. unc0ver
- Lors de son intégration dans unc0ver, la structure de l’exploit a été conçue pour fonctionner sur une large gamme de SoC, d’A8 à A13 inclus
- Le suivi de l’imbrication et du chevauchement des objets OSData, ainsi que la libération/allocation du bon objet au bon moment, permettent de contrôler la zone mémoire
- En exploitant des objets noyau comme IOMemoryDescriptor, il devient possible d’exposer l’adresse d’un tampon de données contrôlé par l’utilisateur et d’implémenter des lectures/écritures directes depuis le noyau
- L’exploit utilise de manière appropriée les faiblesses des politiques de l’allocateur mémoire du noyau d’iOS 13, notamment pour contourner zone_require
- L’implémentation détaillée de la structure complète de l’exploit peut être consultée dans le dépôt GitHub public (tachy0n)
4. Impact ultérieur
- La publication d’un exploit 0day a eu un fort retentissement dans la communauté sécurité comme chez Apple
- quatre heures seulement après la publication de l’exploit réel, Project Zero et Synacktiv avaient déjà produit des analyses détaillées et engagé une réponse
- Après le correctif, Apple a ajouté à XNU un véritable test de régression pour cette vulnérabilité, marquant un virage vers un renforcement fondamental de sa stratégie de sécurité
- À partir d’iOS 14, des changements majeurs ont été introduits — séparation des zones d’allocation, object secure guard, PAC (Pointer Authentication Code), structure kheap, etc. — augmentant fortement la difficulté de développer des exploits
- Désormais, la stratégie d’exploitation elle-même est devenue plus importante, et l’écart entre les informations publiques et la recherche privée s’est creusé, au point qu’il n’existe plus aucun exploit noyau public pour iOS 17 à 18
5. Conclusion
- C’est un cas qui montre clairement à quel point le domaine de la sécurité iOS et du jailbreak a radicalement changé en cinq ans
- Il offre un éclairage sur la manière dont ont évolué les orientations techniques de la communauté du jailbreak/exploit, des chercheurs, et d’Apple
- L’époque où l’on partageait les IL et relevait des défis appartient désormais au passé, et depuis iOS 14 le partage d’informations sur les exploits s’est nettement réduit
Références et contact
- Le code source lié et des informations détaillées sont disponibles sur le site personnel de Siguza et dans le dépôt GitHub public
2 commentaires
Le matériel d’Apple est excellent, mais son logiciel est truffé de mécanismes conçus pour tenir les utilisateurs en laisse.
Même si vous voulez simplement faire tourner sur votre propre appareil une app que vous avez vous-même créée et compilée, il vous faut un abonnement à 100 dollars.
Si vous êtes développeur, que vous utilisez de petites ou moyennes apps open source et que vous les compilez vous-même pour les utiliser,
il est plus simple de prendre un Android que de devoir exploiter des vulnérabilités et jailbreaker un appareil Apple pour faire du sideloading.
Avis Hacker News
Il est mentionné que SockPuppet avait déjà été utilisé auparavant pour un jailbreak à l’époque d’iOS 12, puis qu’après avoir été signalé à Apple par Ned Williamson de Project Zero et corrigé dans iOS 12.3, il est réapparu dans iOS 12.4
Apple semble probablement avoir forké XNU sur une branche séparée et oublié d’y reporter ce correctif, et le vrai problème est surtout l’absence totale de tests de régression pour ce type de vulnérabilités, nouvelles comme anciennes
J’ai moi-même automatisé quelques vulnérabilités 1-day connues en tests de régression, et j’ai immédiatement réussi à les redétecter
Je me demande si, dans divers projets open source comme Linux, FreeBSD, OpenWRT ou OpenSSH, on exécute aussi des tests de régression sur les anciennes vulnérabilités à chaque nouvelle version
Si chaque vulnérabilité était formalisée de manière automatisée, et qu’on pouvait allouer les ressources nécessaires pour les exécuter en CI, cela apporterait clairement beaucoup de valeur
Je partage le souvenir de mon bénévolat en QA chez Mozilla à l’université, il y a 20 ans, où il existait des centaines de cas de tests de régression
Il s’agissait surtout de bugs de rendu/mise en page et du moteur JS, et dès qu’on créait un cas de test minimal, on pouvait l’ajouter directement à la pipeline CI
Les bugs eux-mêmes sont inévitables, mais le pire, c’est quand un bug déjà corrigé réapparaît, car c’est une perte de temps et d’argent ; à mes yeux, toute organisation soucieuse de la qualité investit forcément beaucoup dans les tests de régression
Malheureusement, beaucoup d’organisations négligent la QA ou la traitent uniquement par sous-traitance, sans vraiment s’y investir
Je ne comprends pas qu’Apple n’ait pas eu de tests de régression liés au jailbreak
Depuis longtemps déjà, chez Mozilla notamment, des outils comme Tinderbox et Bugzilla permettaient de mettre en place d’excellents environnements de QA et de CI/CD, et je pensais que ce mode de fonctionnement était courant bien avant l’émergence du concept de DevOps ; j’ai découvert assez tard que ce n’était pas réellement le cas
Il y avait des milliers de cas de test, et je crois qu’il s’agissait de Sqlite
Si on ne rétroporte pas le patch, il y a aussi de fortes chances qu’on ne rétroporte pas non plus le test correspondant
Au final, la loi de Conway s’applique aussi telle quelle entre la sécurité et le développement fonctionnel
Ainsi, même dans une organisation dont les procédures de build/release sont bien équipées en tests de régression, la structure interne augmente le risque que les sujets de sécurité passent à la trappe
il est avancé que les services de renseignement (G10, Russie, Chine, Corée du Nord, etc.) ainsi que de nombreux groupes privés procèdent évidemment de cette manière pour tester les vulnérabilités en régression
c’est comparé à une discussion avec un ami dans une langue étrangère qui, l’instant d’après, bascule sur un sujet ultra-spécialisé comme la neurochirurgie ou la physique nucléaire, laissant complètement l’esprit vide
Cela rappelle le souvenir d’avoir essayé autrefois d’interpréter une conversation sur la réparation d’une aciérie
C’est dommage que le jailbreak ait disparu ; je n’ai pas vraiment tiré une grande utilité pratique de mon iPad jailbreaké, mais j’y trouvais un plaisir en soi
Aujourd’hui, j’aimerais y installer une app de tethering, UTM ou une solution JIT
SideStore semble prometteur et j’aimerais l’essayer, mais mon compte Apple était autrefois un compte développeur payant, et comme 10 identifiants d’app n’ont pas expiré, cela bloque l’installation de ce type d’apps
Il faudrait soit créer un nouveau compte, soit repayer
Sans jailbreak, je n’avais absolument aucune raison d’utiliser un iPhone comme téléphone principal, et j’ai fini par passer sur Android
C’était à peu près l’époque où Android avait beaucoup rattrapé son retard en termes de fonctionnalités de base
Faut-il passer par un intermédiaire, existe-t-il une adresse e-mail ou un canal officiel, et peut-on éviter que cela soit simplement enterré par le support de premier niveau ?
Comme le mentionne l’article, des communautés privées détiennent toujours ces vulnérabilités et Apple continue à les corriger
Seuls les jailbreaks rendus publics se sont raréfiés