Failles et iOS

1. Introduction

1.1 Le périmètre de cet article

iOS est aujourd'hui le système d'exploitation de différents terminaux Apple : iPhone, iPod touch, iPad et Apple TV. Ces matériels sont techniquement très proches, mais quelques différences notables apparaissent : par exemple, l'iPhone et certaines versions de l'iPad incluent un système de communication GSM, alors que les autres n'en disposent pas. Ce circuit intégré supplémentaire, le baseband, est une véritable plateforme dédiée, intégrant un CPU, une mémoire, des coprocesseurs et un système d'exploitation temps-réel : dans le cas de l'iPhone 4, l'OS ThreadX d'ExpressLogic pilote le baseband X-Gold 618.

L'objet de cet article étant la sécurité d'iOS, le baseband ne sera pas abordé, mais il est la cible de recherches de vulnérabilités et d'exploits permettant le « SIM unlocking » : l'iPhone Dev Team est ainsi devenue, avec son application ultrasn0w, la référence en la matière.

Nous nous concentrerons sur le System-on-Chip (SoC) applicatif de l'iPhone, le dénominateur commun entre les différentes plateformes Apple exécutant iOS : c'est le processeur en charge des applications graphiques.

Par simplicité enfin, nous utiliserons le terme « iPhone », mais les informations mentionnées ici sont aussi applicables aux autres terminaux iOS, avec un bémol toutefois sur la phase de démarrage bas niveau, qui ne s'applique pas aux anciennes générations (iPhone 2G, iPhone 3G, iPod 1G), étant très différente, car largement modifiée par Apple suite aux exploits développés par l'iPhone Dev Team : Pwnage et Pwnage 2.0.

1.2 Le SoC applicatif

Le SoC a évolué depuis la 1ère génération d'iPhone en 2007 : d'abord de type ARMv6, le CPU est ARMv7 depuis la 3ème génération (iPod 3G, iPhone 3Gs), la fréquence d'horloge du CPU et de la mémoire a augmenté, un processeur d'accélération 3D plus rapide a été intégré, etc. Pour information, la dernière révision en date a pour nom de code S5L8930 (publiquement : A4) et peut intégrer un CPU de 1 GHz et 512 Mo de RAM (iPhone 4). Chaque terminal iOS dispose de plus d'une mémoire NAND en standard d'un espace allant de 4 Go à 64 Go, selon les générations et versions.

La plus grande difficulté vis-à-vis de la recherche de vulnérabilités sur iPhone est qu'il n'existe aucune documentation publique concernant son architecture technique. L'ensemble des adresses d'entrée/sortie et les différentes plages mémoire connues publiquement ont été identifiées par ingénierie inverse du noyau d'iOS. La référence de ces informations est The iPhone Wiki [WIKI].

1.3 Mécanismes de sécurité userland

De manière a empêcher la modification du système d'exploitation au niveau filesystem, Apple a choisi de séparer iOS en deux partitions : une partition « système » et une partition « utilisateur ».

La partition système contient le kernelcache (kernel et ses extensions), ainsi que l'ensemble des daemons, programmes et bibliothèques nécessaires à iOS. Elle est montée en lecture seule.

La partition utilisateur contient l'ensemble des applications (dont Safari et Mail), leurs préférences et données associées.

Cette première sécurité, alliée au fait que l'ensemble des applications sont lancées avec un utilisateur restreint mobile, permet de garantir le fait que le système ne pourra être altéré pour le débrider.

Chaque application est d'autre part exécutée dans un bac à sable distinct grâce à Mac OSX Seatbelt. Le répertoire « prison », unique à chaque application, accessible en lecture/écriture par celle-ci, contient l'ensemble de ses données et préférences. Safari, par exemple, y stocke ses signets et son cache. Une application ne peut accéder à aucun autre répertoire en dehors de cette prison, et grâce à cette spécificité, elle ne peut donc lire les données d'une autre ni les fichiers du système.

Ensuite, tout exécutable doit être signé par Apple, ou son lancement sera bloqué par le kernel qui vérifie les hashs SHA1 de chacune des pages mémoires qui ont été embarqués dans le binaire signé MachO. Le processus de validation des applications effectué par Apple, qui aboutira sur la signature de l'applicatif et sa mise à disposition sur l'AppStore, est d'ailleurs reconnu pour son sérieux et sa sévérité vis-à-vis de l'utilisation d'API privées et de comportements douteux. Un malware pourra être retiré rapidement de l'AppStore des suites de l'identification d'une faille.

Enfin, iOS intègre des mécanismes de prévention d'exécution de code arbitraire ou Data Execution Prevention (DEP) :

• le heap et la pile ne sont pas exécutables. Les pages mémoires sont marquées NX : No eXecute.
• les pages mémoires de code sont marquées W^X (Write Xor eXecute), si bien qu'elles ne sont pas modifiables au runtime.

L'écriture d'exploits userland nécessite donc des payloads de type return-to-libc ou ROP.

Se référer à l'article « Mémoire non exécutable : vers le Return Oriented Programming », paru dans MISC n°51, pour de plus amples informations sur ROP.

1.4 La chaîne de confiance

L'ensemble des mécanismes de sécurité mis en œuvre en userland par le kernel iOS n'aurait aucun intérêt s'il était possible d'intervenir sur le firmware inscrit par iTunes dans l'iPhone et changer le kernel pour une version dépourvue de ces contraintes.

