Dirty dancing
Dirty Stream agite le Net depuis quelques jours. Il faut dire que cette « faille » fait les gros titres à coups de milliards de smartphones Android touchés. Suivant comment les applications sont programmées, elles peuvent se laisser berner par un pirate qui peut écraser des fichiers pour en prendre le contrôle. Inutile de paniquer pour autant, des correctifs sont déployés.
La semaine dernière, Microsoft a publié un billet de blog pour présenter Dirty Stream, présenté comme un « modèle de vulnérabilité courant dans les applications Android ». Les risques sont réels puisque cela peut aller jusqu’à l’exécution de code arbitraire et au vol de jetons d’identification, deux situations très dangereuses.
Avant de paniquer, un point important : Microsoft a prévenu les développeurs bien en avance afin de pouvoir corriger le tir. C’est notamment le cas des applications de gestionnaire de fichier de Xiaomi et WPS Office. Elles ont été mises à jour dès le mois de février, bien avant la publication de ce bulletin d’alerte. Microsoft s’est également rapproché de Google, qui a mis en ligne une page sur son site dédié aux développeurs Android (et une autre ici) afin de prévenir les développeurs et leur proposer des protections à mettre en place.
Content Provider : gare à l’implémentation
Mais de quoi s’agit-il exactement ? Microsoft commence par un rappel sur le fonctionnement du système d’exploitation : « Android impose l’isolation en attribuant à chaque application son propre espace dédié pour le stockage des données et la mémoire. Pour faciliter le partage des données et des fichiers, Android propose un composant appelé Content Provider, qui agit comme une interface pour gérer et exposer les données aux autres applications, de manière sécurisée ».
Utilisé correctement, le Content Provider est décrit par Microsoft comme « une solution fiable ». Mais, comme souvent, une implémentation « inappropriée peut introduire des vulnérabilités qui pourraient permettre de contourner les restrictions de lecture/écriture dans le répertoire personnel d’une application ».
On est donc face à un cas malheureusement assez classique où il faut distinguer le protocole ou la fonctionnalité de son implémentation (c’est-à-dire sa mise en œuvre de manière pratique) dans les applications. Comme on a pu le voir par le passé (ici, là et encore ici ou là… et ce n’est que la partie visible de l’iceberg), il peut y avoir une grande différence entre les deux.
On vous épargne le fonctionnement précis du Content Provider (détaillé ici par Google), mais il arrive que des applications « ne valident pas le contenu du fichier qu’elle reçoive et, ce qui est le plus inquiétant, utilisent le nom de fichier fourni » par l’application qui envoie les données. Ce fichier est alors stocké dans le répertoire de données interne de l’application ciblée. Voyez-vous venir le risque ?
Remplacer des fichiers par ceux des pirates
Avec des noms de fichier taillés sur mesure, l’application d’un pirate peut donc remplacer les fichiers clés de l’application cible et ainsi en prendre le contrôle. Dans tous les cas, l’impact varie en fonction des applications et de leur mise en œuvre.
« Par exemple, il est très courant que les applications Android lisent les paramètres de leur serveur à partir du répertoire shared_prefs. Dans de tels cas, l’application malveillante peut écraser ces paramètres, ce qui l’oblige à communiquer avec un serveur contrôlé par l’attaquant et à envoyer les jetons d’identification de l’utilisateur ou d’autres informations sensibles », explique Microsoft. Ce serait un peu comme si une application pouvait venir remplacer n’importe quel fichier sur votre ordinateur…
Microsoft en ajoute une couche : « Dans le pire des cas (et ce n’est pas si rare), l’application vulnérable peut charger des bibliothèques natives à partir de son répertoire de données dédié (par opposition au répertoire /data/app-lib, plus sécurisé, où les bibliothèques sont protégées contre toute modification). Dans ce cas, l’application malveillante peut écraser une bibliothèque avec du code malveillant, qui est alors exécuté lors du chargement ».
Dans le cas du gestionnaire de fichier de Xiaomi, cette technique a permis d’exécuter du code « arbitraire avec l’ID utilisateur et les autorisations du gestionnaire de fichiers ». On vous laisse imaginer le boulevard que cela ouvre au pirate, qui peut ainsi contrôler l’application et accéder à l’ensemble des fichiers ou presque.
Google confirme et donne des « astuces »
Google confirme les risques sur cette page : « Si un pirate informatique parvient à écraser les fichiers d’une application, cela peut entraîner l’exécution de code malveillant (en écrasant le code de l’application) ou sinon, permettre la modification du comportement de l’application (par exemple, en écrasant les préférences partagées de l’application ou d’autres fichiers de configuration) ».
Au-delà des applications mises à jour, d’autres peuvent encore être vulnérables. Microsoft et Google proposent donc des méthodes pour éviter de tomber dans ce piège.
« La solution la plus sûre consiste à ignorer complètement le nom renvoyé par l’application lors de la mise en cache du contenu. Certaines des approches les plus robustes que nous avons rencontrées utilisent des noms générés aléatoirement, de sorte que, même dans le cas où le contenu d’un flux entrant est mal formé, il n’altère pas l’application ». Une autre solution serait d’enregistrer les fichiers dans un répertoire dédié.
Mille milliards de mille sabords
Terminons avec un mot sur l’emballement autour de cette affaire. On entend souvent parler de milliards de terminaux affectés, ce n’est pas aussi simple. Microsoft explique avoir « identifié plusieurs applications vulnérables dans le Google Play Store qui représentaient plus de quatre milliards d’installations ». Quatre milliards d’installations (dont plus d’un milliard pour la seule application de Xiaomi) ne signifie pas que quatre milliards de smartphones sont touchés, loin de là.
La question est aussi de savoir si on doit parler d‘une mauvaise gestion des données du côté des développeurs qui laissent des données de leur application se faire écraser par des fichiers externes, ou bien d’une faille d’Android qui laisse ce genre d’action passer, peu importe ce qu’en disent les applications.