Stagefright expliqué: L'exploit qui a changé Android

L'un des points forts d'Android est principalement sa nature open source, qui permet aux parties prenantes de créer, modifier et redistribuer le système d'exploitation de manière à répondre à leurs besoins particuliers. Mais cet avantage même d'être open source agit comme une arme à double tranchant en ce qui concerne les problèmes de malware et de sécurité. Il est plus facile de trouver et de corriger les défauts lorsque vous avez beaucoup de contributeurs capables sur un projet dont le code source est disponible librement. Cependant, régler le problème au niveau de la source ne signifie pas souvent que le problème sera 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 lancement du programme Android For Work lors de Google I / O 2014, Google a donné le premier coup de pouce vers un écosystème plus sécurisé et plus convivial pour les entreprises. Android For Work a adopté une approche à deux profils pour répondre aux besoins des entreprises. Ainsi, les administrateurs informatiques pouvaient créer un profil d'utilisateur distinct pour les employés, l'un centré sur le travail, laissant d'autres profils à l'usage personnel des employés. Grâce au cryptage matériel et aux stratégies gérées par l'administrateur, les données personnelles et professionnelles restent distinctes et sûres. Par la suite, Android For Work a attiré davantage d’attention ces derniers mois, l’accent étant mis sur la sécurité de l’appareil contre les logiciels malveillants. Google prévoyait également d’activer le chiffrement intégral des appareils livrés avec Android Lollipop, mais cette opération a été abandonnée en raison de problèmes de performances, le transfert étant désormais optionnel pour les OEM.

L’appui pour un Android sécurisé n’est pas tout du travail de Google, Samsung y ayant joué un rôle assez important grâce à ses contributions de KNOX à AOSP, qui ont finalement renforcé Android For Work. Toutefois, les récents exploits de sécurité et vulnérabilités d'Android laissent planer une tâche difficile en termes de popularité pour l'adoption par les entreprises. La vulnérabilité récente de Stagefright en est un exemple.

Contenu:

  • Qu'est-ce que Stagefright?
  • Quelle est la gravité de Stagefright?
  • 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 le code reçu sous la forme d'une vidéo malveillante via MMS, ne nécessitant ainsi que le numéro de téléphone portable de la victime pour mener à bien une attaque.

Pulser_g2, notre expert interne, développeur reconnu et développeur reconnu, nous a fourni des explications plus détaillées.

« Au moment où j'écris ces lignes, l'exploit de [Stagefright] devait être expliqué sur BlackHat [Link], bien qu'il n'y ait pas encore de diapositives ou de papier blanc.

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

Stagefright comporte un certain nombre de bogues, qui ont leur propre numéro CVE [Common Vulnerabilities & Exposures] pour le 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 liés directement à chaque CVE (comme il se doit), ce sera donc un peu compliqué à expliquer.

1. [CVE-2015-1538]