Pour répondre à cette problématique, Apple a développé un système sécurisé de démarrage breveté nommé « SecureBoot ». L'objectif du système est de garantir que tous les éléments du bootloader au kernel sont authentiques. Chaque maillon exécuté au démarrage (que nous préciserons en section 2) est vérifié par son précédent : il doit être intègre et la signature apposée par le certificat d'Apple doit attester qu'il n'a pas été modifié. Un autre mécanisme (ECID, voir section 2.6) empêche l'utilisateur de pouvoir revenir à une version précédente d'iOS (downgrade) potentiellement vulnérable.

1.5 Difficulté du jailbreak userland

Malgré le SecureBoot protégeant le kernel d'une altération dans la mémoire de stockage de l'iPhone, un acteur de la « communauté jailbreak », nommé comex, a réussi la prouesse de débrider l'iPhone de manière persistante (untethered), et ce au runtime !

L'année 2010 a ainsi été riche en exploits userland et kerneland, qui ont permis le débridage des firmwares 3.1.2, 3.1.3, 3.2, 3.2.1 et 4.0.1.

La difficulté d'un tel exercice est de passer outre les protections DEP en userland, de trouver une escalade de privilèges pour accéder au kernel, et d'utiliser une vulnérabilité imputable à ce dernier pour pouvoir modifier son espace mémoire.

Ainsi, pour Spirit, 3 vulnérabilités différentes ont été utilisées :

• MobileBackup copy directory traversal : injection ;
• Incomplete codesign : exécution userland et untethered;
• BPF_STX kernel write : exécution kerneland.

Pour Star :

• Malformed CFF (CVE-2010-1797) : exécution userland.
• Incomplete codesign : exécution userland et untethered.
• IOSurface properties integer overflow (CVE-2010-2973) : exécution kerneland.

Se référer à l'article « L'iPhone OS et le jailbreak Spirit », paru dans MISC n°51, pour l'analyse complète du jailbreak Spirit et pour une explication de Star.

Apple a livré des versions d'iOS (3.2.1/4.0.1 puis 3.2.2/4.0.2) corrigeant les failles utilisées par comex environ 1 mois après leur divulgation.

Ce type de jailbreak nécessite donc une technicité élevée (escalade de privilèges, payloads de type ROP), un temps considérable pour sa réalisation, et est patché sans grande difficulté par Apple.

Existe-t-il une méthode plus simple pour réaliser un jailbreak ? Oui, et nous allons le voir tout se suite, il suffit d'intervenir plus tôt dans la chaîne de confiance.

1.6 Le maillon faible

Comme nous venons de le voir, le SecureBoot garantit que le noyau est authentique dans la NOR/NAND et qu'il contient donc les protections mises en œuvre par Apple.

Si en revanche, il était possible de passer à travers les mailles du filet et laisser penser au SecureBoot que le kernel est valide alors qu'il a été modifié pour en supprimer ses sécurités, la chaîne est rompue : le jailbreak est réalisé - des applications tierces peuvent être exécutées sans la signature d'Apple.

C'est cette méthode qu'appliquent les différents jailbreak fondés sur les exploits Pwnage (iPhone, iPhone 3G, iPod touch) et 24kpwn (iPod touch 2G, iPhone 3Gs).

Les avantages par rapport aux jailbreaks userland sont multiples :

• Ils détournent le SecureBoot en utilisant des vulnérabilités semi-matérielles non patchables par Apple.
• Ils sont naturellement persistants puisqu'ils interviennent lors du chargement des éléments depuis la NOR/NAND.
• Ils s'appliquent sur les maillons de la chaîne de démarrage d'iOS qui n'évoluent que très peu, pour des raisons évidentes de sécurité. La méthode de suppression des protections sur chaque élément jusqu'au kernel n'a donc quasiment pas évolué depuis 2008.
• DEP n'est pas actif avant le démarrage du noyau, facilitant grandement l'écriture des exploits

La section 3.4 présente 24kpwn, le dernier exploit public de type bootrom untethered.

1.7 Le vecteur d'injection

Les exploits bootland untethered survenant lors de la lecture NOR/NAND, ils nécessitent un vecteur d'injection, c'est-à-dire un moyen d'altérer la NOR/NAND pour les provoquer.

Voici des possibilités :

• Utiliser iTunes pour restaurer des firmwares « maison ». C'est exactement l'opération effectuée par PwnageTool.
• Utiliser un exploit dans le mode de restauration du firmware de l'iPhone (mode recovery, détaillé en section 2.3). Les outils purplera1n, blackra1n, redsn0w et greenpois0n déverrouillent le SecureBoot pour lui faire accepter un ramdisk personnalisé modifiant la NOR/NAND.

La 2ème a l'avantage d'être plus efficace, dans le sens où elle n'implique pas la mise à jour complète de l'OS : il s'agit seulement de « patcher » les éléments de la chaîne de démarrage et le noyau pour retirer leurs protections.

1.8 Le mélange des genres

En octobre 2010 est apparu un nouveau type de jailbreak mutant (outils limera1n et greenpois0n) :

