Spécial sécurité : Chrome n'est pas nickel

Sommaire :

- 1 - Google Chrome, épisode 1 : déjà des questions de sécurité 

- 2 - Chrome, ep.2 : solide « by design » ?

- 3 - Chrome, ep.3 : le « c’est pas nickel » des ténors sécu

- 4 - Chrome ep.4 : Le beau, le bug et la beta

- 5 - EEE, l’Inspecteur Gadget du hack

1) Google Chrome, épisode 1 : déjà des questions de sécurité

Voilà probablement la page de publicité Internet la plus répandue dans le monde : Google lance une préversion de Chrome, son navigateur. Plus sécurisé, plus « Open Source », plus rapide, sa sortie provoque déjà des remous. Tristan Nitot, de la Fondation Mozilla Europe, en a illico publié deux articles, l’un titré «  Pourquoi Google a sorti Chrome » , l’autre «  A propos de Google Chrome et du reste ». John Lily, le CEO de Mozilla, y va également de son couplet de bienvenue. Qu’on le veuille ou non, derrière toute cette dialectique, Chrome est bel et bien un concurrent direct de Firefox et de tous les membres du front commun « anti Internet Explorer ». Concurrent officiellement non agressif, mais concurrent tout de même. Car on ne choisit pas Chrome ou Firefox comme solution alternative à Internet Explorer, on choisit Chrome ou Firefox parmi les concurrents d’Internet Explorer. La nuance est de taille.

D’ailleurs, très finement, Lily dépeint avec une précision toute chirurgicale la place que pourrait prendre Chrome : «  Chrome will be a browser optimized for the things that they see as important ». Or, lorsque Google, la prima dona du web, considère quelque chose dans le monde IP comme étant important, cette chose le devient immanquablement. La face du monde peut très bien ne pas changer, mais en attendant, il serait sot d’oublier que Google est à Internet ce que Microsoft est à la bureautique et aux systèmes d’exploitation. Les matheux appellent çà un «  système référentiel », les politiciens un « diktat », les historiens «  le fait du roi », les dictateurs «  la raison d’Etat » et les journaux informatiques «  une révolution technologique furieusement tendance ». A l’aube d’une ère nouvelle et merveilleuse où le monde informatique entier sera « cloudifié », atomisé, virtualisé et dématérialisé – et donc totalement dépendant des infrastructures Internet et des navigateurs -, le pari que les équipes de Google viennent de lancer dépassent très largement ce que certains voient comme « un navigateur de plus ».

2) Chrome, ep.2 : solide « by design » ? 

Il semble donc que le nouveau venu ait des arguments sérieux. A commencer par la possibilité d’ouvrir simultanément deux instances de Chrome pointant chacune sur plus d’une soixantaine d’adresses différentes. Une aubaine inespérée pour tous ceux qui souffrent des « limitations GDI » et autres gels de navigateur. GNU Citizen explique d’ailleurs que le mot « instance » n’est peut être pas nécessairement le meilleur des qualificatifs dans le cas présent. On devrait dire plus exactement « réentrance ». Un distinguo qui, d’un point de vue sécurité et gestion mémoire, est d’une importance capitale, puisque chaque onglet serait en fait une instance à elle toute seule. Qu’une page provoque un crash, et seul l’onglet passe de vie à trépas, sans entraîner dans sa chute ses dizaines de voisines (du moins en théorie… certains exploits prouvent déjà le contraire). Ce n’est pas pour autant une raison de croire que Chrome, pour de vagues raisons liées à son caractère Open Source ou à sa nouveauté, soit à l’abri des bugs, erreurs de conception, failles et autres joyeusetés.

3) Chrome, ep.3 : le « c’est pas nickel » des ténors sécu

«  Y’a de l’ASLR déclaré sur certaines bibliothèques, mais pas de « no execute » »… Chrome est donc «  pas aussi mauvais que certaines applications qu’il m’ait été donné de voir… mais sans plus », pense David Maynor, d’Errata .

