Google corrige l'importante faille de sécurité d'Android

Florian Innocente |

Google a corrigé la faille de sécurité concernant quasiment tous les terminaux sous Android. Une vulnérabilité capable de transformer, à l'insu du système, une app en un cheval de Troie (lire 99 % des appareils Android touchés par une énorme faille).

Google a indiqué à ZDNet que le correctif avait été envoyé à ses partenaires matériels et qu'il leur incombait maintenant de le distribuer auprès de leurs utilisateurs. Samsung s'y serait déjà attelé.

Un scan des apps présentes sur Google Play n'a révélé aucune application compromise, a ajouté Google. Quant aux logiciels récupérés par d'autres biais que cette boutique, ils peuvent être contrôlés à distance par Google via une fonction similaire intégrée à Android.

Image : Android-MT

Tags
#android #sécurité
avatar hipkiss | 
Et Adobe corrige Flash aussi. 11.8 et des poussières.
avatar -oldmac- | 
Dommage, personne n'a encore utilisé cette faille. Ça aurait été amusant de voir le résultat ...
avatar Oh la belle Pomme | 
@iOShit4Noob : +1 aussi. Je ne comprend pas ce besoin de vouloir le malheur chez les autres. Ca t'apporte quoi wolf ? Etre pro Apple t'a (toi aussi) frustré ? Sache, jeune homme, que Pomme ou pas, rien est infaillible, et perso je ne serais pas spécialement dans un état d'euphorie si l'un de tes comptes (ou l'une de tes machines) se faisait un jour attaquer ou hacker. M'enfin, on trouve son plaisir où l'on peut.
avatar -oldmac- | 
Non ce qui est intéressant c'est de voir que la NSA à participer à l'élaboration de la sécurité d'Android, d'après le communiqué officiel …
avatar lol51 | 
putain voilà une belle brochette de monsieur la morale...
avatar tigre2010 | 
@iOShit4Noob Oui et dommage que personne n'ait détourné le jailbreak a des fins nuisibles histoire de voir jusqu'où va ton sens de l'humour.... Bien tenté mais hélas il y eu quelque histoires à ses débuts.
avatar kalynoh | 
Tu peux encore espérer, si les mobiles doivent être mis à jour pour être protégés, il n'y en a pas beaucoup qui le seront.
avatar Kevelian | 
Donc maintenant on sait clairement que Google contrôle ce qui se trouve dans les mobiles Android
avatar Zash_FX | 
@iPadOne : Comme Apple, et sans doute MS, c'est l'inverse qui serait inquiétant en fait.
avatar napuconcture | 
Oui depuis quelques mois sur les appareils qui ont le Play store de déployé, et via l'application Services Google Play. Dans les paramètres il y a une nouvelle option coché par défaut, justement pour permettre de vérifier les apk via les services de Google
avatar eipem | 
@DeanLubaki : Encore faut-il que l'app soit détectable et pas diluée dans le système comme le malware OBAD. Si l'app en question se contente de déposer le code malveillant, Google pourra bien effacer l'app à distance, le malware sera toujours là. Mais oui, Apple a elle aussi un système de désinstallation à distance, pas plus efficace que le système de Google d'ailleurs.
avatar pgo | 
C'est moche de reprendre les discours catastrophes des éditeurs d'antivirus. Sauf si le malware exploite une faille système, ce qui est possible dans tous les systèmes, aucun ne se "dilue" dans le système Android. Que ce soit sur iOS ou Android l'exécution d'une application est cloisonnées (sandboxé). Donc il suffit simplement de désinstaller l'application fautive. Si j'ai bien compris, Obad est exactement comme tous les autres malware Android à la différence près que son code "mute" plus facilement et qu'il utilise le système de "device admin" pour complexifier sa désinstallation. Mais encore un fois, les individus qui installent ce type d'applications sont responsables de leurs négligences. Android n'a pas besoin d'Antivirus.
avatar eipem | 
@ichp : 'Sauf si le malware exploite une faille système, ce qui est possible dans tous les systèmes, aucun ne se "dilue" dans le système Android. Que ce soit sur iOS ou Android l'exécution d'une application est cloisonnées (sandboxé).' Renseigne toi sur le malware OBAD avant de balancer des vérités. Le sandboxing est un choix du développeur, pas une obligation de son code. En l'occurrence il est parfaitement possible qu'un code malicieux sorte du bac à sable. Google autorise les API privées. Que le discours des fabricants d'antivirus soit orienté c'est certain. Ça ne veut pas dire que le système est sûr. Nous courons les mêmes risques sur iOS jailbreaké. Et même si le risque est beaucoup moins important, nous courrons aussi le risque sur l'appstore (cf les app qui activaient le partage Wifi). C'est déjà pas infaillible sur l'appstore avec les équipes de validation, c'est forcément pire sans ces équipes. Affirmer le contraire est absurde.
avatar pgo | 
"Le sandboxing est un choix du développeur, pas une obligation de son code." !!!!!! C'est strictement faux !!!!! 1. Une application installée à un UID et un GID de fixé par le système ce qui l'empêche d'accéder au reste du système. Une application est donc cloisonnée d'un point de vue système. 2. Chaque application est lancée dans une VM Dalvik clonée propre à l'application. Une application est donc cloisonnée d'un point de vue exécution. La seule marge de manœuvre d'un développeur est de fusionner les droits systèmes et la VM d'exécution pour des applications ayant la même signature, donc provenant du même développeur. Franchement, si tu arrives à me prouver le contraire, je serais très curieux d'avoir la moindre petite source...
avatar eipem | 
@ichp : Et il fonctionne comment ce sandboxing ? Je croyais qu'il y avait un vrai explorateur de fichier dans Android ? C'est pas une des caractéristiques d'Android que le libre accès des fichiers ? Si une app peut enregistrer du code où elle veut elle peut bien enregistrer du code malicieux dans le répertoire système. Donc bon, le sandboxing d'Android... Et comme le faisait remarquer Byte_order, tu peux très bien exécuter du code à l'extérieur de la machine Dalvik. Donc dans un cas comme dans l'autre, le sandboxing est inopérant contre un code malicieux caché dans une app.
avatar eipem | 
@bibi81 : Et il n'est pas possible de demander à du code de s'exécuter au démarrage sans rooter l'appareil ? Android autorise les apps a exécuter du code extérieur, c'est le cas de Flash notamment. Comment tu empêches une app de télécharger et exécuter du code ? Les portes d'entrée sur Android sont trop nombreuses. Un exemple simple. Tu fais un navigateur censé intégrer un moteur Flash maison. Dans ce navigateur tu crées de toute pièce une faille qui va donner accès au système. Ce code malicieux est indétectable par Google avant qu'il n'ait été téléchargé sur l'appareil.
avatar pgo | 
Tu dis n'importe quoi ! Ta vérité repose sur des exemples faux ou dont tu ne comprends pas le principe. 1/ "explorateur de fichier dans Android" Oui seulement pour la "mémoire externe", aucun fichier système n'est accessible. 2/ "Une app peut bien enregistrer du code malicieux dans le répertoire système." Non elle ne peut pas. En plus tu ne sembles même pas connaître les rudiments de la sécurité Linux. Même si une application avait accès aux fichiers systèmes c'est par pour autant qu'elle pourrait les modifier. C'est la base de la sécurité Linux ! 3/ "tu peux très bien exécuter du code à l'extérieur de la machine Dalvik." Tu interprètes les propos de Byte_order. Il est effectivement possible du code dit natif (en C/C++), mais les API sont très limités et l'exécution est également sanboxée tout comme l'accès au système. 4/ "demander à du code de s'exécuter au démarrage sans rooter l'appareil" Bien sur que oui. Au démarrage, le système Android envoie un événement aux applications le souhaitant pour qu'elles puissent s'exécuter. Ça n'a rien d'un hack. Juste l'utilisation standard et prévue du bus événementielle (iBinder) d'Android. D'ailleurs il est possible de voir les applications qui se lance au démarrage dans la liste des permissions. 5/ "c'est le cas de Flash notamment. " Flash avait bénéficier d'un accès privilégié conclu entre Google et Adobe. Il n'était donc pas sur la couche application mais sur la couche Framework. Comme WebKit sur iOS. Et oui on peut créer une application Javascript sur iOS, comme il était possible de créer une application Flash sous Android ! 6/ "Les portes d'entrée sur Android sont trop nombreuses." Absolument pas. La seule différence avec iOS concerne la distribution des applications qui n'est pas contrôlée pas le constructeur. 7/ "Tu fais un navigateur censé intégrer un moteur Flash maison. Dans ce navigateur... blablabl" Tu t'enfonces. Ton moteur Flash maison sera soit codé en Java (Dalvik) soit avec le NDK (C++ limité). Ça ne compromet donc pas plus le système qu'une autre application. Le plus gros risque est que le moteur que tu as codé est des failles et fasse planter les applications qui tournent dessus. C'est tout.
avatar eipem | 
@ichp : 'Non elle ne peut pas. En plus tu ne sembles même pas connaître les rudiments de la sécurité Linux. Même si une application avait accès aux fichiers systèmes c'est par pour autant qu'elle pourrait les modifier. C'est la base de la sécurité Linux !' Tu as besoin d'un code super utilisateur sudo pour installer des trucs sur Android ??? Non. Donc on est pas du tout sur un système Linux comme Debian par exemple. Faut pas confondre le mot de passe sudo et le mot de passe de ton compte Gmail...
avatar eipem | 
@W.B.M : Par défaut oui. Et je n'ai jamais prétendu le contraire. Ce que je dis par contre c'est qu'une faille du système (et il y en a sur Android comme partout ailleurs) peut parfaitement être exploitée depuis une app du playstore parce que Google autorise les apps à télécharger et exécuter du code. Je ne dis pas qu'Android est plus troué que iOS ou quoi que ce soit d'autre. Je dis qu'une app téléchargée sur le PlayStore ne garantis pas la sécurité. Parce que Google peut bien scanner ce qu'elle veut, elle n'empêche pas les apps du PlayStore de télécharger et exécuter du code. C'est un des points qui font qu'Android est plus flexible qu'iOS, mais du coup c'est une porte d'entrée supplémentaire à l'exploitation d'une faille.
avatar eipem | 
@joneskind : 'Par défaut oui. Et je n'ai jamais prétendu le contraire.' En fait si. J'ai prétendu le contraire. Mais ça ne change rien au problème.
avatar pgo | 
... ? Que vient faire sudo la dedans ? Tu dois pas être très vieux pour faire l'amalgame entre sudo et root. Bref, Android EST un système Linux. Google a "juste" implémenté des couches applicatives (librairie, framework, application) pour l'ajuster au contrainte mobile (sécurité, UI, SDK).
avatar eipem | 
C'est une blague ? sudo c'est la commande Linux pour accéder aux droits root ! C'est surtout toi qui a l'air de ne rien connaitre du tout à Linux oui. Tiens, un peu de culture... http://doc.ubuntu-fr.org/root "Bref, Android EST un système Linux. Google a "juste" implémenté des couches applicatives (librairie, framework, application) pour l'ajuster au contrainte mobile (sécurité, UI, SDK)." Non. Android c'est un noyau Linux qui fait principalement tourner une VM Java. Rien à voir avec un Linux. Tu peux faire la même chose avec une VM qui fait tourner Windows sur Linux. T'auras bien un noyau Linux mais la VM sera aussi faillible que peut l'être Windows par rapport à Linux. T'auras juste une couche inaccessible si la machine Java est bien codée. Sauf qu'on sait pertinemment que ce n'est jamais le cas, tout système étant faillible.
avatar pgo | 
Mon pauvre joneskind... Les droits Linux dépendent de l'utilisateur. Et les "droits root" ,comme tu dis, s'obtiennent en se connectant en tant qu'utilisateur root (c'est à dire un utilisateur UID 0). Sudo est un programme facultatif pour simplement lancer des commandes en tant qu'un autre utilisateur, root ou non. La configuration se fait en général de le fichier sudoers si ça t’intéresse. Donc quand tu dis "Tu as besoin d'un code super utilisateur sudo pour installer des trucs sur Android", j'arrive à interprèter ton idée mais ça ne veut pas dire grand chose. Pour le reste, je ne réponds pas, c'est juste grotesque. Tu associes un JVM avec de la virtualisation système. Mais je pense que tu es un jeune IT,... donc l'obsession de penser tout savoir ;)
avatar eipem | 
@ichp : 'Flash avait bénéficier d'un accès privilégié conclu entre Google et Adobe. Il n'était donc pas sur la couche application mais sur la couche Framework. Comme WebKit sur iOS. Et oui on peut créer une application Javascript sur iOS, comme il était possible de créer une application Flash sous Android ! ' Non. Webkit c'est un moteur html5/CSS. C'est pas de l'exécutable. Ça n'a absolument rien à voir avec Flash. Tu mélanges tout.
avatar pgo | 
Effectivement Webkit n'est plus un moteur Javascript, les projets ont été fragmenté. Je ne sais pas comment s'appelle le moteur Javascript sur iOS, mais peu importe, il y'en a un et les développeurs peuvent l'utiliser.
avatar eipem | 
@ichp : 'Tu t'enfonces.' Android est infaillible ? Ça serai bien le premier OS de tous les temps et Google devrait être maitre du monde... Je t'explique que sur Android, les apps du playstore ont l'autorisation de télécharger et exécuter du code. Qu'à partir de là, n'importe qui peut exploiter une faille du système pour injecter du code malicieux via une app du playstore...
avatar pgo | 
Ça devient n'importe quoi... Le principe d'une application c'est justement d'exécuter du code ! Tu as dit qu'un malware peut se "diluer" et "s'injecter" dans le système Android. Moi je te dis que c'est impossible étant donné les mécanismes misent en place. On est pas sur Windows XP où dès qu'on travaillait en admin, on pouvait se retrouver avec un PC complètement infecté. Après si une faille système est exploitée, alors la effectivement tout est possible. Mais ça c'est n'importe qu'elle système, donc pas la peine de s’étaler la dessus.
avatar eipem | 
Si je m'étale dessus comme tu dis c'est pour te faire comprendre que le PlayStore n'est PAS une garantie de sécurité. Sur iOS, toute app qui voudrait récupérer et exécuter un code EXTERIEUR est refusée. Donc il est rigoureusement impossible qu'une app inoffensive à la base devienne malveillante par la suite. Sur Android, Google laisse les apps télécharger du code exécutable. Ça veut dire qu'une app peut très bien passer la "validation" de Google et télécharger ensuite une portion de code qui la modifiera, ou qui exploitera une faille du système. C'est pourquoi le Playstore peut bien scanner tout ce qu'il veut, ça ne sert à rien.
avatar pgo | 
Rien compris. Ce que tu dis est identique sur les deux plateformes. Sous iOS, une webapp "télécharge du code exécutable" depuis le serveur (code javascript), et une app en Objective-C peut faire de l’introspection et de la réflexion. Après, je suis d'accord que le Google Play n'est pas un garantie de sécurité. Mais l'utilisateur doit l'être.
avatar pgo | 
Je suis d'accord avec toi. Mais le message que j'essaie de faire passer est qu'Android ne repose pas sur les anciens modèles d'OS. Sous Windows (et les autres), un utilisateur peut compromettre l'ensemble du système, qu'il y'est une faille ou non. Sur Android (et iOS, WP, MACOS/MAS), un utilisateur ne peut plus compromettre l'ensemble du système sans l'exploitation d'une faille. C'est une différence capitale dans l'approche de la sécurité.
avatar eipem | 
@iOShit4Noob : Oui... C'est un anti-virus qui va scanner le code pour détecter un malware connu. Elle n'a pas les moyens de détecter un code "mailicieux" avant qu'il n'ait déjà opéré. Un exemple simple: t'as une app qui demande un accès à un serveur et à tes contacts - c'est une app banale qui n'a aucune chance d'être éliminée. Le serveur en question récupère tous tes contacts et envoie le SMS corrompu d'OBAD. Tu fais quoi ? Une autre app demande à un serveur de récupérer un fichier particulier, masqué par une extension .truc et l'enregistre dans un dossier système. Le fichier lui-même est exécuté au redémarrage. Là encore, comment tu le détectes ?
avatar pgo | 
Tu dois parlé de l'application Path (et de tant d'autres) qui ont siphonné tous les contacts des utilisateurs iPhone ? - "SMS corrompu OBAD" A ce jour, il n'y'a pas de faille dans la gestion des SMS sous Android (il y'en a eu sous iOS). Ce n'est pas le SMS qui est corrompu. C'est le lien contenu dans le SMS qui redirige vers une application vérolée. Après il faut que l'utilisateur télécharge l'application (en ayant décocher l'option ne permettant pas de le faire pas défaut), ne se pose pas la question pourquoi l'application "fond d'écran" demande l'accès aux sms et aux contacts, installer l'application, accepter que l'application gère les options d'administration (attention il ne s'agit pas d'être administrateur - root - du système !). Piouf... - ", masqué par une extension .truc et l'enregistre dans un dossier système." Techniquement impossible.
avatar eipem | 
@iOShit4Noob [10.07.2013 - 18:49] Combien de temps ces apps tournent-elles sur les serveurs de Google ? Les IP des serveurs de Google sont-elles dynamiques ? Tu ne crois pas qu'une bonne partie d'entre elles sont connues ? Tu crois pas qu'un dev peut facilement désactiver son code en fonction de l'IP du système qui l'héberge ? De plus, une app peut très bien avoir du code dormant, qui ne se mette en route qu'au moment où le développeur en a décidé ainsi. Sur Android, l'immense majorité des systèmes ne sont pas mis à jour par les constructeurs. Un hacker a tout le loisir d'attendre un an avant de mettre en route son bot. Ça s'est toujours fait, quelque soit les OS.
avatar lol51 | 
NON, le risque est important, il suffit d'une minorité d'appareil android infecté pour foutre la merde.
avatar Abudah237 | 
Ça fait des années que la faille existe, rien n'indique qu'elle n'aie pas été utilisée. Et comme la plupart des téléphones n'auront jamais de correctifs, ce n'est pas fini.
avatar pgo | 
Le système Android n'a rien à voir avec Windows. Ceux qui déballent le contraire montrent à quel point ils n'y connaissent pas grand chose. En fait l'architecture Android et d'iOS sont très proches. Et aucun système n'est à l'abri d'une faille système. Il n'y pas si longtemps l'iPhone se jailbreakait en visitant une simple page Internet.
avatar eipem | 
@ichp : 'En fait l'architecture Android et d'iOS sont très proches.' Rien à voir. Android fait tourner une machine Java (Dalvik) sur un Linux et n'exécute aucun code Linux natif. iOS fait tourner du code natif sur le noyau UNIX Darwin.
avatar eipem | 
@byte_order : Ok chef ! Je la remets dans le pantalon ^_^ Et merci pour tes explications !
avatar boccob | 
J'ai envie de dire ... Et alors ? Aujourd'hui c'est Android, Hier c'était Apple avec JailBreakME, demain ça sera MS. C'est le jeu. Pour 500 dev chez Apple ou Google (ou les autres) il y a des dizaines de milliers, ou plus, de hacker en herbe qui tente de casser l'OS. Il y aura toujours une faille. Le but est de savoir si elle est facilement exploitable, si elle peut faire beaucoup de dégat, etc etc. Dans chaque cas, ça crit au loup sans qu'il n'y ait eut d'impact.
avatar YanDerS | 
c'était une allocution d'elamapi, le médiateur pour la Paix de l'internationale des Geeks bavards ;-))

CONNEXION UTILISATEUR