• Les vecteurs d'injections sont des exploits bootrom tethered : limera1n et steaks4uce, découverts respectivement par geohot et pod2g.
• La persistance est assurée par un payload userland de comex utilisant deux vulnérabilités ; incomplete codesign (exécution userland et untethered) et /dev/pf invalid pointer dereference (CVE-2010-3830, exécution kerneland).

Ces failles bootrom DFU (voir section 2.4) permettent de limiter le nombre d'exploits userland nécessaires pour effectuer le jailbreak, et ont l'avantage d'être semi-matérielles, si bien que l'on peut s'appuyer sur elles pour la durée de vie d'une génération de terminaux.

Afin de comprendre comment ces exploits bootland ont été réalisés, nous allons présenter comment l'iPhone démarre et quels mécanismes sont employés par le SecureBoot pour vérifier les maillons de la chaîne de confiance.

2. Analyse du SecureBoot

2.1 Préliminaires

Lorsque l'iPhone démarre, le tout premier code ARM exécuté par le processeur est intégré dans le SoC applicatif, dans une mémoire non réinscriptible (ROM). Ce programme de très bas niveau est limité à 64 Ko, mais seuls 48 Ko sont actuellement utilisés pour la dernière révision (iBoot-574.4). Apple nomme ce programme la « SecureROM » :

L'objectif de ce code initial est de paramétrer le strict minimum de composants (CPU, MMU, bus, coprocesseurs, et NOR/NAND ou USB) pour déterminer le mode de démarrage, charger le programme de démarrage et l'exécuter.

Ce programme que la bootrom exécute, ainsi que chaque maillon du SecureBoot, est contenu dans un format de fichier IMG3 signé numériquement : ce « conteneur » est le fondement de la sécurité du chargement d'iOS. Nous le détaillons en section 2.5-2.6 et nous étudions en section 2.7 comment les contrôles de signature sont effectués.

La bootrom sait gérer 2 modes différents de démarrage : normal (NOR/NAND) et Device Firmware Upgrade (DFU). Le choix se fait selon un registre inscrit en ROM et les GPIO actifs :

• NOR : anciennes générations (iPhone 2G, iPod 1G, iPhone 3G, iPod 2G).
• NAND : pour les nouvelles générations, la NOR a été remplacée par une partition NAND dédiée au démarrage.
• DFU : si les boutons Power et Home sont activés suivant une procédure précise, la bootrom entre dans ce mode spécifique.

Quel que soit le mode, la bootrom ne dispose que d'un espace mémoire restreint pour charger le programme à démarrer : 0x24000 pour les anciennes générations, 0x2C000 pour l'A4. Cette limitation est à l'origine du démarrage en 3 phases d'iOS.

2.2 Démarrage normal

La figure 1 présente la chaîne de démarrage normal.

En mode normal, la bootrom copie le chargeur de démarrage de 2ème niveau depuis la partition de démarrage de la NOR/NAND dans une section de mémoire restreinte (de 0x24000 à 0x2C000 octets selon la génération), puis l'exécute. Ce programme est appelé Low Level Booter (LLB).

Le LLB initialise un nombre plus grand de composants, essentiellement les différentes horloges, les différents blocs de mémoire NAND, la mémoire physique et un paramétrage plus complet de la MMU afin de pouvoir charger des images programme de plus grande taille. Il charge et exécute l'image programme iBoot depuis la partition de démarrage.

L'iBoot charge deux images distinctes : le DeviceTree depuis la partition de démarrage, monte la partition système de la NAND, charge puis lance le kernel iOS depuis celle-ci.

Le kernel initialise et démarre l'ensemble des périphériques inclus à l'iPhone en utilisant le DeviceTree comme référence des registres d'entrée/sortie, monte les partitions iOS et démarre le système d'exploitation.

2.3 Démarrage recovery

La figure 2 présente la chaîne de démarrage recovery lors d'une mise à jour de firmware.

Une variante du démarrage normal est le mode recovery. Ce mode est utilisé par iTunes pour effectuer la mise à jour standard d'iOS.

Le mode recovery est initié par iTunes en modifiant la valeur de la variable d'environnement auto-boot à false, et en ordonnant le redémarrage (soft-reboot) de l'iPhone.

Lors de son chargement, l'iBoot inspecte la valeur de cette variable, et si elle est à la valeur false, un shell USB est démarré, en lieu et place de l'exécution du kernel iOS.

iTunes envoie ensuite un ramdisk (inclus dans la distribution du nouveau firmware au format IPSW) par USB, ainsi que le DeviceTree et le kernel. Le kernel démarre, monte le ramdisk et exécute le démon restored contenu dans le ramdisk, établissant une communication USB entre iTunes et l'iPhone et permettant le remplacement du firmware vers la version supérieure.

Le ramdisk est un filesystem au format HFS Extended. Il peut être créé/monté/modifié sous Mac OS X à l'aide de la commande hdiutil. Les outils xpwn de planetbeing [XPWN‑GIT] sont très utiles.

Deux ramdisks différents existent dans chaque distribution : restore et update. Les deux sont assez proches, la grande différence résidant dans le fait que le 2ème n'efface pas la partition utilisateur iOS, mais seulement les partitions de démarrage et système, si bien que toutes les données utilisateur (carnet d'adresses, messages, applications, musique, ...) sont conservées.

L'outil irecovery [LIBRECOVERY-GIT] de la Chronic Dev Team permet de communiquer avec l'iPhone en mode recovery : exécution de commandes shell et transfert d'images programme au format IMG3 vers l'iPhone.