Guère plus d’enthousiasme de la part de Denis Fisher, de Security News, lequel dit en substance : « Quand on voit les efforts marketing et sécuritaires prodigués par la Fondation Mozilla d’une part, et les scores que continue à afficher Internet Explorer, force est de constater qu’il en faut beaucoup pour changer les habitudes. Peu de chances donc que Chrome puisse faire mieux et plus rapidement. Hormis peut-être d’un point de vue médiatique. Mais on ne gagne pas une guerre des navigateurs en remportant une bataille des communiqués. Passé les premiers effets d’annonce, le lustre de Chrome perdra de son éclat ».

Le  Security Focus, pour sa part, s’intéresse à la génération de code automatique accélérant Javascript, à l’isolation de l’interprétation des javascripts en question entre chaque instance du navigateur (entre chaque onglet devrait-on dire). Les détails techniques sont d’ailleurs fort bien vulgarisés dans une bande dessinée qui rappelle un peu le graphisme et l’approche des aventures d’Anselme Lanturlu.

4) Chrome ep.4 : Le beau, le bug et la beta

Si, comme le laisse clairement entendre Google, l’arrivée d’un navigateur « maison » ne pourra qu’améliorer l’interactivité de certaines applications, on peut craindre également l’apparition d’un « second effet Johnny » ou de prometteuses campagnes de Google Hacking d’un genre nouveau, puisque pouvant également s’appuyer sur le poste client. D’ailleurs, Mikko Hyppönen de F-Secure, dans un billet consacré aussi à la sécurité de Chrome, émet deux remarques : «  enfin un navigateur qui ne consomme pas tout l’espace mémoire »… détail technique qui risque de lui garantir un certain succès. Mais ce succès, cette visibilité, pourrait se retourner contre Chrome, en attirant également l’attention des pirates et auteurs de malwares. Et de signaler l’alerte d’Aviv Raff à propos d’une double faille héritée, l’une dans le Webkit (une « base » de Safari utilisée par Chrome), l’autre de Java, failles dont la combinaison pourrait servir de vecteur d’attaque. L’inventeur du procédé consacre, sous forme de « preuve de faisabilité » inoffensive, une page Web à cet exploit. Rish Narang en fait de même avec un autre exploit capable précisément de faire crasher le navigateur et tous ses onglets... en d’autres termes de contourner la protection « bac à sable » qui isole chaque instance.

Ne perdons pas de vue que Chrome n’a pas encore dépassé le stade de la préversion et que toutes ces découvertes d’imperfection sont on ne peut plus normales… découvrir un « bug dans une beta » ne relève pas de l’exploit mais du debuging d’application. Il serait par ailleurs téméraire de porter un jugement favorable ou non sur la solidité du programme, tout comme il serait inconscient de l’intégrer dès aujourd’hui dans un environnent de production.

5) EEE, l’Inspecteur Gadget du hack 

Qui n’y a pas pensé ? Après s’être fait installé entièrement ou en partie sur les systèmes les plus exotiques – routeurs Linksys, PDA, iPhone, clef USB exigües, machines virtuelles…-, voilà que Backtrack s’invite sur l’Asus EEE. A lire dans les colonnes de I-Hacked. Certes, il y avait déjà eu par le passé quelques tentatives plus ou moins bien détaillées. Et notamment celle de Tech Dude, plus focalisée sur la mise en œuvre de la partie Aircrack. C’est d’ailleurs là une performance de hacker purement intellectuelle, les performances de l’extension WiFi de l’EEE oscillant entre « pas terrible » et « peut mieux faire ». Du moins à l’encan de ce que peut exiger un RSSI en quête d’un véritable outil d’audit. Le « how to » de I-Hacked est clair, progressif, quasi complet et très didactique. A suivre si l’on ne souhaite pas batailler avec les pilotes parfois très spécifiques de cette plate-forme.