Il semble que Google ne puisse décidément pas se débarrasser de la faille Stagefright. La découverte initiale remonte à presque trois mois, et plusieurs variantes de la brèche ont été détectées, obligeant plusieurs constructeurs à déployer des séries de correctifs. L’histoire recommence avec Stagefright 2.0, exploitable cette fois depuis un navigateur.
Le nom « Stagefright » provient de celui d'une bibliothèque système d’Android, libstragefright. Écrite en C++, elle est chargée de la lecture d’un grand nombre de formats multimédia, audio comme vidéo. La faille permettait en fait d’exécuter des instructions contenues dans un fichier, dès qu’elles étaient lues par la bibliothèque. Intégrée profondément dans Android, elle ne pouvait être désactivée et représentait dès lors un véritable danger.
Une faille très sérieuse dont Google a du mal à se débarrasser
Le cas le plus sérieux pouvait se manifester avec un simple MMS. Envoyé de nuit, pendant le sommeil de l’utilisateur, le contenu était préchargé et lu, les instructions étaient exécutées et un malware pouvait être téléchargé pour accomplir son méfait. Une fois l’opération terminée, le code avait suffisamment de droits pour effacer ses traces, de sorte qu’au réveil, l’utilisateur n’avait aucun moyen de savoir qu’un problème avait eu lieu.
Stagefright a eu le mérite en tout cas de relancer très sérieusement le sujet épineux de la gestion de la sécurité à long terme de la plateforme Android. Car si celle-ci reçoit régulièrement des mises à jour de sécurité, elles ne parviennent pas toujours à l’utilisateur. Il faut que son smartphone ou sa tablette soit assez récent pour être encore supporté par le constructeur. Google, Samsung et d’autres entreprises ont ainsi annoncé la mise en place d’un cycle mensuel, à la manière des Patch Tuesdays de Microsoft. Mais, là encore, seuls les appareils relativement récents en profitent.
Une version 2.0 qui exploite les métadonnées dans un navigateur
Et alors que tout le monde n’a pas encore été servi par les premiers correctifs, il faut déjà en prévoir d’autres. La société Zimperium, à l’origine de la découverte de Stagefright, revient avec une « version 2.0 » de la faille. Il s’agit plus précisément de la concordance de deux failles, une dans la bibliothèque libutils, l’autre dans libstragefright. La première est totalement nouvelle et Google a d’ailleurs créé un bulletin CVE spécifique. Selon Zimperium, c’est bien cette brèche (disponible sur toutes les versions à partir de la 1.0) qui permet d’activer la seconde.
Le vice-président de la recherche, Joshua Drake, explique sur le blog de l'entreprise que la faille peut être exploitée de plusieurs manières. Tout d’abord – et c’est la solution la plus simple – en attirant l’utilisateur sur une page web particulière, par n’importe quel moyen. Un pirate sur le même réseau pourrait également injecter le code malveillant via des techniques d’interception classiques (Man in the Middle) dans un flux en clair destiné au navigateur. Dans tous les cas, dès que les métadonnées sont lues, la bibliothèque exécute les instructions. Il s'agit donc à nouveau d'une faille RCE (Remote Code Execution), donc exploitable à distance.
Il suffit de ne cliquer sur rien
Le chercheur a indiqué au site Motherboard qu’il n’y avait rien à faire actuellement, à part sans doute vérifier les liens sur lesquels on clique (autant alimenter la psychose). Comme pour la première précédente de Stagefright, à peu près tous les appareils Android utilisés dans le monde pourraient être concernés, d'autant que les dernières mises à jour ne protègent pas de l'exploitation. Un Galaxy S6 parfaitement à jour par exemple y est donc vulnérable. Pour Zimperium, ce ne sont pas moins de 1,4 milliard d’appareils qui sont donc potentiellement exposés à ce risque. Potentiellement, car Joshua Drake précise : « Je ne peux vous dire que tous les téléphones sont vulnérables, mais la plupart le sont ».
Google est dans tous les cas informé de cette nouvelle variante. La faille centrale étant connue, il se pourrait que le développement d’un correctif ne prenne que peu de temps. Espérons d'ailleurs que la mise à jour soit déployée dès la prochaine série de bulletins mensuels.
Commentaires (45)
#1
Espérons d’ailleurs que la mise à jour soit déployée dès la prochaine série de bulletins mensuels
Et que les opérateurs fassent les mises à jour de leurs firmwares avec surcouches de merde avant 2019.
#2
Alors que revoilà la sous préfète
Prenez un chewing-gum Emile… Si si, prenez un chewing-gum Emile.
#3
#4
stagefright, ça fini comme un épisode de Dallas
… to be continued …
#5
Pas moyen de s’en prémunir avec un navigateur spécifique ? :/
#6
Le jour ou Kevin va pirater mon pauvre téléphone sous android 4.1( aucune maj disponible et pas envie de repasser à la caisse) je vais prendre chère avec toutes les failles de disponible…
#7
Ou comment motiver les gens a changer de ROM
" />
#8
Ou comment motiver les gens à acheter autre qu’Android.
#9
#10
#11
Encore faut-il pouvoir installer une rom, ce qui n’est pas toujours possible à moins d’avoir un smartphone bien spécifique.
#12
#13
Et encore, il faut arriver à se dépatouiller avec toutes les versions du même téléphone que tu as.
Je prends le mien en exemple : Samsung Galaxy Note 3, t’as le LTE, le INTL, etc…
#14
#15
#16
Juste à titre d’infos, qu’en est-il des Blackphone ? Parce que là on parle d’une lib qui est au coeur du système.
#17
Mon telephone sous tizen vous salut bien ^^
#18
En même temps il pas totalement tord. Le paysage des OS pour mobile ne brille pas niveau sécurité. Même si les ROM ne changent pas le problème.
#19
#20
#21
Touchés pareil en théorie.
Après le systeme peut éventuellement bloquer les sorties non controlés
#22
Parce que les applications Android ne sont pas cloisonnées? D’ailleurs, c’est quoi les données que cette faille permettrait de récupérer?
Ne jamais faire confiance aux auto-proclamés numéros 1 de la sécurité qui sortent des failles spectaculaires, avec des chiffres dévastateurs à quelques jours d’une conférence. Les versions Android 4.0 et supérieures ont d’autres mécanismes de sécurité qui rendent cette faille encore plus aléatoire que la réalité elle-même qui rend déjà sont exploitation tellement contraignante que personne ne s’y est mis.
#23
Comme tous les OS au monde : soit c’est corrigé soit non
" />
" />
S’ils suivent les correctifs de Google (ou si l’intégrateur pousse son patch chez aosp pourquoi pas) alors la faille devrait être corrigée dans des délais acceptable (si corrigée bien entendu)… si c’est comme les OEM grand public…
#24
#25
Bon mon S3 sous 4.3 risque de prendre cher
" />
#26
Tout le monde s’en fout de cette faille, le but de Samsung et cie c’est de vendre du matos pas de gagner un concours de sécu, c’est sûr ça leur fait un peu de mauvaise pub mais ce n’est pas comme s’ils n’avaient pas le budget marketing pour compenser ça.
Idem pour Google, il doit donner le change car ses utilisateurs sont un peu plus technophiles que ceux de Samsung, mais tant que ça ne met pas en danger les parts de marché d’Android ses actionnaires peuvent dormir tranquilles.
Ça m’attriste hein, mais ici on est sur NextInpact pas sur un site de Webedia, ce n’est pas le genre d’info que retient l’acheteur lambda :/
#27
#28
Si il y a une faille du type que Windows XP avait subit comme Blaster, ou tout ordinateur connecté à internet était vérolé dans la minute et rebootait en boucle, je pense que l’image de samsung va souffrir, et que les opérateurs qui se feront débordé feront la gueule…
mais malheureusement, j’ai l’impression que ce n’est que comme ça que les opérateurs prendront la mesure de leurs responsabilité dans la mise à jour des téléphones de leur réseau…. exactement comme Windows XP à changé après blaster
#29
Rah Blaster…
" />
J’ai un ami qui avait tout formater pour tout bien réinstaller… il a commencer à aller sur le net avant d’installer l’antivirus… boom réinfection direct ! La grande époque
#30
A partir du moment où google est une faille des données personnelles, cette stragefright est de la roupi de sansonnet à côté, en regard du nombre d’unités vendues
#31
Par contre une question que je me pose, si ton téléphone est déjà infecté sans que tu le sache, le futur correctif ne sert à rien j’imagine ?
#32
#33
Installons donc des antivirus sur nos Android. Depuis le temps que les éditeurs de solutions de sécurité nous le disent…
#34
Je me demande bien comment s’en sortira un appareil comme le Blackberry Priv. Le but du jeu, c’est la sécurité max. Or, avec Android, on en est quand même assez loin vu les récents événements.
Big up pour Jolla et Sailfish OS au passage.
#35
ca ne me surprendrais pas qu’ils mettent une espèce de machine virtuelle chiffré, pour les données pro.
maintenant un système dont le bas niveau est compromis, tu peux faire ce que tu veux, le pirate aura le contrôle…
PS: quand Jolla et Sailfish sortiront, ils auront aussi des failles de sécurité a corriger, faut arrêter de se faire des films…
#36
Oui je sais, mais Jolla ça corrige vite. Très vite.
#37
Quel bazar que j’ai pu mettre avec mon commentaire sur le changement de ROM 
" />
#38
C’est bien ce que je me disais. Merci à vous. Ça vaut le coup 800 roros pour un téléphone plombé.
" />
#39
#40
#41
Tout système d’exploitation a des failles….
Mais ce qui est impératif, c’est qu’une fois une faille découverte, elle puisse être corrigée dans les plus brefs délais sur tous les appareils en circulation.
Sur Android, c’est ce qui ne va pas.
D’abord parce que les mises à jour sont au bon vouloir des constructeurs d’appareils. Et ils ne se foulent pas, que ce soit d’un point de vue réactivité ou de la durée de prise en charge.
Le bon modèle pour les smartphones, c’est de suivre la logique du PC : un appareil qui peut recevoir l’installation de n’importe quel Os et dont les mises à jour ne dépendent pas des fabricants.
#42
Libstagefright aussi utilisée par les hackers de la scène 3DS/WiiU en ce moment…
#43
Il est grand temps qu’Android évolue en scindant son “noyau” en plusieurs parties. Il y a trop de choses dedans (à commencer déjà par les applis préinstallées non désinstallables, y compris les applis Google comme le Google Play Store ou Youtube, qui buffent la place en permanence dans leur ancienne version, même quand on a installé la nouvelle version en plus).
Même les bibliothèques de service (non strictement nécessaires au démarrage de l’appareil ou les pilotes de périphériques tels que la Cam) devraient être isolés dans des packages TOTALEMENT désinstallables (pour libérer l’espace interne et pour ne plus avoir à les réactiver si on a mis autre chose pour les remplacer).
Même les pilotes de périphériques (y compris les “blobs” propriétaires devraient être remplaçables, il suffirait juste d’un certificat de sécurité pour installer la nouvelle version puis une fois activée et fonctionnelle supprimer totalement l’ancienne).
Et dans la plupart des cas cela ne devrait même pas nécessiter de rebooter le téléphone ou d’installer une nouvelle ROM de base. Je ne comprends pas du tout pourquoi toutes les ROM sont aussi énormes, même débarassées du package additionel des GoogleApps à installer séparément). La ROM doit juste permettre d’énumérer les périhpériques physiques de base, aucun périphérique purement logiciel ne devrait y être (exemple les méthodes de saisie, les listes de certificats préapprouvés, beaucoup trop grosses alors qu’il suffit d’inclure dans la ROM un unique certificat identifiant la version de la ROM ou sa source officielle pour permettre de la mettre à jour avec éventuellement un nouveau certificat, les autres certificats sont téléchargeables ensuite depuis le site du fournisseur, même si la package d’installation en ajoute dès le début dans la zone non protégée)
Mais il semble en fait que les APIs spécifiques Android (hors des API Java classiques) soient uniquement des créations de Google permettant aux applis Google de communiquer librement entre elles en passant outre leur barrière d’isolation, elles sont là non pas comme des barrières mais comme des portes ouvertes. Libstragefright en est un parfait exemple puisqu’elle change silencieusement de contexte de sécurité et passe toutes les données qu’elle veut d’un niveau à l’autre :
Un unique point de contrôle est mis à l’entrée de l’API mais tous les composants utilisés derrière ne vérifient plus rien, ils sont déjà en mode privilégié et Google se passe totalement dans ses APIS d’utiliser les APIs documentées des autres composants, ce qui est une violation du concept de boite noire : il y a trop de passerelles dérobées, ces bibliothèques n’étant pas isolées entre elles, la boite noire est juste superficielle (c’est juste un bout de chiffon noir posé sur un plat de vieilles spaghettis grouillant de vers : on croit voir la fine couche de fromage gratiné, ça sent bon et on plonge la cuillère dedans, on croit se régaler et on finit par une bonne tourista) Le problème est que lors du passage interne d’une bibliothèque à l’autre, on a perdu la trace du contexte de sécurité d’origine (car Google ne respecte pas les consignes de sécurité Java et ne transmet pas les contraintes en créant les contextes appropriés: il passe toute les données en aveugle à la bibliothèque suivante sans même savoir si c’est vraiement elle qui va les traiter et pas une autre encore plus bas et ces canaux internes ne valident pas chaque étape.
Il faut dire aussi que le cas des codecs multimédia (objet de Libstagefright) est à la base un plat de spaghettis avec de trop nombreuses extensions non documentées. Les spécifications d’ailleurs sont largement incomplètes, et les extensions possibles beaucoup trop nombreuses. La notion de “profil” des extensions supportées n’est pas mise en oeuvre du tout alors qu’un profil devrait bloquer tout ce qu’il ne connait pas ou n’implémente pas (ou pas encore) correctement et complètement (pour utiliser les extensions, il faudrait non seulement transmettre les données mais aussi l’identification du profil de sécurité afin que l’extension de plus bas niveau ait de quoi faire des vérifs supplémentaires et valider les droits accordés ou pas.
Et puis il faut en finir avec les trop nombreuses versions d’Android qui ne sont maintenues que par les constructeurs ou vendeurs de réseaux mobiles. On veut un OS unique avec une mise à jour unifiée des composants de base. Les vendeurs peuvent inclure ou pas une bibliothèque option elle, mais s’ils l’incluent cette blibliothèque doit pouvoir être mise à jour séparément depuis leur source réelle et non pas l’assembleur de la ROM.
La ROM critique de base ne devrait même pas avoir de navigateur intégré et ne contenir qu’un jeu simplifié d’algorithmes de sécurité (SHA3, DES, RSA, AES) si possibles supportés par le matériel uniquement pour valider l’image du noyau (uniquement ce qui est nécessaire dans le bootloader), tout le reste au dessus devrait utiliser ses propres algos ou extensions désinstallables, cela ne devrait jamais être permanent dans une ROM même si c’est installé dans des sandbox virtualisées.
#44
Salut,Donc, en gros le “retour usine” du téléphone ne sert à rien?Si on est infecté, le malveillant aura toujours la possibilité de se réinstaller via le root auquel il a “souscrit” lors de son intrusion dans le portable?Est-il possible de supprimer ce root et de l’identifier?Merci par avance,Cdt.