2.4 Démarrage DFU

La figure 3 présente la chaîne de démarrage DFU lors d'une restauration de firmware.

Le mode DFU est le mode récupération de la bootrom. Activé via une procédure manuelle, il permet de réparer un iPhone dont la NOR/NAND a été corrompue, par exemple lorsqu'une mise à jour d'iOS a été interrompue avant sa finalisation. Grâce à cette fonctionnalité semi-matérielle (car incluse à la bootrom), l'iPhone n'est pas « brickable ».

Ainsi, la bootrom démarre une communication USB et attend que le chargeur de démarrage de 2ème niveau soit envoyé via USB par le Host, selon un protocole basique fondé sur des messages de contrôle.

iTunes transmet une première image nommée iBSS, qui n'est autre que l'équivalent DFU du LLB, mais qui au lieu de charger l'iBoot depuis la NOR/NAND initialise un shell recovery.

iTunes transmet une seconde image nommée iBEC, équivalent DFU de l'iBoot en mode recovery.

La suite est en tous points similaire à une restauration en mode recovery.

Pour les bidouilleurs : le protocole de transfert DFU est implémenté dans l'outil irecovery : il permet ainsi d'envoyer des images programmes au format IMG3 à la bootrom, tel que le fait iTunes.

2.5 Le format IMG3

C'est une structure binaire, composée d'un en-tête, puis de diverses sections.

À noter : les champs DWORD sont au format little‑endian, le CPU ARM de l'iPhone utilisant ce mode.

2.5.1 En-tête

 

Position	Titre	Commentaire
0x0	Signature du format de fichier	« img3 » ou « Img3 ». Si « img3 », l'image vient de la NOR/NAND. Si « Img3 », il s'agit d'une image DFU.
0x4	Taille totale de l'image/du fichier en octets
0x8	Taille totale de l'image, en-tête exclu, en octets	Idem que la taille totale, moins 0x14.
0xC	Offset de la section SHSH	Offset de la section SHSH (signature) en partant de l'offset 0x14.
0x10	Type d'image	« illb », « ibot », « ibss », « ibec », « dter », « krnl », etc.

2.5.2 Section

 

Position	Titre	Commentaire
0x0	Type de section	Exemple : « TYPE », « DATA », « SHSH », etc.
0x4	Taille totale de la section en octets
0x8	Taille totale de la section, en-tête exclu	Idem que la taille totale, moins 0xC.
...	Contenu de la section	...

2.5.3 Composition d'une image

Section	Contenu de la section
En-tête
« TYPE »	Type d'image, par exemple « illb », cette information est redondante avec celle présente dans l'en-tête. Certainement une raison historique. En mode DFU, le seul type autorisé est « ibss ». La SecureROM attend une image de type « illb » en mode NOR/NAND.
« DATA »	Les données réelles contenues dans l'image. Le code exécutable du LLB, par exemple.
« VERS »	Une chaîne de caractères identifiant la version de l'image. Exemple : iBoot-931.71.16. Cette version doit être inférieure ou égale à celle de l'image courante.
« SEPO »	Security Epoch
« BORD »	Matériel (board) compatible avec cette image. Est comparé par la SecureROM au registre matériel correspondant inscrit en ROM. Si une différence est identifiée, l'image ne sera pas exécutée.
« KBAG »	Clé et IV AES utilisés pour chiffrer le contenu de la section DATA, eux-mêmes chiffrés en AES avec la clé GID (unique à chaque modèle d'iPhone et inscrite dans le coprocesseur AES).
« ECID »	Exclusive Chip ID. Cette section n'apparaît pas dans les images du fichier IPSW. Elle est ajoutée dynamiquement par iTunes. Voir section 2.6 dédiée.
« SHSH »	Signature. Il s'agit du SHA1 chiffré du bloc de données commençant à l'offset 0xC de l'image (3ème DWORD de l'en-tête) jusqu'à la section SHSH (exclue). Le SHA1 est chiffré en RSA avec la clé privée (secrète) associée au 2ème certificat contenu dans la section CERT.
« CERT »	Contient la concaténation de 2 certificats (clés publiques) au format DER : Apple Secure Boot Certification Authority ; S5L89xx Secure Boot.

À noter aussi, une image IMG3 de taille restreinte (68 octets) est intégrée au 2ème certificat de la section CERT, composée de la façon suivante :

Section	Contenu de la section
« SMOD »	Security Domain
« PROD »	Production Mode
« CHIP »	Chip. SoC compatible. Est comparé par la SecureROM au registre matériel correspondant inscrit en ROM. Si une différence est identifiée, l'image ne sera pas exécutée.

2.6 Exclusive Chip ID

La notion d'ECID existe depuis les premières générations d'iPhone : il s'agit d'un identifiant de 64 bits unique à chaque terminal. L'information est stockée dans un registre matériel de la ROM.

Lors de la sortie de l'iPhone 3Gs, des différences sont apparues par rapport aux générations précédentes : il devient impossible de démarrer l'image DFU de l'iBSS trouvée dans le fichier IPSW à l'aide d'irecovery. La bootrom considère cette image invalide. Idem pour l'iBEC en mode recovery. Impossible aussi d'utiliser les logos présents dans le fichier IPSW pour les faire afficher à l'iBoot en mode recovery.