Dans le code de traitement MPEG4, le code de traitement des métadonnées 3GPP (l'élément décrivant le format et d'autres informations supplémentaires lorsqu'une vidéo est au format 3GPP) est erroné. Il n'a pas rejeté les métadonnées, où les données étaient excessivement volumineuses, mais 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 portion de métadonnées plus longue que prévu.

L'un des grands défis de l'écriture de code pour traiter des données «non fiables» (c'est-à-dire d'un utilisateur ou de tout autre lieu extérieur au code) est la gestion de 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éé en tant que pointeur sur une certaine mémoire, mais la longueur du tableau pointé est un élément trop court. 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 zéro). Il est important que le dernier élément du tableau soit zéro, car c'est ainsi que le logiciel indique au tableau qu'il est terminé. En étant capable de rendre la dernière valeur non nulle (étant donné que 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 serait «sous-jacente» et bouclée, 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 pourrez pas descendre en dessous de zéro. Donc, vous retournez à 65535 et comptez à partir de là. C'est ce qui se passe ici!

Si une longueur inférieure à 6 était reçue, des images pourraient être décodées de manière incorrecte, car 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 volumineuse que prévu, ce qui modifierait les valeurs des données de l'image de manière inattendue.

(Réf: OmniROM Gerrit)

3. [CVE-2015-3824]

Un gros! Celui-ci est méchant. Il y a l'exact opposé de ce dernier problème - un dépassement d'entier, où un entier peut devenir «trop grand». Si vous atteignez 65535 (par exemple) et que vous ne pouvez compter plus haut, vous feriez volte-face et passeriez à 0 ensuite!

Si vous allouez de la mémoire en fonction de cela (c'est ce que fait Stagefright!), Vous vous retrouveriez avec beaucoup trop peu de mémoire allouée dans le tableau. Lorsque les données y étaient insérées, les données non corrélées seraient écrasées par les données contrôlées par le créateur de fichier malveillant.

(Réf: OmniROM Gerrit)

4. [CVE-2015-3826]

Un autre méchant! Très similaire au dernier - un autre dépassement d'entier, où un tableau (utilisé comme tampon) serait trop petit. Cela permettrait à la mémoire non liée d'être écrasée, ce qui est encore mauvais. Quelqu'un qui peut écrire des données en mémoire peut corrompre d'autres données qui ne sont pas liées, et éventuellement l'utiliser pour que le code qu'ils contrôlent 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, ce qui peut être rendu négatif lors d'une soustraction (comme ci-dessus). Cela entraînerait une très grande longueur de «saut», débordant d'un tampon, donnant accès à de la mémoire à laquelle il ne devrait pas être accédé.

(Réf: OmniROM Gerrit)

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

(Réf: OmniROM Gerrit)

Cela ajoute des contrôles pour arrêter les problèmes avec un correctif de sécurité passé pour ajouter des contrôles de limites, qui peuvent eux-mêmes être dépassés. En C, les nombres pouvant être représentés sous la forme d'un entier signé sont stockés sous la forme d'un entier signé. Sinon, ils restent inchangés pendant les opérations. Lors de ces vérifications, certains entiers auraient pu être signés (plutôt que non signés), ce qui réduirait leur valeur maximale ultérieurement et permettrait un dépassement de capacité.

(Réf: OmniROM Gerrit)

Certains sous-débits plus entiers (où les nombres sont trop bas, puis une soustraction est effectuée sur ces nombres, ce qui leur permet d’être négatifs). Cela conduit encore à un grand nombre, plutôt qu’à un petit nombre, ce qui pose les mêmes problèmes que ci-dessus.

(Réf: OmniROM Gerrit)

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

(Réf.: OmniROM Gerrit)

Quelle est la gravité de Stagefright?

Selon le billet de blog publié par la société mère de recherche, Zimperium Research Labs, l'exploit de Stagefright expose potentiellement 95% des appareils Android, soit environ 950 millions de personnes, à cette vulnérabilité dans la mesure où elle affecte les appareils fonctionnant sous Android 2.2. Pour aggraver les choses, les appareils antérieurs à Jelly Bean 4.3 présentent le «risque le plus élevé», car ils ne contiennent pas les mesures adéquates pour atténuer cet exploit.

En ce qui concerne les dommages que Stagefright pourrait causer, pulser_g2 a remarqué:

““ En soi, Stagefright donnerait un accès à l'utilisateur du système par téléphone. Cependant, vous devrez contourner ASLR (randomisation de la disposition d'espace d'adressage) pour en abuser. On ne sait pas 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 le périphérique, et l'utilisateur du système est un endroit idéal pour lancer un exploit root. Vous vous souvenez de tous les exploits root incroyables que vous avez utilisés pour rooter votre téléphone?

Celles-ci pourraient éventuellement être utilisées en mode silencieux pour prendre racine sur votre appareil! Celui qui a la racine possède le téléphone. Ils devraient contourner SELinux, mais TowelRoot a réussi cela, et PingPong a réussi aussi. Une fois qu'ils ont obtenu la racine, tout ce qui se trouve sur votre téléphone leur est ouvert. Messages, clés, etc. ””

pulser_g2

À propos des pires scénarios, seul un MMS est nécessaire pour livrer 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 le MMS avant que l'utilisateur n'interagisse avec lui. Ceci est différent des attaques de spear-phishing car l’utilisateur peut être complètement inconscient d’une attaque réussie, en compromettant toutes les données présentes et futures contenues dans le téléphone.

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

«Toutes les vulnérabilités présentent un 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 attaqué ””

pulser_g2

Les exploits plus anciens comme Android Installer Hijacking, FakeID ainsi que les exploits root tels que TowelRoot et PingPong nécessitent une interaction de l'utilisateur à un moment donné pour être exécutés. Même s’ils sont encore «exploités» par le fait que de nombreux préjudices peuvent être causés par une utilisation malveillante, il n’en reste pas moins que Stagefright n’a théoriquement besoin que du numéro de téléphone mobile de la victime pour transformer son téléphone en un cheval de Troie. journées.

Android n'est cependant pas entièrement à la merci de cet exploit. Adrian Ludwig, ingénieur en chef chez Android Security, a évoqué certaines inquiétudes dans un article de Google:

«Il existe une hypothèse erronée commune selon laquelle tout bogue logiciel peut être transformé en exploit de sécurité. En fait, la plupart des bugs ne sont pas exploitables et il y a beaucoup de choses que Android a faites pour améliorer ces chances…

Voici une liste de certaines de ces technologies introduites depuis Ice Cream Sandwich (Android 4.0). Le plus connu d'entre eux s'appelle ASLR (Address Space Layout Randomization), complètement complété dans Android 4.1 avec la prise en charge de PIE (Position Independent Executables) et concerne désormais plus de 85% des appareils Android. Cette technologie rend plus difficile pour un attaquant de deviner l'emplacement du code, qui lui est nécessaire pour créer un exploit réussi…

Nous ne nous sommes pas arrêtés avec ASLR, nous avons également ajouté NX, FortifySource, Relocations en lecture seule, Canaries empilées, etc. ».

Adrian Ludwig

Cependant, force est de constater que Stagefright est une question sérieuse pour l'avenir d'Android et, en tant que tel, est pris au sérieux par les parties prenantes impliquées. Stagefright a également souligné les éléphants blancs dans la pièce - le problème de la fragmentation et des mises à jour atteignant finalement le consommateur.

Le dilemme de la mise à jour

En parlant de mises à jour, il est bon de voir que les OEM assument la responsabilité de la sécurité des utilisateurs, car beaucoup ont promis d'améliorer le processus de mise à jour en intégrant des correctifs de sécurité et des correctifs pour des exploits tels que Stagefright.

Parmi les premiers à publier un communiqué officiel, Google a promis des mises à jour de sécurité mensuelles (en plus des mises à jour prévues pour le système d'exploitation et la plate-forme) de la plupart de ses appareils Nexus, y compris le Nexus 4, presque âgé de 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 de mise à jour de sécurité mensuel, mais qu’il n’a pas été en mesure de spécifier les périphériques et les détails de la chronologie de cette implémentation. 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, de sorte que nous pouvons nous attendre à 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 à jour de microprogrammes) sur les appareils des opérateurs.

Parmi les autres constructeurs OEM qui rejoignent le groupe, on peut citer LG, qui se joindra aux mises à jour de sécurité mensuelles. Motorola a également annoncé la liste des appareils qui seront mis à jour avec les correctifs de Stagefright. Cette liste inclut presque tous les appareils fabriqués par la société depuis 2013. Sony a également annoncé que ses appareils recevront bientôt les correctifs.

Pour une fois, les transporteurs sont également à venir avec des mises à jour. Sprint a publié une déclaration indiquant que certains périphériques avaient déjà reçu le correctif Stagefright, et que davantage de périphériques étaient planifiés pour la mise à jour. AT & T a également emboîté le pas en publiant 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 Note 4. 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 chances 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 garder le contrôle des cas dans lesquels aucune interaction de l'utilisateur n'était requise pour que l'exploit fonctionne. Ensuite, veillez à ne pas télécharger de contenu multimédia à partir de messages MMS provenant de sources inconnues et non fiables.

En tant qu'utilisateur expérimenté, vous pouvez également modifier votre propulseur de construction pour désactiver Stagefright. Ce n'est pas un moyen sûr et sûr de vous sauver de Stagefright, mais vous pouvez tenter votre chance pour réduire les chances d'une attaque réussie si vous êtes bloqué sur une version plus ancienne d'Android. Il existe également des solutions ROM personnalisées, dont la plupart synchronisent régulièrement les sources avec AOSP et intègrent par conséquent les correctifs Stagefright. Si vous exécutez une ROM basée sur le programme AOSP, il est vivement recommandé de mettre à jour une version plus récente de la ROM intégrant les correctifs Stagefright. Vous pouvez utiliser cette application pour vérifier si votre pilote quotidien actuel est affecté par Stagefright.

Android, Post-Stagefright

Stagefright n’a été qu’un réveil d’Android et de son problème de fragmentation ainsi que de mises à jour. Il souligne qu’il n’existe pas de mécanisme clair permettant d’appliquer rapidement ces correctifs critiques à de nombreux périphériques. Alors que les constructeurs essaient de déployer des correctifs pour les périphériques, la vérité est que la plupart de ces correctifs seront limités aux produits phares récents. Les autres périphériques non plus phares et plus anciens, et encore moins ceux de petits constructeurs OEM, continueront à être exposés aux mêmes caractéristiques que Stagefright.

Cet exploit a un aspect positif : il a réorienté l'attention sur le processus de mise à jour d'Android et l'a présenté sous un jour qui n'attirerait pas autant de futures entreprises pour l'adoption d'Android à des fins professionnelles. Au fur et à mesure que Google travaillera à une plus grande adoption par les entreprises, il sera obligé de repenser sa stratégie de mise à jour et le niveau de contrôle qu'il autorise.

Alors qu'Android M se rapproche de la sortie sur le marché de jour en jour, il ne serait pas surprenant que Google choisisse de dissocier de plus en plus de composants de AOSP en faveur de son ensemble de services de lecture. Après tout, c’est un domaine sur lequel Google conserve toujours le contrôle total sur la livraison d’un appareil avec Google Play Store. Cela a ses inconvénients en remplaçant les zones ouvertes par des murs proches.

Lorsque l'on spécule sur l'avenir d'Android, il est (très peu) possible que Google limite également les modifications que les équipementiers peuvent apporter à AOSP. Le cadre RRO étant présent dans un état fonctionnel dans Android M, Google pourrait limiter les constructeurs OEM à n'apporter que des modifications esthétiques sous la forme de peaux RRO. Cela devrait permettre un déploiement plus rapide des mises à jour, mais aurait pour conséquence que les constructeurs OEM se voient refuser la possibilité de personnaliser complètement Android.

Une autre possibilité serait de rendre obligatoire que les mises à jour de sécurité garanties par tous les appareils expédiés avec Google Play Store soient garanties pendant une période déterminée, éventuellement deux ans. La structure Play Services pourrait être utilisée pour vérifier la présence d'importantes mises à jour et correctifs de sécurité, l'accès au Play Store étant annulé en cas de non-conformité.

Notes de clôture

Cela reste au mieux une spéculation, car il n’existe aucun moyen élégant de résoudre ce problème. Sans une approche très totalitaire, il y aura toujours des lacunes dans la portée des solutions. En raison du nombre impressionnant d'appareils Android, il serait très gigantesque de surveiller l'état de la sécurité de chaque appareil. La nécessité de l'heure est de repenser la façon dont Android se met à jour, car la méthode actuelle n'est certainement pas la meilleure. Les développeurs espèrent qu'Android continue de rester fidèle à ses racines Open Source tout en travaillant avec les plans de source fermée de Google.

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