Google ne peut plus corriger les vulnérabilités des versions d'Android les plus populaires
Google a expliqué pourquoi il n'y aurait pas de correctif pour la dernière faille de sécurité (en date) recensée dans le moteur de rendu de pages web d'Android 4.3 ou antérieures.
C'est à l'intérieur de WebView qu'est logée cette faille (mais elle n'est pas la seule). Ce composant système permet l'affichage des pages web et l'exécution de code JavaScript. Depuis Android 4.4 KitKat, WebView a changé de cheval, sautant du moteur WebKit qu'utilise Apple à Blink mis au point par Google et régulièrement mis à jour. WebView, à l'origine, est utilisé dans Android Browser, le navigateur de base fourni avec l'OS. WebView peut aussi servir à des éditeurs tiers dont les applications ont besoin d'afficher des contenus web ou des publicités.
Sur son blog, Tod Beardsley s'alarmait il y a quelques jours de la véritable boite à outils offerte par ces failles de sécurité à des malandrins qui souhaiteraient par exemple détourner des utilisateurs vers des sites fallacieux et récupérer des données privées. Il s'étonne encore que Google soit prêt à corriger une faille dans le composant AudioPlayer de ces anciens Android mais pas à refermer dans WebView une des plus belles portes d'entrées pour les amateurs de vulnérabilités.
Membre de l'équipe sécurité d'Android, Adrian Ludwig est revenu sur le sujet pour expliquer la position de son employeur. Comme indiqué précédemment, Google n'apportera aucun correctif à WebView dans ces anciennes versions d'Android (Jelly Bean n'est pas si vieux, sorti mi-2012 sa dernière révision date d'octobre 2013).
Google, explique-t-il, n'a plus les moyens de mettre à jour un composant aussi complexe et qui, de par sa nature open source, est en constante évolution. Cet effort a été encore fait récemment mais ce n'est plus tenable :
À lui seul, WebKit représente 5 millions de lignes de code et des centaines de développeurs ajoutent des milliers de nouvelles modifications chaque mois, de sorte que, dans certains cas, appliquer des correctifs de vulnérabilité sur une branche de WebKit vieille de 2 ans et plus impose des changements sur des volumes de code importants et ce n'était plus gérable de le faire de manière fiable. Avec les progrès d'Android 4.4, le nombre d'utilisateurs qui sont susceptibles d'être affectés par des problèmes de sécurité hérités de WebKit diminue chaque jour, alors que de plus en plus les gens se mettent à jour ou achètent un nouveau terminal.
Mécaniquement, il est vrai que la part de risques va aller décroissante, mais il y a encore de la marge. En se basant sur les statistiques de Google, les 4 version d'OS concernées - Froyo, Gingerbread, Ice Cream Sandwich et Jelly Bean - pèsent encore pour 60,9% des connexions faites sur Google Play. Dans le lot évidemment certains utilisent probablement Chrome plutôt qu'Android Browser. Restent les apps tierces.
Les solutions répétées par Adrian Ludwig sont multiples. Pour s'affranchir des risques posés par les failles, les utilisateurs peuvent passer à KitKat (encore faut-il que cela soit possible pour leur terminal…). Ou, plus simplement, installer soit Chrome soit Firefox qui n'utilisent plus ou pas le WebView version WebKit. Chrome marche à partir d'Android 4.0 et Firefox fait mieux encore en remontant jusqu'à Android 2.3 (Opera utilise aussi Blink). Sans oublier que Chrome figure en bonne place et par défaut sur de multiples téléphones de grandes marques.
D'autres solutions sont proposées aux développeurs qui utilisent l'ancien WebView, comme de suivre les recommandations de Google en termes de sécurité pour éviter le chargement de sites litigieux ou, carrément, d'intégrer leur propre moteur. C'est vers ce type d'applications "sûres" que les utilisateurs doivent aller, en les choisissant sur Google Play.
Adrian Ludwig insiste sur le fait que Google ne se contente pas de mettre à jour l'OS du moment, mais qu'il tient à jour les deux dernières versions en date.
@keyzone :
Mais est-ce que cette faille touchait les versions précédentes ?
De plus, quel est le pourcentage d'iOS 5 encore actifs ?
De mon point de vue, cela reste quand même principalement de la responsabilité de Google que de corriger cette faille. Ok, c'est complexe mais c'est leurs choix stratégiques (mode de diffusion d'Android, passage à Blink) qui, tout en restant tout à fait défendables, conduisent à cette problématique. Cela ne dédouane pas non plus les constructeurs de leur propre responsabilité parce qu'ils utilisent un OS libre et gratuit.
Et bien justement, c'est de Google dont il s'agit, qui utilise webkit dans certaines versions d'android.
Oui mais leur OS était à l'époque basé exclusivement sur Webkit. Je trouve donc que c'est de leur responsabilité.
Leur OS est basé sur webkit, Java, et bien d'autres technologies, je pense que Google doit savoir ou mettre la limite, ils ne peuvent pas s'occuper de la maintenance de tout cela. Evidemment, ils poussent des patches dans quelques directions, et pourraient certainement faire mieux, mais ils ne sont pas là pour faire tourner 50 sociétés et leur empêcher de faire leur travail!
"je pense que Google doit savoir ou mettre la limite"
Apparemment leur limite est au-delà de 61% d'utilisateurs. Plus de la moitié. Ouais, ça semble très raisonnable oO
Waouw, un commentaire constructif et intelligent dans le flux d'idiotie des lecteurs ici! Merci Akerloof!
@Ast2001
Je ne saurais que trop être d'accord avec toi. Et ça me fait plaisir.
"À lui seul, WebKit représente 5 millions de lignes de code et des centaines de développeurs ajoutent des milliers de nouvelles modifications chaque mois, de sorte que, dans certains cas, appliquer des correctifs de vulnérabilité sur une branche de WebKit vieille de 2 ans et plus impose des changements sur des volumes de code importants et ce n'était plus gérable de le faire de manière fiable."
Cette explication me laisse septique ! En effet, l'objectif n'est pas de mettre à jour Webkit dans son ensemble mais de corriger une faille parfaitement identifiée, sur une branche "vieille de 2 ans et plus".
Donc de partir du code source des versions incriminées et d'appliquer les correctifs de vulnérabilité.
À moins que Google ne possède plus le code source de Webkit utilisé dans les distributions je ne vois pas ce qui bloque.
Je me faisais la même réflexion. Le discours de Google qui est "on ne peut pas corriger parce que c'est open-source", c'est se foutre de monde comme c'est pas possible.
@Domsware :
C'est exactement ce à quoi je pensais, je pense que les ingénieurs de Google sont capable de corriger la faille sans mettre à jour les 5000000 de lignes de codes
Il suffit d'utiliser les bons navigateurs ... C'est un faux problème
Non ! Le code concerné peut aussi être utilisé par les applications.
En résumé c'est une brique logicielle de base utilisée par le navigateur par défaut et aussi par nombre d'applications. Donc non, ce n'est pas un faux problème.
Sauf que ce n'est pas à Google de corriger la faille d'un module qu'ils utilisent mais au propriétaire de ce module de le corriger, Apple dans ce cas. Enfin je me trompe peut être.
Et même si Google proposait une mise a jour, la plupart des constructeurs ne la feraient pas et donc le problème serait le même.
Tu te trompes car le module utilisé est Open Source et Google en faisait partie lors du choix d'utilisation du code incriminé.
Cela n'a rien à voir avec Apple.
Apple aussi laisse des failles... iOS 8.1.2 est toujours jailbreakable... Donc un utilisateur Jailbreaké est plus fiable qu'un non Jailbreaké sachant que la faille (ou les) est rebouchée par le programme en lui même.
Mouai...
Le jailbreak peut ouvrir des failles aussi. Et puis ce n'est pas du tout le même genre de failles et donc de risques de sécurité : le jailbreak est fait consciemment par l'utilisateur qui exploite une faille.
Ici il est question de failles de sécurité lors de l'utilisation d'applications utilisant un composant de navigation web. L'utilisateur n'en ayant pas conscience et faisant confiance à l'OS.
"CNNN
CNNN 26/01/2015 - 13:12via iGeneration pour iOS
Apple aussi laisse des failles... iOS 8.1.2 est toujours jailbreakable... Donc un utilisateur Jailbreaké est plus fiable qu'un non Jailbreaké sachant que la faille (ou les) est rebouchée par le programme en lui même."
Mais idiotie !
Le jailbreak justement enleve toutes protections et ouvre toutes les failles.
Dire qu'un iPhone jailbreak est plus sécurisé qu'un iPhone normal, c'est ne vraiment rien comprendre.
@Thegoldfinger :
Les failles sont rebouchées après installation de Cydia.. Donc si on installe pas un SSH je ne vois pas où est le risque, au contraire...
Il suffit d'installer les debian depuis une source officielle.
@CNNN
C'est quand même un peu con ce que tu dis. C'est pas parce que tu utilises une faille que tu la combles en l'utilisant. Donc un iBidule Jailbreaké n'est pas plus fiable qu'un iBidule non jailbreaké. La faille reste ouverte, dans tous les cas. En plus t'es pas à l'abri d'un malware sur les stores "indépendants". Déjà qu'on est susceptible d'en trouver sur l'AppStore alors t'imagines bien que sur un store pas controlé, c'est open bar pour les hackers.
Bref, faut arrêter d'être naïf à ce point.
En fait le titre est faux et devrait être : Google ne veut pas corriger...
@Domsware
Bah dixit Google, c'est trop compliqué pour eux ^_^. Donc de deux choses l'une, soit il est temps d'embaucher des gens compétents, soit il est temps d'arrêter de se foutre de la gueule du monde.
Aujourd'hui seul ms possède cette vertu de suivre les produits assez longtemps pour les questions de sécurité. Après google / apple dans ce domaine c'est pas leur cheval de bataille. Tant que ça reste hype...
Inadmissible de la part de google en tout cas.
Pages