Pourtant, iTunes parvient à réaliser ces opérations !

Après différentes analyses des échanges réseau et USB opérés par iTunes lors de la restauration d'un firmware à l'iPhone 3Gs, il s'est avéré qu'iTunes demande à un serveur Apple un « blob » SHSH (sections SHSH et CERT) pour chaque image de boot du fichier IPSW. On appelle cette opération « requête TSS ». Il s'agit d'une simple requête HTTP dont la réponse est le contenu binaire du « blob ». Des images IMG3 enrichies d'une section ECID (d'où l'intérêt de la nouvelle signature) dont la valeur est identique à celle du terminal sont transférées par USB en lieu et place des images apparaissant dans le fichier IPSW.

Si l'on utilise ces images personnalisées, alors le terminal les accepte sans difficultés.

On peut en conclure plusieurs points :

• La bootrom, ainsi que l'iBoot (et toutes images de démarrage) contrôlent la présence de la section ECID dans l'image à exécuter, et vérifient que son contenu est identique à la valeur présente dans la ROM du terminal.
• Apple est libre de décider de délivrer ou non une signature, pour une image, une version et un ECID donné.

Cette opération permet aujourd'hui à Apple d'empêcher le downgrade vers un firmware débridé.

En revanche, Apple n'est pas allé au bout de la manœuvre car le protocole TSS est sensible aux attaques de type « replay ». L'utilitaire TinyUmbrella permet ainsi d'enregistrer localement la réponse du serveur d'Apple à la requête TSS et simuler plus tard le comportement du serveur pour autoriser le downgrade.

2.7 Validation IMG3

C'est sur cette validation qu'est fondée la chaîne de confiance du SecureBoot : dans le cas d'un démarrage normal, par exemple, la bootrom valide l'IMG3 LLB, qui valide l'IMG3 iBoot, qui valide les IMG3 DeviceTree et kernel.

La procédure de contrôle est strictement identique pour chaque booter : bootrom, LLB, iBoot, iBEC, iBSS partagent le même code pour réaliser cette opération.

En voici les étapes successives :

• L'en-tête est vérifié : la cohérence mathématique de chaque longueur et offset est contrôlée. Un point d'honneur est mis à éviter tout integer overflow.
• Les tailles des sections SHSH et CERT sont vérifiées, toujours dans l'optique d'éviter toute tentative d'overflow.
• Le SHA1 du bloc allant de l'offset 0xC à la section SHSH est calculé, en utilisant un coprocesseur accélérant cette opération.
• Si l'image est de type « img3 », elle vient de la NOR/NAND, la signature apposée par Apple et contenue dans la section SHSH a été personnalisée lors de l'étape de mise à jour du firmware. Cette personnalisation est réalisée en chiffrant en AES la signature avec la clé UID (unique à chaque iPhone). Cela permet de ne pas pouvoir intervertir la NOR/NAND avec un autre iPhone et que l'opération fonctionne, mais cela n'a plus d'intérêt depuis l'arrivée de la section ECID. La signature est donc éventuellement déchiffrée ici avant de poursuivre.
• La chaîne de validation des certificats contenus dans la section CERT est vérifiée : chaque certificat contient une signature (SHA1 des données du certificat chiffré avec la clé privée RSA du certificat parent). Le certificat racine de la chaîne de certification réside dans l'image actuellement exécutée (le programme exécutant ce processus de validation). Apple part donc du principe que si le maillon courant n'a pas été corrompu, le certificat racine qu'il contient n'est pas corrompu. Dans le cas spécifique de la SecureROM, le certificat racine résidant en ROM, il n'est pas « altérable »
• Le certificat « feuille » de cette chaîne de certification est utilisé pour déchiffrer le SHA1 de la section SHSH.
• Le SHA1 en clair est comparé avec le SHA1 calculé de l'image.
• Les sections SMOD, PROD, CHIP, TYPE, VERS, SEPO, BORD, ECID sont vérifiées.

Si tous ces contrôles sont passés, alors les données de l'image (section DATA) sont déchiffrées et le programme est exécuté.

2.8 Un processus éprouvé

Le SecureBoot est aujourd'hui un processus éprouvé et fiable. Fonctionnellement parlant, il est inviolable, à moins bien sûr de connaître les clés privées utilisées par Apple pour signer les images.

Cela n'a pas toujours été le cas : l'exploit Pwnage de l'iPhone Dev Team était un simple contournement de la chaîne de confiance : la SecureROM ne vérifiait pas le LLB lors de sa lecture depuis la NOR, alors que les mécanismes de contrôle existaient, puisque appliqués en mode DFU. Apple a certainement considéré à cette époque que si la NOR est compromise, c'est que la sécurité de l'iPhone est déjà compromise.

Ce raisonnement est toutefois incomplet car une faille de ce type permet un jailbreak untethered (persistant), l'exploit étant valable pour l'ensemble d'une génération matérielle de terminaux (dans le cas de Pwnage : iPhone 2G, iPhone 3G et iPod 1G sont vulnérables).

Depuis qu'Apple a appliqué des contre-mesures à Pwnage, il n'y a d'ailleurs plus aucun exemple d'exploit détournant ces protections de SecureBoot.

Cependant, et nous allons le voir, une protection n'est jamais infaillible, car si la porte d'entrée est blindée, il est toujours possible de passer par les fenêtres : l'exécution arbitraire de code reste accessible.

