Curieuse conjoncture dans la galaxie des émulateurs et virtualiseurs : des vulnérabilités touchant VMWare et QEMU, permettant de "sortir" de la machine virtuelle et ainsi de compromettre la machine hôte, ont été publiées coup sur coup de façon indépendante.

La première vulnérabilité rendue publique concerne QEMU (Réf Lexsi 9750) et a été postée sur la liste de diffusion Debian-Security. Le pilote générique de périphérique en mode bloc ne vérifie pas les limites lorsque l'invité effectue une requête de lecture ou d'écriture. Potentiellement, cela peut être exploité afin de lire ou d'écrire certaines portions de la mémoire de QEMU, et au final de s'échapper du système virtualisé. Notons que plusieurs systèmes s'appuient sur QEMU, comme Xen (en mode HVM) ou KVM.

La seconde concerne VMWare (Réf Lexsi 8483) et a été découverte par CORE Security. Cette fois-ci, il s'agit d'une faille de type traversée de répertoires dans la fonctionnalité de partage de répertoires entre les machines hôte et invitée. Elle permet à un programme invité d'obtenir un accès en lecture et écriture au système de fichier hôte. Comme souvent dans ce genre de vulnérabilité, qu'on retrouve régulièrement dans les applications Web, le problème se situe dans la gestion des différentes façons d'encoder la fameuse chaine ".." (0x2e0x2e en hexadécimal) utilisée afin de remonter d'un cran dans l'arborescence d'un système de fichiers. La vérification de la présence de cette chaine malicieuse est effectué par VMWare avant un appel à la fonction MultiByteToWideChar() (convertissant une chaine "classique" LPCSTR en une chaine Unicode LPCWSTR). Dans le cadre d'une faille précédente très proche de celle-ci (CVE-2007-1744), cette API était appelée avec un argument dwFlags nul, ce qui permettait d'utiliser simplement la chaine "%c0%2e%c0%2e" (1) qui ne contient pas directement ".." mais qui sera encodé en une chaine Unicode le représentant. Le correctif avait à l'époque consisté à positionner cet argument à la valeur MB_ERR_INVALID_CHARS, ce qui provoque une erreur avec la chaine 1 car il ne s'agit pas d'une chaine Unicode valide. CORE Security a découvert qu'il était toujours possible d'exploiter la faille en utilisant cette fois-ci "0xc20x2e0xc20x2e" qui passe la première validation mais aussi l'appel à MultiByteToWideChar(), cette suite d'octets étant valide en Unicode.

Profitons-en pour rappeler qu'en environnement virtualisé, l'application des correctifs de sécurité, en plus d'être indispensable pour les systèmes d'exploitation et applications invités, l'est aussi pour le virtualiseur et le système hôte.