Quentin Berdugo, consultant en sécurité chez EdelWeb

L'architecture IA-32 (x86) n'a pas nativement de fonction de virtualisation. Elle s'y prête assez mal, car il faut contourner de manière logicielle ses limitations matérielles. Le problème tient au fait que certaines instructions ne sont pas interprétées de la même façon par le microprocesseur en fonction de leur contexte d'exécution.

Dans l'architecture IA-32, le processeur propose plusieurs modes de fonctionnement. En mode protégé, il distingue différents contextes d'exécution, sur lesquels les systèmes d'exploitation s'appuient pour gérer la séparation des privilèges entre le noyau et les applications. L'objectif est d'éviter qu'une application défaillante ou malveillante ne compromette la stabilité ou la sécurité du système d'exploitation. Ces contextes sont appelés rings . Le noyau est exécuté en ring 0, le plus privilégié, tandis que les applications, exécutées en ring 3, n'ont accès qu'à un nombre restreint d'instructions. Pour accéder aux ressources, les applications sont contraintes de faire appel aux fonctions proposées par le noyau, qui joue le rôle de médiateur entre elles et le matériel. Le système d'exploitation peut alors coordonner l'accès aux ressources (partage de la mémoire et ordonnancement de la charge processeur), fournir une couche d'abstraction (fichiers sur le disque, sockets TCP-IP, etc.) et imposer des mécanismes de sécurité (tels des permissions sur les fichiers ou du filtrage réseau).

Pour disposer d'une machine virtuelle, il faut créer un programme qui exécute du code pour le compte d'un système d'exploitation en lui donnant l'illusion qu'il a accès aux ressources. Or, si on tente d'exécuter un système d'exploitation comme s'il s'agissait d'une application, le noyau de ce dernier sera exécuté en ring 3, et non en ring 0, pour lequel il a été conçu. Par conséquent, le système virtualisé va « planter » à la première tentative d'accès à une ressource nécessitant les privilèges ring 0. Si, à l'inverse, il est exécuté en ring 0, la machine virtuelle aura autant de privilèges que le système hôte. Cette solution n'estpasacceptable, car le dysfonctionnement ou la compromission d'une machine virtuelle aura un impact sur le système hôte et toutes les machines virtuelles que celui-ci héberge.

Pour résoudre ce problème, il ne subsiste que des approches de contournement. Deux d'entre elles se dégagent. La première, adoptée parVMware, est la translation binaire, qui consiste à intercepter les instructions nécessitant les privilèges liés à l'utilisation de ring 0 pour les traduire à la volée et en simuler les résultats. La réécriture dynamique du code est néanmoins coûteuse en termes de performances, car elle démultiplie le nombre de cycles nécessaires à l'exécution d'instructions.

La seconde approche, mise en oeuvre dans le projet open source Xen, est la paravirtualisation. Il s'agit cette fois de modifier le système d'exploitation à virtualiser pour lui permettre de fonctionner sans l'exécution de code en ring 0. C'est une meilleure approche en termes de performances, mais l'inconvénient majeur est qu'il faut pouvoir réécrire une partie du système d'exploitation.

Récemment, Intel et AMD ont implanté leurs technologies de virtualisation au coeur de leurs processeurs. Bien que mutuellement incompatibles, les technologies Vanderpool d'Intel et Pacifica d'AMD partagent le même principe : introduire un nouveau contexte d'exécution ayant des privilèges plus élevés que le ring 0. En exécutant le système hôte (appelé hyperviseur) dans ce mode et les systèmes virtualisés en ring 0, on garantit la séparation des privilèges entre l'hyperviseur et les machines virtuelles, tout en permettant à ces dernières de s'exécuter dans leur mode natif.

Joanna Rutkowska, chercheuse en sécurité chez Coseinc, a cependant pris ce concept à défaut. (lire l'encadré). Son programme Blue Pill illustre une nouvelle forme de code malicieux utilisant les fonctionnalités matérielles - et non des techniques logicielles - des nouvelles puces pour se dissimuler en dehors du système d'exploitation. Deux particularités rendent la démonstration très intéressante. La première est qu'elle n'exploite aucune vulnérabilité d'implémentation : il s'agit donc bien d'une faille dans la conception de l'architecture de virtualisation. Et même si l'auteur a démontré cette faille sous Windows avec un processeur AMD, elle indique qu'il n'y a pas, a priori, de raison technique pour qu'elle ne puisse pas être portée sur n'importe quel système d'exploitation et sur processeur Intel. La seconde particularité est que le concept n'est pas fondé sur des codes masquant son mode de fonctionnement. Une fois exécuté, le code de Blue Pill est, quant à lui, indétectable par le système d'exploitation, et donc par les antivirus, bien que son mode de fonctionnement soit connu. Pour le détecter, il faudrait que l'antivirus réside lui-même dans l'hyperviseur. Joanna Rutkowska précise que s'il existait un moyen de détecter Blue Pill depuis le système et d'avoir accès à l'hyperviseur depuis une machine virtuelle, cela constituerait une défaillance de la technologie de virtualisation, conçue pour donner au système virtualisé l'illusion parfaite d'une machine réelle. Elle évoque plusieurs pistes pour se protéger contre la réalisation de cette attaque. Mais, outre la désactivation des fonctions de virtualisation, elle ne présente aucune solution à court terme. Reste à voir comment l'industrie va réagir à cette découverte qui a terni la réputation de ces technologies après leur lancement commercial.