3. Failles SecureROM

3.1 Logique intégrée à la bootrom

La bootrom est mappée de manière matérielle par le SoC à son démarrage depuis son adresse physique réelle (dépend du SoC, A4: 0xBF000000) vers l'adresse 0x0, PC du processeur ARM au boot.

Voici la liste des actions réalisées par le programme SecureROM :

• Définition d'un ensemble de vecteurs d'exception du processeur ARM ;
• Définition d'une pile dédiée aux vecteurs d'exception (Exception handler stack) ;
• Définition d'une pile principale (Stack) ;
• Préparation de la zone mémoire BSS :
  • cette section contient l'ensemble des variables globales (statiques) du programme C de la bootrom,
  • les 0x160 (352) premiers octets de cette section contiennent des données pré-initialisées, qui sont copiées depuis le corps de la bootrom (A4: 0xA41C),
  • le reste de la section est vidé (memzero).
• Préparation de la zone mémoire Heap :
  • la zone est vidée (memzero),
  • les structures essentielles à malloc sont préparées dans le BSS.
• Initialisation du minimum vital de périphériques nécessaires
• Identification du mode de démarrage en fonction des GPIOs et de la configuration matérielle : NOR, NAND ou DFU.
• En mode DFU :
  • Initialisation du chipset USB,
  • Ajout d'un gestionnaire d'exception IRQ répondant aux paquets USB reçus. Un ensemble de messages de contrôle permettent au Host d'envoyer une image IMG3 au terminal, qui la copiera bloc par bloc vers le tampon Loadaddr,
  • Démarrage de la gestion matérielle USB,
  • Boucle d'attente CPU ne terminant qu'à la réception complète d'une image programme à exécuter.
• En mode NOR/NAND :
  • Lecture bloc à bloc de l'image IMG3 de type LLB depuis la partition de démarrage. Chaque bloc est copié un à un vers le tampon Loadaddr.
• Validation de l'authenticité de l'image IMG3 (voir paragraphe dédié 2.7) ;
• Déchiffrement de la section DATA de l'image ;
• Déplacement des données déchiffrées vers le début du tampon Loadaddr ;
• Préparation du SoC à l'exécution de l'image (arrêt de tous les périphériques, désactivation des caches, désactivation de la MMU, ...) ;
• Exécution de l'image par un simple saut ARM (BX) vers le début du tampon Loadaddr.

Apple est donc parvenu à intégrer une quantité importante de fonctionnalités dans un espace très restreint : une prouesse technique !

Nous avons maintenant synthétisé le comportement de la bootrom, mais cela est insuffisant pour comprendre comment les exploits 24kpwn et limera1n, par exemple, permettent l'exécution arbitraire de code. Il est indispensable d'avoir en tête une vue de la cartographie mémoire au runtime.

3.2 Carte mémoire de la bootrom

La figure 4 présente les plages d'adresses utilisées par la bootrom lors de son exécution (les adresses d'I/O sont exclues).

Aucune des pages mémoires n'est protégée via des mécanismes de DEP : toutes les zones en RAM sont inscriptibles, exécutables et à adresse fixe. Cela constitue une grande différence par rapport à la sécurité mise en œuvre en userland ! Nous pouvons imaginer que ce sont les contraintes de compacité du code et de complexité minimale qui ont forcé Apple à faire l'impasse sur ces protections...

Le BSS contient un ensemble de variables globales critiques, dont par exemple :

• les descripteurs USB ;
• les registres d'adresse du coprocesseur d'accélération SHA1 ;
• les structures de gestion du Heap nécessaires à malloc.

Le Heap contient tous les buffers alloués par un appel à malloc. À noter :

• l'algorithme utilisé semble être (ou en tout cas est très proche) de dlmalloc(Doug Lea Malloc) ;
• lors d'un malloc ou d'un free, le contenu du tampon n'est pas vidé.

Il est intéressant de constater que :

• le BSS suit le tampon Loadaddr. Un dépassement d'une image hors du tampon Loadaddr lors de sa copie pourrait modifier le contenu du BSS !
• les vecteurs d'exception sur l'architecture ARM sont à l'adresse 0x0. Cela constitue une faiblesse importante, car le déréférencement d'un pointeur NULL peut aboutir à la modification de cette zone critique. Dans le cas de la SecureROM, la criticité est moindre car il s'agit de ROM, mais cette faiblesse a déjà abouti à des exploits iBoot tels que usb_control_msg(0x21, 2).

Maintenant que nous connaissons la structure de la mémoire et les fonctions incluses dans la bootrom, il manque un dernier élément permettant de comprendre la démarche suivie par les développeurs indépendants pour identifier des vulnérabilités et les exploiter. En effet, aucun outil de debugging ne permet d'effectuer du pas à pas pour tracer l'exécution du programme sur un terminal de production, aucune trace n'est conservée et aucun message n'est présenté à l'utilisateur. La bootrom est totalement « muette ».

3.3 Des tests à l'aveugle

Voici les comportements connus de la bootrom :

