Evaluation des risques posés par l'usage de machines virtuelles

De nombreux logiciels permettent de faire tourner un OS complet dans une machine virtuelle (Virtual PC, VMware, UML, Qemu, Bochs...). Ils sont parfois utilisés pour confiner une menace dans un sous-ensemble isolé du système (cas d'un pot à miel, d'un service peu sécurisé...). Les problèmes auquels je me suis intéressé sont :
- Un pirate peut-il découvrir qu'il vient de pénétrer dans une machine virtuelle (et non dans un système classique) ?
- Le fait qu'un système d'exploitation tourne dans une machine virtuelle introduit-il de nouvelles vulnérabilités ?
- Un pirate peut-il "sortir" d'une machine virtuelle, cassant ainsi l'isolation avec le système hôte ? (ce qui élimine tout l'intérêt d'utiliser une machine virtuelle à des fins de sécurité)

Détection de machines virtuelles : elles sont toutes détectables, au minimum en "local". D'une part, elles émulent un type de matériel bien spécifique, donc repérable. D'autre part, chaque technique de virtualisation employée (modification du noyau comme dans UML, émulation du processeur comme dans Qemu et Bochs, modification de l'organisation mémoire d'un processus avec émulation des instructions privilégiées comme dans VMWare) entraîne des modifications détectables dans l'environnement des processus virtuels. Par exemple, la technique de mesure du temps que j'ai présentée au SSTIC (voir ci-dessus) permet de détecter VMware en mesurant le temps supplémentaire mis par les appels systèmes et les instructions privilégiées.
Introduction de vulnérabilités : certaines peuvent exister. Par exemple, le code exécuté au sein d'une machine virtuelle tourne en niveau de privilège 'utilisateur' ("ring 3" sur processeurs Intel) du point de vue du processeur physique. C'est donc le rôle du logiciel de machine virtuelle d'émuler correctement la protection de la mémoire du noyau (qui tourne normalement en "ring 0" afin d'être protégé des processus utilisateurs). Sinon, un processus utilisateur pourrait écrire dans le noyau et ainsi gagner les droits ultimes sur le système. UML en mode 'tt' avait initialement ce problème.
Sortie d'une machine virtuelle : au moins trois pistes existent. 1, trop de fonctionnalités accordées à la machine virtuelle (exemple: accès au presse-papier de la machine hôte depuis VMware). 2, un bug exploitable dans l'émulation du hardware ou des instructions assembleur. 3, une mauvaise protection de l'espace mémoire, permettant à un processus tournant à l'intérieur de la machine virtuelle d'écrire directement dans la mémoire du logiciel gérant la machine virtuelle.

Quelques résultats

Je n'ai audité que certains logiciels de machines virtuelle, cette liste est donc susceptible de s'agrandir.

Qemu en mode 'fast' est sujet à ces trois problèmes : détection, élévation de privilèges à l'intérieur de la machine virtuelle, sortie de la machine virtuelle.
En effet, il utilise la MMU (Memory Management Unit) du système hôte sans vérifier les droits d'accès, ce qui permet d'écrire dans la mémoire du noyau émulé, ainsi que dans la pile du processus qemu-fast.

Télécharger le code de démonstration et ses explications.

Remarque : l'auteur de Qemu a mis à jour la documentation pour expliquer que la sécurité n'était pas assurée par qemu-fast en raison d'un choix volontaire de design.
Exemple sur UML : A VENIR, SITE EN COURS DE CONSTRUCTION
Je recommanderais l'usage de VMware, pour lequel je n'ai pas détecté pour le moment de problème majeur (uniquement la détectabilité et la possibilité pour un utilisateur de stopper la machine virtuelle).

Retour à la page d'accueil