Chrome

Le piratage de Chrome en 6 étapes

Dans un post en mars, j’affirmais que Chrome était le navigateur le plus sécurisé du marché et louais logiquement la robustesse du système Chrome OS. Mais peu après, durant le concours Pwnium, Sergey Glazunov et Pinkie Pie (en fait, je n’ai pas compris s’il s’agit de la même personne) ont réussi à ouvrir une brèche et ont par la même occasion empoché 60000$.

 

Comment cet exploit, salué par les ingénieurs de Google, a-t-il pu être réalisé ? Dennis Fisher nous décortique sur son blog la méthode qui a été suivie.

Comme vous le savez, la sécurité de Chrome est en grande partie assurée par la sandbox. Eh bien Pinkie Pie ne s’est pas évertué à casser la sandbox, mais l’a contourné. Ah, ce petit coquin de poney rose!

  1. Le départ de ce long chemin commence par un bug au niveau de la fonction « Prerendering » de Chrome. Pour rappel, cela sert à afficher les pages à l’avance pendant qu’elle continue à se charger en arrière plan. Une astuce pour donner l’impression d’un affichage immédiat après une recherche. Afin d’éviter de jouer le son d’une page pendant qu’elle est « pré-affichée », Chrome était sensé bloqué un certain nombre de plugins liés à la page. Hors Pinkie Pie s’est rendu compte qu’en fait tous les plugins se lançaient et en a profité pour exécuter un plugin Native Client.
  2. Voilà donc un morceau de code viral baignant dans la sandbox de Native Client. Normalement, cela ne pose aucun problème, car cette sandbox est encore plus contraignante que celle contrôlant le rendu des pages HTML. Mais Native Client donne accès à un point d’entrée de bas niveau au « GPU command buffer », utilisé pour communiquer des opérations d’accélération graphique au process GPU. Et alors? Eh bien, il  a profité d’un autre bug permettant la corruption du process GPU pour passer une commande spéciale.
  3. Le code viral se retrouve à cette étape dans le GPU command buffer. Pinkie Pie se débrouille pour une créer une arborescence lui permettant d’exécuter tranquillement du code plus élaboré à l’intérieur du GPU process.
  4. Il paraît que le GPU process est lui aussi sous cloche (i.e. que son code tourne dans une sandbox). Mais notre petit cheval rose profite encore d’un bug lui permettant de prendre le contrôle du « renderer » à travers le GPU process.
  5. Le code viral se retrouve désormais dans un « renderer » non privilégié. Hop! Nouveau bug, permettant de prendre le contrôle d’un renderer privilégié à partir d’un renderer non priviligié. Pinkie Pie l’exploite pour prendre le contrôle du process de l’extension manager.
  6. Une fois dans l’extension manager, il profite encore de 2 bugs dans ce process pour d’une part donner l’instruction de charger une extension et d’autre part éviter le message de confirmation d’installation de la dite extension. Il installe donc tranquillement une extension qui s’exécute hors de toute sandbox avec tous les privilèges.

En résumé:

  1. Exploitation du bug du process de prerendering pour lancer un plugin Native Client
  2. Exploitation de l’accès au process GPU par Native Client
  3. Exploitation du bug  permettant la création d’une arborescence dans le GPU buffer
  4. Exploitation de l’accès au process renderer par le GPU process
  5. Exploitation du bug permettant la prise de contrôle du process extension manager
  6. Exploitation de 2 autres bugs permettant d’installer une extension virale

Vous n’avez rien compris? Moi non plus. Heureusement, les ingénieurs de Google ont colmaté au moins un des bugs dans cette chaîne le jour d’après.

C’est inévitable, en rajoutant des fonctionnalités (prerendering, Native Client, extensions), on contrôle forcément de moins en moins la forteresse. Il a quand même fallu passer 6 murs avant de s’introduire et ça, ça valait bien 60000$.

A propos de l'auteur

Christophe

Passionné de high-tech et fasciné par Google, ce blog est un "laboratoire" permettant de m'exprimer sur les différents services et produits de Google, en premier lieu les chromebooks et les appareils Nexus

5 commentaires absolument uniques ont été postés à ce jour

  • On sait combien de temps il a mis pour réussir à trouver toutes les failles ? En tout cas c’est un joli petit pactole 60 000$ !
  • Aucune idée, mais il n’a sûrement pas fait ça en 5 minutes comme on a pu lire ici et là sur le web. Il doit avoir une profonde connaissance de l’ensemble des bugs existants en tout cas pour avoir pensé à en enchaîner 6.
    Le niveau de sécurité des coffres-forts s’évalue par le nombre de mécanismes de protection à passer. Six, c’est déjà un assez haut niveau je trouve.
  • C’est pour ça que tu as pris du retard, tout s’explique, tu étais trop occupé a déjouer la sécurité de chrome :p
  • Non, tu n’y es pas du tout. La mise à jour du site m’a pris pas mal de temps. En revanche, pour Chrome, en une dizaine de minutes, c’était réglé. J’ai juste éprouvé deux ou trois minutes de difficultés sur le 4ème bug !!!!!!!!!!!!!!!!

Laissez vous aussi un commentaire exceptionnel (ou pas !)

Partage cet article par mail