Apple a corrigé avec iOS 13.5 une faille de sécurité détaillée par le chercheur en sécurité qui l’a découverte et qui l’a surnommée « Psychic Paper » en référence à Doctor Who. La correction n’est pas encore complètement disponible, puisque cette version est toujours en bêta, mais iOS 13.4 l’avait déjà comblée en majorité, si bien qu’elle ne peut plus être exploitée. Cette faille était assez importante néanmoins, puisqu’elle permettait de sortir de la sandbox (bac à sable), cet espace de travail réservé à une app qui est normalement une barrière infranchissable.

En exploitant un bug dans iOS, une app distribuée sur l’App Store pouvait se faire passer pour une app native conçue par Apple et obtenir un accès complet à tous les fichiers stockés sur un iPhone ou un iPad. Ce bug est lié à une particularité d’iOS, qui est un héritage de macOS : tous les paramètres des apps sont stockés dans des fichiers plist qui sont codés en XML, littéralement « langage de balisage extensible ».

Ce standard créé à la fin des années 1990 est très pratique, entre autres choses, pour stocker des informations sous la forme d’une clé et d’une valeur. Dans le fichier plist d’une app, on trouvera notamment une clé « name » avec le nom de l’app comme valeur, et une autre « version » avec son numéro de version. C’est aussi dans ce fichier que les permissions de l’app sont consignées par son développeur. Si elle doit accéder à l’appareil photo d’un iPhone, elle doit le renseigner dans ce fichier.

Les apps d’Apple utilisent ce même système, mais elles ont des droits supplémentaires qu’elles sont les seules à pouvoir exploiter. En théorie, iOS doit bloquer une app de l’App Store qui essaie de les utiliser, mais il faut savoir que le XML est un langage très complexe à analyser.

Il offre beaucoup de souplesse et il est en général possible d’utiliser plusieurs notations différentes qui sont toutes considérées valides, même si elles ne respectent pas strictement les règles. Cette liberté a un prix : déchiffrer un fichier XML nécessite de gérer tous les cas de figure, avec le risque de laisser une brèche si ce n’est pas le cas. Dans cet exemple, Apple n’avait pas prévu qu’un commentaire puisse être volontairement mal écrit pour duper le système.

C’est exactement ce qu’a fait ce chercheur en sécurité. En insérant volontairement une erreur dans la balise qui sert à insérer des commentaires, il a réussi à générer un fichier XML qui reste valide et qu’iOS accepte volontiers, mais qui n’était pas toujours analysé correctement. Normalement, ce qui se trouve à l’intérieur du commentaire est systématiquement ignoré. Dans certains cas toutefois, iOS se faisait tromper par l’erreur dans la balise des commentaires, conduisant à lire et exécuter ce qui se trouvait à l’intérieur.

Pour comprendre, il faut ajouter qu’il n’y a pas une seule instance dans iOS qui se charge de vérifier les autorisations des apps, il y a plusieurs modules qui ont tous des mécanismes de vérification différents. Ainsi, même si lors de l’installation de l’app, iOS ne se fait pas avoir par le commentaire mal écrit, un autre processus en arrière-plan pouvait par la suite être moins strict et accorder à l’app des autorisations étendues.

RIP my very first 0day and absolute best sandbox escape ever:

application-identifier
...

platform-application

com .apple.private.security.no-container

task_for_pid-allow

— Siguza (@s1guza) April 29, 2020

Le correctif apporté par Apple consiste précisément à s’assurer que tous les processus de vérification sont sur la même longueur d’onde. Si l’un d’eux obtient un résultat différent de l’autre, iOS remonte désormais une erreur plutôt que d’exécuter le code, ou en l’occurrence d’accorder à tort des autorisations.

Si le sujet vous intéresse, l’article qui détaille la faille de sécurité est suffisamment simple pour être suivi même si vous n’êtes pas chercheur en sécurité ou développeur.