Une faille de sécurité liée à XML permettait à une app de sortir du bac à sable d’iOS

Nicolas Furno |

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 ».

Ces quelques lignes de code permettaient à une app de sortir de la sandbox.

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.

En utilisant des commentaires « mal » écrits, mais considérés comme valides, le chercheur en sécurité à réussi à contourner l’une des protections en place dans iOS.

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.

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.


avatar Tao | 

Pour ceux qui voudraient se lancer dans la prononciation du document, le p- est muet, prononcez sychic paper

avatar Baptiste_nv18 | 

@Tao

plist -> property list

avatar Tao | 

@Baptiste_nv18

Ça change pas prononciation de psychic

avatar Baptiste_nv18 | 

@Tao

Je n’ai pas dit le contraire 🤷🏻‍♂️🤷🏻‍♂️

avatar Valiran | 

Se prononce "List" ou "Roperty list" :p

avatar iBaby | 

iOS 13.5 est de sortie ?

avatar Florent Morin | 

@iBaby

Il reste pour le moment confiné en beta.

avatar iCHrome | 

@FloMo

Donc elle sort lundi 🤣

avatar victoireviclaux | 

@iCHrome
Je pense que oui :)

avatar damienjdc | 

C'est le genre de bug que je trouve presque "élégant". Et chapeau au découvreur.

Simultanément (non je ne dirai pas en même temps) je pense que les codes sont de plus en plus spaghetti et de moins en moins rigoureux, et pour poursuivre la métaphore italienne deviennent d'indigestes lasagnes...

avatar B. Bro | 

@damienjdc si ça peut te rassurer. Enfin sans vouloir te contrarier, ça fait 15 ans que je code un peu et que je parle pas mal avec des développeurs et j’ai toujours entendu « avant on codait mieux », « les mecs maintenant ils codent avec les pieds », « l’assembleur il y a que ça de vrai... ». Je crois que ce genre de rengaine appartient au même marronnier que « aaahhh les jeunes, c’est pas comme nous, on était plus sérieux... ».

J’invite ces même personnes à coder le moteur 3D d’unreal engine, pour voir si savoir coder ça fout le camps...

avatar cybercooll | 

@B. Bro

Les développeurs d’aujourd’hui sont différents. Ils maîtrisent beaucoup plus de technologies qu’avant, donc forcément il les maîtrisent moins bien. Un bon dev d’appli web java maîtrise en général java JavaScript css xml xsd sql http un minimum de système pour utiliser docker, un peu de sécurité pour configurer nginx/apache et obtenir son certif ssl et tout un paquet d’outils indispensables (gradle, un IDE, git, ...).
Il s’amuse pas à parser de l’xml à la main, il utilise une librairie. Qui a plus ou moins de failles et qui n’est pas forcément à jour. Mais qui en aura moins que du code maison. Parce que le dev de la librairie maîtrise mieux son unique sujet. Ce sont 2 types de dev différents, il est difficile de les comparer.

avatar victoireviclaux | 

@B. Bro

🤣👍

avatar DrStax | 

J’imagine quand même la satisfaction énorme de ces White Hat quand ils trouvent une faille.

avatar ElFitz | 

C'est amusant. Je me serai attendu à ce que ces droits nécessitent systématiquement une signature avec une clé spécifique à Apple 🤷‍♂️

C'est toujours surprenant d'avoir un aperçu du fonctionnement de ces systèmes et de ces mécanismes. Ils sont souvent moins... avancés qu'on ne pourrait s'y attendre.

avatar FaBapple | 

Si cette faille a été utilisée, il est aisé pour Apple de le savoir : des apps avec cette syntaxe ont étés soumises et acceptées par son store, donc sont présentes dans ses archives. Aurons nous une communication sur le sujet ? 😇

avatar geooooooooffrey | 

L'expert en sécurité informatique à parlé.

avatar byte_order | 

En fait, je suis plus surpris que le processus de validation des AppStore ne vérifie pas automatiquement qu'il n'y a pas com.apple.private.security.no-container ni platform-application, dans la plist d'une app d'un tiers soumisse à validation.
Une simple recherche purement textuel le détecterait automatiquement, ce qui activerait une suspicion légitime sur les intentions cachées du dev de l'app, c'est ballot.

P'tet qu'ils le font, mais avec un parser XML... qui ne voit pas la partie qu'il considère comme être dans un commentaire.

Après, utiliser un format à la syntaxe complexe comme XML, c'est toujours plus dangereux en terme de sécurité qu'un format à la syntaxe beaucoup plus simple.

Question de surface d'attaque plus importante liée à la complexité.

Je serais curieux de savoir combien d'apps sur l'AppStore ont exploité cette faille zero day, présente depuis au moins 3 ans mais probablement bien plus encore.
Mais j'imagine aisément qu'Apple ne le dira pas.

CONNEXION UTILISATEUR