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$.