• la bootrom démarre l'image à exécuter si celle-ci est authentifiée ;
  • en mode normal, et si la NOR/NAND n'est pas altérée, le LLB et l'iBoot sont chargés successivement, affichant une Pomme à l'écran,
  • en mode DFU, si un iBSS (personnalisé avec l'ECID du terminal !) est envoyé par USB en respectant le protocole, l'écran apparaît avec un fond blanc.
• si l'image est incorrecte, le mode DFU est démarré et le terminal apparaît comme un périphérique USB lorsqu'il est connecté à un ordinateur, décrit comme « Apple Mobile Device (DFU Mode) » ;
• en mode DFU, la bootrom doit être en mesure de répondre aux messages de contrôle USB envoyés par le Host ;
• les vecteurs d'exception relatifs à des erreurs de données ou d'instruction (Undefined Instruction, Data Abort, Prefetch Abort) appellent la fonction panic, effectuant unsoft reset du terminal et exécutant donc à nouveau la bootrom. Une boucle infinie de redémarrage est d'ailleurs possible !

Ces données permettent d'obtenir suffisamment d'indications (connaissant le fonctionnement exact de la bootrom) sur la nature de l'incident causé par une vulnérabilité.

Nous allons maintenant étudier comment 24kpwn permet sur les 2èmes générations de terminaux de passer outre la vérification de l'authentification d'une image IMG3.

3.4 L'exploit 24kpwn (mars 2009)

24kpwn est le dernier exploit bootrom untethered rendu public. Il a été fermé par Apple en septembre 2009 dans les SecureROM « iBoot-240.5.1 » et « iBoot‑359.3.2 », livrées dans des nouvelles versions de l'iPod 2G et l'iPhone 3Gs (nommées new bootrom). L'iPod 3G, commercialisé le 9 septembre 2009 (SecureROM iBoot‑359.5), est lui aussi corrigé.

L'histoire complète de l'identification de la vulnérabilité (pod2g), à son exploitation (planetbeing, pod2g) est expliquée dans l'iPhone Wiki : [24KPWN]. Nous allons toutefois résumer ici la démarche technique suivie.

Par analyse statique du code de la fonction de chargement, pod2g constate que la taille du LLB chargé depuis la NOR n'est pas limitée. Comme nous l'avons vu précédemment (paragraphe 3.2), si une copie d'image déborde du tampon Loadaddr, le BSS peut être modifié ! La seule vérification opérée est que la taille doit être un multiple de 64. La taille limite de 0x24000 était pourtant contrôlée en mode DFU. Il doit certainement s'agir d'un vestige de l'ère pré-Pwnage, où Apple considérait que les données en NOR étaient nécessairement authentifiées.

Or, il s'avère qu'un exploit tethered venait d'être identifié sur l'iPod 2G (arm7_go). Un bon vecteur de modification de la NOR, d'autant plus qu'une grande quantité de commandes de debugging avait été laissées par Apple dans le shell USB de l'iBoot 2.1.1, permettant très simplement à des terminaux de développement d'écrire des images et de modifier la structure de la NOR ! Un payload (0wnboot) a simplement été écrit pour faire croire à l'iBoot que le terminal de production était un terminal de développement, activant les fonctions de debugging.

Un scénario de test a été défini, permettant d'affirmer que le BSS était vraisemblablement modifié, entraînant soit un mode DFU cassé (les descripteurs USB présents au début du BSS ayant été altérés par l'overflow), soit une boucle infinie de redémarrage, à cause du déclenchement de la fonction panic.

La Chronic Dev Team explique que la plus grande difficulté ensuite a été de stabiliser cet overflow (en écrivant des données cohérentes) et d'identifier quelle variable du BSS utiliser pour exécuter du code arbitraire, et ce « à l'aveugle », en définissant différents scénarios de tests et en croisant les données.

