Stagefright: l'exploit qui a changé Android

L'un des points forts d'Android réside principalement dans sa nature open source, qui permet aux parties prenantes de créer, modifier et redistribuer le système d'exploitation d'une manière adaptée à leurs besoins particuliers. Mais cet avantage même d’être open source agit comme une arme à double tranchant lorsqu’il s’agit de problèmes de logiciels malveillants et de sécurité. Il est plus facile de trouver et de corriger les failles lorsque vous disposez de nombreux contributeurs compétents sur un projet dont le code source est disponible gratuitement. Cependant, résoudre le problème au niveau de la source ne signifie pas souvent que le problème soit résolu entre les mains du consommateur final. En tant que tel, Android n’est pas le premier choix lorsqu’il s’agit de choisir un système d’exploitation pour les besoins des entreprises sensibles aux données.

Lors du Google I/O 2014, Google a donné son premier pas vers un écosystème plus sécurisé et plus convivial pour les entreprises avec le lancement de Programme Android pour le travail. Android For Work a adopté une approche à double profil pour les besoins de l'entreprise, grâce à laquelle les administrateurs informatiques peuvent créer un profils d'utilisateurs distincts pour les employés - un axé sur le travail, laissant les autres profils pour le personnel des employés utiliser. Grâce à l'utilisation d'un cryptage matériel et de politiques gérées par l'administrateur, les données professionnelles et personnelles sont restées distinctes et sécurisées. Par la suite, Android For Work a reçu davantage d'attention au cours des derniers mois, l'accent étant mis sur la sécurité de l'appareil contre les logiciels malveillants. Google prévoyait également de activer le cryptage complet de tous les appareils qui devaient être publiés avec Android Lollipop prêt à l'emploi, mais cela a été abandonné en raison de problèmes de performances, cette décision étant rendue facultative pour la mise en œuvre par les OEM.

La promotion d’un Android sécurisé n’est pas entièrement l’œuvre de Google, car Samsung a joué un rôle assez important à cet égard via son Contributions de KNOX à l'AOSP, ce qui finalement Android For Work renforcé. Cependant, les récents exploits de sécurité et vulnérabilités d'Android indiquent une tâche ardue en matière de popularité pour l'adoption par les entreprises. La récente vulnérabilité Stagefright en est un bon exemple.

Contenu:

• Qu’est-ce que Stagefright ?
• À quel point Stagefright est-il sérieux ?
• Qu’est-ce qui différencie Stagefright des autres « vulnérabilités massives » ?
• Le dilemme de la mise à jour
• Android, post-Stagefright
• Notes de clôture

Qu’est-ce que Stagefright?

En termes simples, Stagefright est un exploit qui utilise la bibliothèque de codes pour la lecture multimédia sous Android appelée libstagefright. Le moteur libstagefright est utilisé pour exécuter du code reçu sous la forme d'une vidéo malveillante via MMS, nécessitant ainsi uniquement le numéro de portable de la victime pour mener à bien une attaque.

Nous avons contacté notre expert interne, XDA Senior Recognized Developer et Developer Admin pulseur_g2 pour fournir une explication plus détaillée.

"Au moment où j'écris ceci, l'exploit [Stagefright] devait être expliqué à BlackHat [Lien], bien qu'il n'y ait pas encore de détails sur les diapositives ou les livres blancs.

Je donne donc cette explication davantage comme une idée approximative de ce qui se passe, plutôt que comme une explication très approfondie avec une précision totale, etc.

