CLOUDBURST: Hacking 3D

Et dire que je pensais que la 3D et le hacking, c'etait bon pour Hackers et les fantasmes du genre. J'avais tort (une fois du plus diront certaines mauvaises langues). Il n'est pas necessairement connu de tout le monde que les produits VMware implementent un certain support 3D depuis un long moment. Et oui, on peut jouer a WoW dans une VMware...

Les fonctionalites 3D etaient tout d'abord presentes et desactivees par defaut. Puis les dernieres versions de Workstation (6.5) et ESX (4.0) ont passe ces fonctions en configuration par defaut. Si vous creez une nouvelle VM, vous aurez le support 3D. Si vous ouvrez une vieille VM, la case sera decochee par defaut mais le code tout de meme execute, resultant en un message d'erreur.

Ces differentes fonctions 3D correspondent en gros aux fonctions de coeur de Direct3D et OpenGL (je n'y connais pas grand chose, j'ai juste Google quelques noms). Les fonctions 3D executees par un programme dans le Guest sont transmises via le driver video a l'Hote qui les "parse" et affiche le resultat. Ce qui est extremement cocace dans le cas de ESX 4.0, c'est que l'Hote parse tout de meme les commandes video, meme si la "console" du Guest est soit un VNC ou un TS . Aucun interet de mon point de vue, mais passons. Le driver video des VMware Tools simplifie le travail, mais n'est pas necessaire a l'exploitation de l'Escape.

L'avantage (pour les partisans du Chaos du moins) est que le traitement de ces commandes 3D implique une quantite impressionante d'operations de copie de buffers. Generalement depuis le Frame Buffer vers le Frame Buffer, ou du Heap vers le Frame Buffer et vice versa. Bien entendu, le Frame Buffer est partage entre le Guest et l'Hote.

La ou ca devient drole, c'est lorsque l'Hote ne verifie pas trop ce qu'il doit copier et ou il doit le copier. Le resultat: deux types de bugs.

1. Le premier est un leak de la memoire l'Hote dans le Guest. L'Hote copie une portion de la memoire dans le Frame Buffer, le Guest lit le Frame Buffer. Bingo part 1.
2. Le second est un write arbitraire (je simplifie la). Le Guest ecrit dans le Frame Buffer. L'Hote copie une portion du Frame Buffer vers sa memoire, et Bingo part 2.

En couplant les deux types de vulnerabilites, on peut tout faire. Fingerprinting de l'Hote, leak des pointeurs necessaires aux etapes suivantes de l'exploitation (l'ASLR n'est donc pas un problem), desactivation du DEP. J'entrerai davantage dans les details dans un prochain post.