L'aide de planetbeing, qui connaissait parfaitement la méthode utilisée par le terminal pour calculer le SHA1 de l'image, ayant écrit un booter open source (openiboot, lanceur d'iphonelinux et iDroid), a été déterminante.

Ainsi, la bootrom copie 64 octets par 64 octets les données dont elle calcule le SHA1 vers un registre d'adresses pointé par une variable globale présente au début du BSS. L'idée de l'exploit coule alors de source : utiliser une image spécialement créée, produisant un overflow sur le BSS, modifiant ce registre d'adresse pour le faire pointer vers la pile de la fonction réalisant le calcul SHA1. Avec un bon réglage de l'offset (déterminé par analyse statique), la fonction sha1_update_checksum modifie alors sa propre pile lors de la copie des 64 premiers octets de données signées de l'image (de 0xC à 0x4C) écrasant son adresse de retour d'appel (LR).

L'exécution arbitraire de code est réussie et le « bypass » de la vérification de l'image est réalisé très simplement en intégrant un payload ARM dans l'image non authentique, dont l'objectif est de retourner dans le processus normal de la bootrom, juste après l'étape de contrôle de l'image et avant son déchiffrement. Un simple « return-to-bootrom ».

Voici une version simplifiée du payload ARM intégré dans l'image non authentique à l'offset 0x23000 et exécuté en faisant pointer le LR de la fonction sha1_update_cheksum vers 0x22023000 (adresse du payload une fois copié dans le tampon Loadaddr sur un iPod 2G) :

Maintenant que nous connaissons un exemple d'exploit bootrom untethered, nous allons étudier un exploit tethered, car ils sont à la mode depuis septembre 2010 ! En l'espace d'un mois, 3 exploits différents ont été annoncés publiquement : steaks4uce, limera1n et SHAtter. Le code exploitant les deux premiers est open source (le code source de l'outil de jailbreak greenpois0n est ouvert : [GP‑GIT]. Le dernier exploit de pod2g n'a en revanche pas été rendu publique, dans l'optique de le conserver pour la sortie de la prochaine version de la bootrom, certainement à l'occasion de l'iPad 2G, annoncé pour le 1er trimestre 2011.

3.5 La vulnérabilité steaks4auce (septembre 2009)

Pod2g explique que pour identifier la vulnérabilité, un fuzzer USB maison a été écrit. Ce programme Linux (de source fermée) reprend la même routine d'initialisation DFU que l'outil irecovery, qui utilise la bibliothèque libusb. Ensuite, grâce à une cascade de boucle imbriquées, tous les paramètres possibles d'un message de contrôle USB allant du Host au terminal sont envoyés et les différentes réponses sont tracées.

Pour effectuer la procédure de fuzzing, le terminal a été placé en mode DFU (en attente d'une image IMG3 envoyée par le Host, en respectant le protocole USB standard de la bootrom) et le fuzzer est démarré.

Voici un pseudo-code permettant de réaliser le fuzzer :

Nous avons testé cette opération et nous confirmons qu'un iPod 2G redémarre (panic) lorsqu'il reçoit le message de contrôle de bmRequestType 0xA1 et de bRequest 0x1 !

Geohot a déclaré qu'une technique similaire est aussi à l'origine de la vulnérabilité limera1n.

3.6 De la vulnérabilité à l'exploit

En faisant varier wLength de 0x0 à 0x800 sur le message de contrôle A1-1, on se rend compte qu'il semble que le crash survient lorsque la taille dépasse 0x100. Il s'agit d'un overflow.

Pod2g fournit le code permettant d'exploiter le heap overflow dans l'article de l'iPhone Wiki : [STEAKS4AUCE].

On y apprend qu'un free du buffer suivant le tampon vulnérable est effectué par la bootrom à réception du message de contrôle USB. Il s'agit de la cause du panic survenu lors du fuzzing : free a constaté que ces structures étaient incohérentes.

L'exploit consiste tout simplement à réécrire les structures dlmalloc du buffer suivant le tampon vulnérable : free écrit alors, grâce à la technique d'exploitation « unlink », un DWORD FD arbitraire à une adresse BK tout aussi arbitraire ! En choisissant BK pour être l'adresse du LR de free dans la pile et FD pour être l'adresse d'un payload intégré à une image IMG3 copiée préalablement vers le tampon Loadaddr, nous avons une exécution de code arbitraire ! C'est exactement l'opération réalisée par greenpois0n pour exécuter une image iBSS non authentique sur les iPod 2G.

Pour plus d'informations au sujet de dlmalloc et des possibilités d'exploitation des heap overflows dans ce contexte, consultez l'article de Phrack n°57 « Vudo malloc tricks by MaXX » : [DLMALLOC].

Conclusion

Les protections mises en œuvre par Apple pour garantir l'authenticité du kernel iOS sont fortes, mais les développeurs indépendants ont rivalisé d'ingéniosité pour passer à travers les mailles du filet. Qu'il s'agisse d'exploits userland en ROP, d'exploits iBoot ou d'exploits matériels, aucune version d'iOS à ce jour n'a pu résister plus de quelques mois avant la livraison d'un jailbreak.

Il semblerait pourtant qu'une page soit en train de se tourner, car la méthodologie de correction appliquée par Apple est bonne : aucun ajout de fonctionnalité dans la chaîne de confiance, seulement des correctifs aux vulnérabilités publiques et suppression du code inutile.

Par exemple, la version 2.1.1 de l'iBoot avait un shell recovery disposant de 29 commandes, dont une grande partie liée à des opérations de manipulation de mémoire et d'I/O, inutiles à des terminaux de production. La dernière version en date, la 4.2.1, n'en inclut que 11, toutes essentielles à la mise à jour de firmware.

En continuant dans cette voie, et peut-être en appliquant quelques contre-mesures supplémentaires (DEP en bootland, ASLR en userland, et pourquoi pas un système semi-matériel bloquant le downgrade, tel que eFUSE dIBM), Apple détiendra certainement le système d'amorçage et mise à jour d'OS le plus sécurisé du marché : un atout commercial gigantesque, garantie d'un business protégé pour les développeurs d'applications de l'AppStore et pour les opérateurs de téléphonie.

Références

[WIKI] The iPhone Wiki, http://theiphonewiki.com/

[XPWN‑GIT] Le dépôt open source de xpwn, https://github.com/planetbeing/xpwn

[LIBRECOVERY-GIT] Le dépôt open source de libirecovery et irecovery, https://github.com/chronicdev/libirecovery

[24KPWN] Détails techniques sur 24kpwn, http://theiphonewiki.com/wiki/index.php?title=24kpwn

[GP‑GIT] Le dépôt open source de greenpois0n, https://github.com/Chronic-Dev/syringe

[STEAKS4AUCE] Détails techniques sur steaks4auce, http://theiphonewiki.com/wiki/index.php?title=Steaks4uce

[DLMALLOC] Phrack n°57 « Vudo malloc tricks by MaXX », http://www.phrack.org/issues.html?issue=57&id=8