Sécurité : iOS a pris une grosse avance sur Android
C'est du moins la conclusion que l'on peut légitimement tirer de l'atelier consacré au sujet qu'ont animé Charlie Miller et Dino Dai Zovi à l'occasion de la conférence RSA qui se déroulait la semaine dernière à San Francisco. Pour faire court, simple et efficace : il faut au moins quatre à cinq "exploits" logiciels pour réussir à installer un rootkit persistant sur iOS contre seulement deux, voire même un seul de très belle facture, pour Android. Non seulement iOS a considérablement progressé depuis son lancement initial en 2007, mais il s'offre aujourd'hui le luxe d'intégrer des dispositifs de sécurité rares.
Indice du succès d'iOS et de son importance dans l'écosystème informatique actuel, l'atelier de Charlie Miller et de Dino Dai Zovi sur la sécurité du système d'exploitation embarqué d'Apple a fait salle comble. La queue pour entrer dans la salle capable d'accueillir environ 350 personnes, sur le mode « premier arrivé, premier servi », sans réservation, s'étendait sur plusieurs dizaines de mètres dans les travées du vaste centre de conférence de la ville, le Moscone Center. Dino Dai Zovi n'a pu s'empêcher de le relever : l'an passé, son atelier consacré à iOS n'avait attiré qu'une dizaine de personnes, dont deux journalistes…
L'objet de l'atelier de cette année ? Ce qu'il faut pour installer un rootkit persistant sur un terminal iOS, c'est-à-dire un logiciel disposant des privilèges les plus élevés sur le système de fichiers interne au terminal et qui continue de fonctionner même après redémarrage de l'appareil. Pourquoi est-ce intéressant ? Notamment parce que cela correspond ni plus ni moins à un jailbreak dit untethered.
Les co-auteurs du Manuel du pirate d'iOS, qui doit sortir au mois d'avril aux États-Unis, ont détaillé, lors de leur atelier, les dispositifs de sécurité dont dispose désormais iOS. L'inventaire est impressionnant, tout autant que l'évolution. Pour Charlie Miller, le système d'exploitation mobile d'Apple est clairement de plus en plus sécurisé : il y a encore quelques années, il aurait pu prendre le contrôle d'un iPhone… « en dormant », ironise-t-il en revenant sur ses exploits passés. Mais aujourd'hui, l'histoire est bien différente.
Que faut-il donc pour installer, sur un iPhone par exemple, un rootkit persistant ? Le point de départ, c'est l'injection de données malicieuses visant à exploiter une vulnérabilité permettant de corrompre la mémoire et d'exécuter du code logiciel dont l'exécution est théoriquement interdite par les mécanismes de protection d'iOS. On contourne ainsi le contrôle de signature du code. Toutefois, le code exécuté reste bloqué dans le « bac à sable » et ne peut donc accéder qu'à des ressources limitées. Il faut alors sortir du bac à sable pour réussir à exploiter une vulnérabilité afin d'accéder à des niveaux de privilèges plus élevés. Ceci fait, il faut exploiter une nouvelle vulnérabilité d'accès au noyau pour en exploiter… une vulnérabilité.
Charlie Miller l'explique, presque admiratif : « même lorsque vous exécutez un processus en tant que root (le niveau le plus élevé de privilèges, NDLR), vous n'avez pas accès au noyau ! C'est pour ainsi dire unique à iOS. » Ce n'est qu'une fois arrivé à utiliser une vulnérabilité du noyau qu'il devient possible de procéder à jailbreak temporaire — qu'il faudra encore réussir à pérenniser.
Alors, certes, en termes de sécurité, il est possible de commencer à dérober des données avant ce stade, et même dès que l'on est capable d'exécuter du code en contournant le contrôle de signature du code. Mais cela est limité à ce qui est accessible directement depuis le bac à sable, et cela représente « de moins en moins de choses. » Pour pérenniser le jailbreak, un autre exploit est nécessaire, qui doit permettre « de s'immiscer dans le noyau au démarrage », explique Miller. Bref, pour lui, il faut compter un minimum de quatre à cinq exploits pour réussir un jailbreak ne disparaissant pas au redémarrage — « c'est beaucoup plus facile sur Android », ajoute-t-il.
L'architecture de sécurité d'iOS s'apparente pour lui à un système de défense en profondeur. Tout d'abord, le système d'exploitation a été dépouillé de nombreuses choses, réduisant d'autant la surface d'attaque : « pas de Flash, pas de Java… même MobileSafari n'est pas capable de présenter certains types de fichiers. » Certains PDF ne sont pas supportés par iOS, ou plutôt certaines de leurs fonctions : « il y a plus de 200 moyens de faire planter le rendu PDF sur OS X. Sur iOS, seulement 7 % de ces cas fonctionnent. […] Il y a moins de code à attaquer, donc moins de bugs. » Et puis iOS fait l'impasse sur pas mal d'outils « utiles » aux hackers, comme le shell.
La plupart des processus « s'exécutent avec l'utilisateur mobile et non pas root », le premier devant se contenter de droits restreints. Plus fort encore : « certaines applications ont des permissions spécifiques, définies dans un profil de provisioning signé par Apple. Ce n'est pas parfait, mais c'est comme ça. » En clair : certains éléments logiciels d'iOS vérifient, au moment d'être sollicités par une application, que celle-ci a bien le droit de les solliciter. Ainsi, « bien que deux processus fonctionnent avec l'utilisateur mobile, tous les deux n'auront pas le droit de faire les mêmes choses. »
De plus, iOS intègre des types de contrôle de la signature du code : un premier au lancement et un second… durant l'exécution - quelque chose « d'assez unique », relève Miller. Le but ? Permettre à Apple de s'assurer que les applications exécutées sont bien celles qui ont été approuvées, et qu'elles n'ont pas été modifiées en cours de route par un téléchargement, voulu par l'éditeur ou malicieux. L'inventaire continue : pas de mémoire exécutable, ce qui signifie que « l'on ne peut pas injecter du code dans la mémoire et le faire tourner. » Petite subtilité : MobileSafari dispose d'un privilège exclusif, celui de pouvoir signer dynamiquement du code, indispensable à la compilation JavaScript à la volée.
Et il faut encore compter la randomisation de l'allocation de la mémoire, très étendue puisqu'elle concerne le code exécutable, les librairies, la pile, etc. Et puis vient le sandboxing, l'emprisonnement du code le plus vulnérable (ou compromis) potentiellement — celui des applications — dans des bacs à sable où ils ne peuvent accéder qu'à peu de choses. Les applications n'ont grosso modo accès qu'à leur dossier, qui doit contenir leur cache, leurs fichiers temporaires, leurs préférences, etc.
Au final, pour Charlie Miller et Dino Dai Zovi, face à ces mesures de protection, les « développeurs de jailbreak sont très intelligents. » Comex ? « Sans aucun doute, il vient du futur […] il est la preuve vivante de l'existence de la machine à voyager dans le temps. » Leur estime pour les auteurs de jailbreak est telle qu'ils s'interrogent sur les raisons qui les ont poussés à lancer, en 2010, la version 2 du site jailbreakme.com : « c'était trois à six mois de boulot. Ils étaient bien conscients que ce serait patché en deux semaines. Je ne pensais pas qu'ils ouvriraient le site. »
Si, du point de vue de la sécurité des utilisateurs d'iPhone, les efforts considérables d'Apple peuvent paraître positifs, les deux spécialistes n'en sont pas moins critiques. Pour eux, de nombreux gains de sécurité d'iOS sont d'abord « les effets secondaires de la volonté de contrôle d'Apple […] C'est un peu comme lorsque l'on vit dans un État policier, il y a moins de criminalité, mais ce n'est qu'un effet secondaire. »
Indice du succès d'iOS et de son importance dans l'écosystème informatique actuel, l'atelier de Charlie Miller et de Dino Dai Zovi sur la sécurité du système d'exploitation embarqué d'Apple a fait salle comble. La queue pour entrer dans la salle capable d'accueillir environ 350 personnes, sur le mode « premier arrivé, premier servi », sans réservation, s'étendait sur plusieurs dizaines de mètres dans les travées du vaste centre de conférence de la ville, le Moscone Center. Dino Dai Zovi n'a pu s'empêcher de le relever : l'an passé, son atelier consacré à iOS n'avait attiré qu'une dizaine de personnes, dont deux journalistes…
L'objet de l'atelier de cette année ? Ce qu'il faut pour installer un rootkit persistant sur un terminal iOS, c'est-à-dire un logiciel disposant des privilèges les plus élevés sur le système de fichiers interne au terminal et qui continue de fonctionner même après redémarrage de l'appareil. Pourquoi est-ce intéressant ? Notamment parce que cela correspond ni plus ni moins à un jailbreak dit untethered.
Les co-auteurs du Manuel du pirate d'iOS, qui doit sortir au mois d'avril aux États-Unis, ont détaillé, lors de leur atelier, les dispositifs de sécurité dont dispose désormais iOS. L'inventaire est impressionnant, tout autant que l'évolution. Pour Charlie Miller, le système d'exploitation mobile d'Apple est clairement de plus en plus sécurisé : il y a encore quelques années, il aurait pu prendre le contrôle d'un iPhone… « en dormant », ironise-t-il en revenant sur ses exploits passés. Mais aujourd'hui, l'histoire est bien différente.
Que faut-il donc pour installer, sur un iPhone par exemple, un rootkit persistant ? Le point de départ, c'est l'injection de données malicieuses visant à exploiter une vulnérabilité permettant de corrompre la mémoire et d'exécuter du code logiciel dont l'exécution est théoriquement interdite par les mécanismes de protection d'iOS. On contourne ainsi le contrôle de signature du code. Toutefois, le code exécuté reste bloqué dans le « bac à sable » et ne peut donc accéder qu'à des ressources limitées. Il faut alors sortir du bac à sable pour réussir à exploiter une vulnérabilité afin d'accéder à des niveaux de privilèges plus élevés. Ceci fait, il faut exploiter une nouvelle vulnérabilité d'accès au noyau pour en exploiter… une vulnérabilité.
Charlie Miller l'explique, presque admiratif : « même lorsque vous exécutez un processus en tant que root (le niveau le plus élevé de privilèges, NDLR), vous n'avez pas accès au noyau ! C'est pour ainsi dire unique à iOS. » Ce n'est qu'une fois arrivé à utiliser une vulnérabilité du noyau qu'il devient possible de procéder à jailbreak temporaire — qu'il faudra encore réussir à pérenniser.
Alors, certes, en termes de sécurité, il est possible de commencer à dérober des données avant ce stade, et même dès que l'on est capable d'exécuter du code en contournant le contrôle de signature du code. Mais cela est limité à ce qui est accessible directement depuis le bac à sable, et cela représente « de moins en moins de choses. » Pour pérenniser le jailbreak, un autre exploit est nécessaire, qui doit permettre « de s'immiscer dans le noyau au démarrage », explique Miller. Bref, pour lui, il faut compter un minimum de quatre à cinq exploits pour réussir un jailbreak ne disparaissant pas au redémarrage — « c'est beaucoup plus facile sur Android », ajoute-t-il.
L'architecture de sécurité d'iOS s'apparente pour lui à un système de défense en profondeur. Tout d'abord, le système d'exploitation a été dépouillé de nombreuses choses, réduisant d'autant la surface d'attaque : « pas de Flash, pas de Java… même MobileSafari n'est pas capable de présenter certains types de fichiers. » Certains PDF ne sont pas supportés par iOS, ou plutôt certaines de leurs fonctions : « il y a plus de 200 moyens de faire planter le rendu PDF sur OS X. Sur iOS, seulement 7 % de ces cas fonctionnent. […] Il y a moins de code à attaquer, donc moins de bugs. » Et puis iOS fait l'impasse sur pas mal d'outils « utiles » aux hackers, comme le shell.
La plupart des processus « s'exécutent avec l'utilisateur mobile et non pas root », le premier devant se contenter de droits restreints. Plus fort encore : « certaines applications ont des permissions spécifiques, définies dans un profil de provisioning signé par Apple. Ce n'est pas parfait, mais c'est comme ça. » En clair : certains éléments logiciels d'iOS vérifient, au moment d'être sollicités par une application, que celle-ci a bien le droit de les solliciter. Ainsi, « bien que deux processus fonctionnent avec l'utilisateur mobile, tous les deux n'auront pas le droit de faire les mêmes choses. »
De plus, iOS intègre des types de contrôle de la signature du code : un premier au lancement et un second… durant l'exécution - quelque chose « d'assez unique », relève Miller. Le but ? Permettre à Apple de s'assurer que les applications exécutées sont bien celles qui ont été approuvées, et qu'elles n'ont pas été modifiées en cours de route par un téléchargement, voulu par l'éditeur ou malicieux. L'inventaire continue : pas de mémoire exécutable, ce qui signifie que « l'on ne peut pas injecter du code dans la mémoire et le faire tourner. » Petite subtilité : MobileSafari dispose d'un privilège exclusif, celui de pouvoir signer dynamiquement du code, indispensable à la compilation JavaScript à la volée.
Et il faut encore compter la randomisation de l'allocation de la mémoire, très étendue puisqu'elle concerne le code exécutable, les librairies, la pile, etc. Et puis vient le sandboxing, l'emprisonnement du code le plus vulnérable (ou compromis) potentiellement — celui des applications — dans des bacs à sable où ils ne peuvent accéder qu'à peu de choses. Les applications n'ont grosso modo accès qu'à leur dossier, qui doit contenir leur cache, leurs fichiers temporaires, leurs préférences, etc.
Au final, pour Charlie Miller et Dino Dai Zovi, face à ces mesures de protection, les « développeurs de jailbreak sont très intelligents. » Comex ? « Sans aucun doute, il vient du futur […] il est la preuve vivante de l'existence de la machine à voyager dans le temps. » Leur estime pour les auteurs de jailbreak est telle qu'ils s'interrogent sur les raisons qui les ont poussés à lancer, en 2010, la version 2 du site jailbreakme.com : « c'était trois à six mois de boulot. Ils étaient bien conscients que ce serait patché en deux semaines. Je ne pensais pas qu'ils ouvriraient le site. »
Si, du point de vue de la sécurité des utilisateurs d'iPhone, les efforts considérables d'Apple peuvent paraître positifs, les deux spécialistes n'en sont pas moins critiques. Pour eux, de nombreux gains de sécurité d'iOS sont d'abord « les effets secondaires de la volonté de contrôle d'Apple […] C'est un peu comme lorsque l'on vit dans un État policier, il y a moins de criminalité, mais ce n'est qu'un effet secondaire. »
Pages