Il existe un certain nombre de bugs différents qui composent Stagefright, et ceux-ci ont leur propre CVE [Vulnérabilités et expositions courantes] numéros de suivi :

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Malheureusement, les correctifs disponibles ne sont pas directement liés à chaque CVE (comme ils devraient l'être), ce sera donc un peu compliqué à expliquer.

1. [CVE-2015-1538]

Dans le code de gestion MPEG4, le code de gestion des métadonnées 3GPP (les éléments qui décrivent le format et d'autres informations supplémentaires, lorsqu'une vidéo est au format 3GPP) est bogué. Il n'a pas rejeté les métadonnées, lorsque les données étaient excessivement volumineuses, mais a simplement vérifié si elles étaient trop petites. Cela signifiait qu'il était possible pour un attaquant de créer un fichier « modifié » ou « corrompu », qui contiendrait une partie de métadonnées plus longue qu'elle ne le devrait.

L'un des grands défis de l'écriture de code pour gérer des données « non fiables » (c'est-à-dire provenant d'un utilisateur ou de tout autre type d'endroit externe à votre code) est la gestion des données de longueur variable. Les vidéos en sont un parfait exemple. Le logiciel doit allouer de la mémoire de manière dynamique, en fonction de ce qui se passe.

Dans ce cas, un tampon est créé comme pointeur vers de la mémoire, mais la longueur du tableau vers lequel il pointe était trop courte d'un élément. Les métadonnées étaient ensuite lues dans ce tableau, et il était possible que la dernière entrée de ce tableau ne soit pas « nulle » (ou nulle). Il est important que le dernier élément du tableau soit zéro, car c'est ainsi que le logiciel indique que le tableau est terminé. En étant capable de rendre la dernière valeur différente de zéro (puisque le tableau était potentiellement un élément trop petit), le code malveillant pourrait être lu par une autre partie du code et lire trop de données. Plutôt que de s'arrêter à la fin de cette valeur, il pourrait continuer à lire d'autres données qu'il ne devrait pas lire.

(Réf: OmniROM Gerrit)

2. [CVE-2015-1539]

La « taille » la plus courte possible des métadonnées doit être de 6 octets, car il s’agit d’une chaîne UTF-16. Le code prend la taille de la valeur entière et en soustrait 6. Si cette valeur était inférieure à 6, la soustraction "sous-dépasserait" et s'enroulerait, et nous nous retrouverions avec un très grand nombre. Imaginez si vous ne pouvez compter que de 0 à 65535, par exemple. Si vous prenez le nombre 4 et soustrayez 6, vous ne pouvez pas descendre en dessous de zéro. Revenez donc à 65535 et comptez à partir de là. C'est ce qui se passe ici !

Si une longueur inférieure à 6 était reçue, cela pourrait entraîner un décodage incorrect des trames, car le Le processus byteswap utilise la variable len16, dont la valeur est obtenue à partir d'un calcul commençant par (taille-6). Cela pourrait entraîner une opération d'échange beaucoup plus importante que prévu, ce qui modifierait les valeurs des données de trame de manière inattendue.

(Réf: OmniROM Gerrit)

3. [CVE-2015-3824]

Un gros problème! Celui-ci est méchant. Il y a exactement le contraire de ce dernier problème: un débordement d’entier, où un entier peut devenir « trop gros ». Si vous atteignez 65535 (par exemple) et que vous ne pouvez plus compter plus haut, vous vous retournerez et passerez ensuite à 0 !

Si vous allouez de la mémoire sur cette base (ce que fait Stagefright !), vous vous retrouverez avec beaucoup trop peu de mémoire allouée dans le tableau. Lorsque des données y étaient placées, elles écraseraient potentiellement des données non liées par des données contrôlées par le créateur du fichier malveillant.

(Réf: OmniROM Gerrit)

4. [CVE-2015-3826]

Encore un méchant! Très similaire au dernier - un autre débordement d'entier, où un tableau (utilisé comme tampon) serait rendu trop petit. Cela permettrait d'écraser la mémoire non liée, ce qui est encore une fois mauvais. Une personne capable d'écrire des données en mémoire peut corrompre d'autres données sans rapport et potentiellement les utiliser pour que du code qu'elle contrôle soit exécuté par votre téléphone.

(Réf: OmniROM Gerrit)

5. [CVE-2015-3827]

Assez similaire à ces derniers. Une variable est utilisée lors du saut de mémoire, et cela peut devenir négatif lors d'une soustraction (comme ci-dessus). Cela entraînerait une très grande longueur de "saut", dépassant un tampon, donnant accès à une mémoire à laquelle il ne faudrait pas accéder.

(Réf: OmniROM Gerrit)

Il existe également des correctifs (potentiellement) liés qui semblent également avoir été intégrés à [Android] 5.1.

(Réf: OmniROM Gerrit)

Cela ajoute des vérifications pour arrêter les problèmes avec un correctif de sécurité antérieur afin d'ajouter des vérifications de limites, qui peuvent elles-mêmes être dépassées. En C, les nombres qui peuvent être représentés comme un entier signé sont stockés comme un entier signé. Sinon, ils restent inchangés pendant les opérations. Dans ces contrôles, certains entiers auraient pu être signés (plutôt que non signés), ce qui réduirait leur valeur maximale par la suite et permettrait un débordement.

(Réf: OmniROM Gerrit)

Certains sous-dépassements entiers supplémentaires (où les nombres sont trop faibles, puis une soustraction est effectuée sur ces nombres, leur permettant de devenir négatifs). Cela conduit encore une fois à un grand nombre plutôt qu’à un petit nombre, ce qui entraîne les mêmes problèmes que ci-dessus.

(Réf: OmniROM Gerrit)

Et enfin, un autre débordement d'entier. Comme avant, il est sur le point d'être utilisé ailleurs et il pourrait déborder.

(Réf: OmniROM Gerrit)"

À quel point Stagefright est-il sérieux?

Selon le article de blog publié par la société de recherche mère, Zimperium Research Labs, l'exploit Stagefright expose potentiellement 95 % des appareils Android - soit environ 950 millions - sont confrontés à cette vulnérabilité, car elle affecte les appareils fonctionnant sous Android 2.2 et en haut. Pour aggraver les choses, les appareils antérieurs à Jelly Bean 4.3 courent le « pire risque » car ils ne contiennent pas de mesures d'atténuation adéquates contre cet exploit.

Concernant les dégâts que Stagefright pourrait infliger, pulser_g2 a fait remarquer :

[blockquote author="pulser_g2"]"En soi, Stagefright donnerait accès à l'utilisateur du système sur le téléphone. Cependant, vous devrez contourner l'ASLR (randomisation de la disposition de l'espace d'adressage) pour en abuser. On ne sait pas encore si cela a été réalisé ou non. Cet exploit permet d'exécuter du « code arbitraire » sur votre appareil en tant qu'utilisateur système ou multimédia. Ceux-ci ont accès à l’audio et à la caméra sur l’appareil, et l’utilisateur du système constitue un excellent endroit pour lancer un exploit root. Vous vous souvenez de tous les incroyables exploits root que vous avez utilisés pour rooter votre téléphone ?

Ceux-ci pourraient potentiellement être utilisés silencieusement pour obtenir le root sur votre appareil! Celui qui a root possède le téléphone. Ils devraient contourner SELinux, mais TowelRoot y est parvenu, et PingPong y est parvenu également. Une fois rootés, tout sur votre téléphone leur est ouvert. Messages, clés, etc."[/blockquote]En parlant des pires scénarios, seul un MMS est nécessaire pour transmettre le code et déclencher cet exploit. L'utilisateur n'a même pas besoin d'ouvrir le message car de nombreuses applications de messagerie prétraitent les MMS avant que l'utilisateur n'interagisse avec lui. Ceci est différent des attaques de spear phishing, dans la mesure où l'utilisateur pourrait être complètement inconscient d'une attaque réussie, compromettant ainsi toutes les données présentes et futures du téléphone.

Qu’est-ce qui différencie Stagefright des autres « vulnérabilités massives »?

"Toutes les vulnérabilités présentent un certain risque pour les utilisateurs. Celui-ci est particulièrement risqué, car si quelqu'un trouve un moyen de l'attaquer à distance (ce qui est possible, si un moyen de contourner l'ASLR était trouvé), il pourrait être déclenché avant même que vous réalisiez que vous êtes sous attaque"

Les exploits plus anciens comme Android Installer Hijacking, FakeID ainsi que les exploits root comme TowelRoot et PingPong nécessitent une interaction de l'utilisateur à un moment donné pour être exécutés. Bien qu’il s’agisse encore d’« exploits » dans la mesure où de nombreux dommages peuvent survenir s’ils sont utilisés de manière malveillante, il n’en demeure pas moins que Stagefright en théorie, il suffit du numéro de portable d'une victime pour transformer son téléphone en cheval de Troie et c'est pourquoi on lui a accordé beaucoup d'attention ces derniers temps. jours.

Cependant, Android n’est pas entièrement à la merci de cet exploit. Ingénieur principal de la sécurité Android, Adrian Ludwig a répondu à certaines préoccupations dans un Publication Google+:

[blockquote author="Adrian Ludwig"]"Il existe une hypothèse erronée et courante selon laquelle tout bug logiciel peut être transformé en exploit de sécurité. En fait, la plupart des bugs ne sont pas exploitables et Android a fait beaucoup de choses pour améliorer ces chances...

Une liste de certaines de ces technologies qui ont été introduites depuis Ice Cream Sandwich (Android 4.0) est répertoriée ici. Le plus connu d'entre eux s'appelle Address Space Layout Randomization (ASLR), qui a été entièrement achevé sous Android 4.1 avec prise en charge de PIE (Position Independent Executables) et est désormais présent sur plus de 85 % d'Android dispositifs. Cette technologie rend plus difficile pour un attaquant de deviner l'emplacement du code, ce qui est nécessaire pour créer un exploit réussi...

Nous ne nous sommes pas arrêtés à ASLR, nous avons également ajouté NX, FortifySource, Read-Only-Relocations, Stack Canaries, et bien plus encore."[/blockquote]

Cependant, il est indéniable que Stagefright est une question sérieuse pour l'avenir d'Android et qu'en tant que telle, elle est prise au sérieux par les parties prenantes impliquées. Stagefright a également mis en lumière les éléphants blancs dans la pièce: le problème de la fragmentation et des mises à jour qui parviennent finalement au consommateur.

Le dilemme de la mise à jour

En parlant de mises à jour, il est bon de voir que les constructeurs OEM assument la responsabilité de la sécurité des utilisateurs, comme beaucoup l’ont promis. améliorer le processus de mise à jour spécifiquement pour incorporer des correctifs de sécurité et des correctifs pour des exploits comme Stagefright.

Parmi les premiers à publier une déclaration officielle, Google a promis mises à jour de sécurité mensuelles (en plus des mises à jour prévues du système d'exploitation et de la plate-forme) pour la plupart de ses appareils Nexus, y compris le Nexus 4, âgé de presque 3 ans. Samsung a également emboîté le pas en annonçant qu'il travaillerait avec les opérateurs et les partenaires pour mettre en œuvre un programme mensuel de mise à jour de sécurité mais il n'a pas précisé les appareils et les détails du calendrier de cette mise en œuvre. Ceci est intéressant car il mentionne une approche « accélérée » des mises à jour de sécurité en collaboration avec les opérateurs, afin que nous puissions attendez-vous à des mises à jour plus fréquentes (bien que basées sur la sécurité, mais j'espère que cela accélérera également les mises à niveau du micrologiciel) sur l'opérateur dispositifs.

Parmi les autres OEM rejoignant le peloton, citons LG qui se joindra à mises à jour de sécurité mensuelles. Motorola a également annoncé le liste des appareils qui seront mis à jour avec les correctifs Stagefright, et la liste comprend presque tous les appareils fabriqués par la société depuis 2013. Sony a également déclaré que ses appareils recevront bientôt les patchs aussi.

Pour une fois, les opérateurs proposent également des mises à jour. Le sprint a a publié une déclaration que certains appareils ont déjà reçu le correctif Stagefright, et que d'autres appareils sont prévus pour la mise à jour. AT&T a également emboîté le pas en émettant le correctif sur certains appareils. Verizon a également publié des correctifs, bien qu'il s'agisse d'un déploiement lent qui donne la priorité aux smartphones haut de gamme comme le Galaxy S6 Edge et le Note 4. Le T-Mobile Note 4 a également reçu une mise à jour du correctif Stagefright.

En tant qu'utilisateur final, quelques mesures de précaution peuvent être prises pour réduire vos risques d'être attaqué. Pour commencer, désactivez la récupération automatique des messages MMS dans les applications de messagerie présentes sur votre téléphone. Cela devrait permettre de contrôler les cas où aucune interaction de l'utilisateur n'est requise pour que l'exploit fonctionne. Après cela, veillez à éviter de télécharger des médias à partir de messages MMS provenant de sources inconnues et non fiables.

En tant qu'utilisateur expérimenté de XDA, vous pouvez également apporter des modifications à votre accessoire de construction pour désactiver Stagefright. Ce n'est pas un moyen complet et infaillible de vous sauver de Stagefright, mais vous pouvez tenter votre chance pour réduire les chances de succès d'une attaque si vous êtes bloqué sur une ancienne version d'Android. Il existe également des solutions ROM personnalisées, dont la plupart synchronisent régulièrement les sources avec AOSP et intègrent donc les correctifs Stagefright. Si vous utilisez une ROM basée sur AOSP, il est fortement recommandé de mettre à jour vers une version plus récente de la ROM qui intègre les correctifs Stagefright. Vous pouvez utiliser cette application pour vérifier si votre conducteur quotidien actuel est affecté par Stagefright.

Android, post-Stagefright

Stagefright n'a été qu'un signal d'alarme envers Android et son problème de fragmentation ainsi que de mises à jour. Il souligne qu’il n’existe aucun mécanisme clair permettant de déployer de tels correctifs critiques en temps opportun sur de nombreux appareils. Alors que les constructeurs OEM tentent de déployer des correctifs pour les appareils, la dure vérité est que la plupart de ces correctifs seront limités aux produits phares récents. D’autres appareils non phares et plus anciens, et encore moins ceux des petits OEM, continueront d’être exposés à des produits comme Stagefright.

Il y a un côté positif à cet exploit: Il a attiré à nouveau l'attention sur le processus de mise à jour d'Android et l'a présenté sous un jour qui n'attirera pas autant de futures entreprises vers l'adoption d'Android pour une utilisation professionnelle. À mesure que Google s'efforce d'adopter une plus grande adoption par les entreprises, il sera obligé de repenser sa stratégie de mise à jour et le degré de contrôle qu'il accorde aux OEM.

Alors qu'Android M se rapproche de jour en jour de sa sortie sur le marché, il ne serait pas surprenant que Google choisisse de se séparer de plus en plus de composants de l'AOSP au profit de son package de services Play. Après tout, c'est un domaine sur lequel Google conserve toujours un contrôle total si un appareil doit être livré avec Google Play Store. Ce a ses propres inconvénients sous la forme du remplacement des zones open source par des murs close source.

En spéculant sur l’avenir d’Android, il existe une (très petite) possibilité que Google limite également les modifications que les OEM peuvent apporter à l’AOSP. Avec le Cadre RRO étant présent dans un état fonctionnel dans Android M, Google pourrait restreindre les OEM à apporter uniquement des modifications cosmétiques sous la forme de skins RRO. Cela devrait permettre un déploiement plus rapide des mises à jour, mais cela se ferait au prix du refus des OEM de la possibilité de personnaliser entièrement Android.

Une autre solution qui pourrait être envisageable serait de le rendre obligatoire pour tous les appareils expédiés avec Google Play Store recevra des mises à jour de sécurité garanties pendant une période déterminée, éventuellement deux années. Le cadre des services Play pourrait être utilisé pour vérifier la présence de mises à jour et de correctifs de sécurité importants, l'accès au Play Store étant annulé en cas de non-conformité.

Notes de clôture

Il s’agit au mieux de spéculations, car il n’existe aucun moyen élégant de résoudre ce problème. À moins d’une approche très totalitaire, il y aura toujours des lacunes dans la portée des solutions. En raison du grand nombre d'appareils Android, suivre l'état de sécurité de chaque appareil serait une tâche très gigantesque. Le besoin actuel est de repenser la manière dont Android se met à jour, car la méthode actuelle n’est certainement pas la meilleure. Chez XDA Developers, nous espérons qu'Android continuera à rester fidèle à ses racines Open Source tout en travaillant avec les plans fermés de Google.

Votre téléphone est-il vulnérable à Stagefright? Pensez-vous que votre téléphone recevra un jour un patch Stagefright? Faites-le nous savoir dans les commentaires ci-dessous !