La fuite d'informations dans les environnements virtuels est l'application de la fuite d'information à l'Informatique, plus particulièrement à des environnements virtuels. Les machines virtuelles sont massivement utilisées dans le but d'établir des environnements mutualisés^[1]. Elles partagent alors le même matériel physique. Ce nouveau type d'architecture a fait apparaître de nouveaux problèmes de sécurité. Il existe différentes techniques permettant d'extraire des informations d'une machine virtuelle cible. Ces techniques dépendent de l'environnement auquel l'attaquant a accès.

La récolte d'informations, dans le cadre d'utilisations malveillantes, est souvent un préambule à de futures attaques. Mais elle peut aussi être utilisée à bon escient, comme dans le cadre d'études statistiques^{[réf. nécessaire]}. La fuite d'information peut toucher plusieurs différentes parties d'un environnement virtualisé: l'environnement en lui-même, le gestionnaire de machines virtuelles, l'hôte exécutant ce gestionnaire ou une machine virtuelle. L'environnement peut laisser à disposition des informations qu'une machine virtuelle peut récupérer, par exemple sur la topologie du ou des réseaux dans lequel elle se trouve. En utilisant ces procédés, elle peut notamment déterminer la corésidence, c'est-à-dire si elle se trouve ou non sur la même machine physique qu'une autre machine virtuelle. Avoir des informations sur le gestionnaire de machines virtuelles, comme le nom et la version du logiciel utilisé, aide à la sélection de malwares ciblés. Concernant l'hôte, il peut être intéressant, entre autres pour les malwares d'être conscient de se trouver dans un environnement virtualisé.

Enfin, l'isolation logicielle des machines virtuelles n'est pas parfaite et il est possible grâce à certains procédés utilisant les ressources communes aux machines virtuelles d'extraire des informations^[2],[3].

Cet article ne traitera pas des environnements virtualisés de haut niveau.

On dit qu'il y a fuite d'information quand des données sensibles sont divulguées intentionnellement ou non à une personne non autorisée. Cela peut être des données confidentielles (par exemple un mot de passe) ou des données menant à un exploit. Un cloisonnement des instances qui se partagent une même ressource est prévu par les solutions de virtualisation, mais en pratique les machines virtuelles ne sont jamais totalement isolées^[4] car elles doivent communiquer avec l'hyperviseur et le matériel nécessaire au fonctionnement. Ce manque de cloisonnement peut engendrer des fuites d'informations^[Comment ?] telles que la détection du gestionnaire de machines virtuelles^[5], ou encore du vol de clé ssh^[2] par attaque temporelle.

L'établissement de la corésidence peut être une étape préalable à la fuite d'information. En effet, une fois que l'attaquant est sûr d'être sur la même machine, il a la possibilité d'observer d'autres métriques tels que l'utilisation CPU(s). Thomas Ristenpart a démontré, la possibilité d'établir la corésidence dans un environnement virtualisé, à travers une expérience avec Amazon Web Services^[6]. L'expérience proposée par Ristenpart se déroule en 3 étapes :

• Résoudre le nom de domaine de la machine cible à l'intérieur du cloud d'amazon pour obtenir son adresse interne^[7];
• Lancer de nombreuses machines virtuelles dans l'espoir que l'une d'entre elles soit sur la même machine physique que la VM cible^[6];
• Vérifier la corésidence via un traceroute : le dom0 ressort en 1 saut du traceroute, on a juste à vérifier que les deux correspondent^[8].

Une machine virtuelle peut mesurer l'utilisation du cache de la machine physique sur laquelle elle est placée (Ce qui constitue une attaque par canal auxiliaire)^[9],[10]. Il est alors possible en se basant sur l'utilisation du cache d'effectuer une attaque de vol de clé^[11] ou une attaque par analyse temporelle des touches frappées ^{[note 1],[2]}.

Osvik, Shamir et Tromer ont essayé plusieurs types d'attaque par canal auxiliaire pour retrouver une clé de chiffrement AES^[10]. Elles se basent sur une analyse des temps d'accès à la mémoire et au cache et sur la manière qu'AES a d'accéder à ceux-ci. La première, dite synchrone, s'applique aux scénarios dans lesquels le clair est connu et l'attaquant peut interagir avec le système de chiffrement de manière synchrone sur le même processeur. L'exemple décrit une attaque sur un système de chiffrement de disque où l'attaquant a accès en écriture au disque, le clair est donc connu. Osvik, Shamir et Tromer ont démontré la viabilité de l'attaque décrite précédemment. En effet, ils ont réussi à extraire de manière fiable des clés AES complètes utilisées pour chiffrer le disque en utilisant 65 ms de mesures (seulement 800 opérations d'écriture) suivi de 3 secondes d'analyse. La seconde attaque est asynchrone et s'applique aux scénarios ne permettant pas d'utiliser le système de chiffrement avec un clair connu. Lors de la récupération de statistiques sur l'utilisation des sets de cache, on suppose que le système de chiffrement est utilisé. On compare ensuite les statistiques récupérées avec celles résultant de l'application d'AES sur le type de données supposé (dans l'exemple, la donnée est l'anglais). Dans leur exemple, ils ont réussi à récupérer en moyenne 45,7 bits des clés avec des statistiques récupérées sur 1 minute.

Bien que l'hyperviseur soit exécuté sur la même machine que la machine virtuelle, celui-ci doit rester aussi transparent que possible. Toutefois, l'hyperviseur doit stocker son code ainsi que les informations concernant les machines virtuelles^[12]. Ces données peuvent engendrer des fuites d'informations.

Plusieurs méthodes permettent de détecter la présence de machines virtuelles. En observant les variables d'environnement il est possible de détecter la présence de l'hyperviseur^[13]. Par exemple, HDTrans, Valgrind et DynamoRIO utilisent la variable d'environnement LD_PRELOAD sous linux afin de définir les librairies dynamiques à lancer en priorité^[13]. L'inspection de la pile permet elle aussi de mettre en évidence un hyperviseur. Comme celui-ci doit stocker ces informations en mémoire telles que son code, et les informations nécessaires à la gestion des invitées, toutes ces informations peuvent être retrouvées en inspectant la pile^[14]. Les méthodes basées sur la table des descripteurs locaux^{[note 2]} se révèlent elles aussi efficaces du fait que les environnements virtuels créent leurs propres tables des descripteurs^[15], en inspectant celles-ci, il est possible de révéler la présence de l'hyperviseur^[16].

Il existe différentes raisons de vouloir détecter la présence d'une machine virtuelle. Les malwares récents possèdent de tels systèmes de détection afin d'éviter de se retrouver dans un honeypot^[1]. Un attaquant peut aussi rechercher un certain type d'hyperviseur afin d'exploiter une faille connue et prendre le contrôle de la machine physique.

La prise de contrôle de l'hôte ne devrait pas être possible dans une machine virtuelle, car celle-ci est censée être isolée. Cependant une vulnérabilité dans l'hyperviseur peut permettre à un attaquant de remonter jusqu'à l'hôte. L'attaquant pourra alors contourner les sécurités mises en place sur la machine virtuelle^[17]. Un exemple fonctionnel dans VMWare est celui de Kostya, travaillant pour la société cloudburst, la vulnérabilité est référencée CVE-2008-0923.

Kostya a utilisé le fait que dans vmware, l'invité, à travers une carte graphique virtuelle, doit forcément accéder au framebuffer de l'hôte pour faire des affichages^[18]. Un driver maison utilisant la carte graphique virtuelle pour écrire dans la mémoire de l'hôte a donc été écrit^[19]. Avec les droits administrateurs sur la machine invitée, il a réussi à réécrire certaines adresses du framebuffer de l'hôte, modifiant ce que l'écran de celui-ci affiche^[20].

L'établissement de la corésidence (notamment sur Amazon Web Services^[6]) peut être atténué en diminuant les données renvoyées par le réseau (résolution dns, traceroute)^[21]. Une solution plus simple est d'autoriser l'utilisateur à placer ses machines virtuelles^[21]. L'utilisateur a alors la possibilité de placer ses machines virtuelles sur une machine physique peuplée uniquement par des machines virtuelles de confiance^[21]. En échange, il paye la sous consommation de la machine physique^[21].

Bien que le fait de retirer le cache dans le but de prévenir des attaques basées sur le cache peut paraître évident^[22], la mise en œuvre d'une telle solution l'est bien moins^[22]. Retirer simplement le cache est irréaliste car celui-ci est nécessaire pour des raisons de performances^[22]. Trois solutions sont particulièrement mises en avant par la littérature du domaine.

Les attaques basées sur des données temporelles ont besoin de relevés précis pour être efficaces^[23]. Il est possible de fausser les données temporelles en ajoutant un temps ou le programme additionne des nombres aléatoires^[24]. Ainsi l'attaquant ne pourra pas se baser sur les relevés de temps pour analyser ce que le programme cible est en train de faire. Cet effet peut être facilement obtenu en ajoutant le code suivant dans la boucle principale de l'algorithme :

for(index = 0; index < random number; index++)
{
dummy = random number + random number;
}

Il est aussi possible de retirer complètement l'accès à l'horloge^[25], sans relevés possibles, l'attaque temporelle devient impossible à réaliser^[24].

L'idée ici est d'accéder à des endroits de la mémoire non présents dans le cache de manière aléatoire^[24]. Ce qui génère un nombre aléatoire de défauts de cache^{[note 3]}. Ainsi l'attaquant ne peut plus se baser sur les défauts de cache pour analyser ce que le programme cible est en train de faire^[26].

Une solution pour pallier les attaques par canal auxiliaire consiste à utiliser des processeurs non déterministes^[27]. Ces processeurs rendent le séquencement des instructions aléatoire tout en conservant les dépendances entre les données^[28].

L'impact de la fuite d'information sur une organisation peut être sévère et couteux^[29], comme le montre l'affaire Sony où un vol de 2.2 millions de cartes bancaires avait eu lieu^[30]. Il faut donc être conscient du danger et tenter de s'en prémunir^[31]. Avec la démocratisation de la virtualisation, grâce notamment au cloud computing qui utilise massivement ces technologies, les fuites d'informations sont de plus en plus répandues^[32]. Cette démocratisation permet de rentabiliser la recherche de failles et le développement de malwares à cause du nombre croissant de cibles potentielles^{[réf. nécessaire]}.

• Ristenpart, Tromer, Shacham et Savage, « Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds », ACM,‎ novembre 2009 (lire en ligne)
• Garfinkel et Rosenblum, « When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments », Usenix 2005,‎ 2005 (lire en ligne)
• Osvik, Shamir et Tromer, « Cache Attacks and Countermeasures: the Case of AES », Department of Computer Science and Applied Mathematics, Weizmann Institute of Science,‎ novembre 2005 (lire en ligne)
• Dan Page, « Defending against cache-based side-channel attacks », Elsevier - Information Security Technical Report. Vol. 8, No. 1,‎ mars 2003 (lire en ligne)
• Garfinkel, Adams, Warfield et Franklin, « Compatibility is Not Transparency: VMM Detection Myths and Realities », Conference: USENIX Security 2007,‎ mai 2007 (lire en ligne)
• Jenni Reuben, « A Survey on Virtual Machine Security », Helsinki University of Technology,‎ octobre 2007 (lire en ligne)
• John Robin et Cynthia Irvine, « Analysis of the Intel Pentium’s Ability to Support a Secure Virtual Machine Monitor », Conference: USENIX Security 2000,‎ août 2000 (lire en ligne)
• Danny Quist et Val Smith, « Further Down the VM Spiral », Conference: DEFCON 14,‎ août 2006 (lire en ligne)
• Song, Wagner et Tian, « Timing Analysis of Keystrokes and Timing Attacks on SSH », Conference: USENIX Security 2001,‎ 2001 (lire en ligne)
• Kostya, « A VMware Guest to Host Escape Story », Conference: Blackhat 2009,‎ 2009 (lire en ligne)
• Vaquero, Rodero-Merino et Morán, « Locking the sky: a survey on IaaS cloud security », Springer,‎ 2010 (lire en ligne)
• Xu, Bailey, Jahanian, Joshi, Hiltunen et Schlichting, « An Exploration of L2 Cache Covert Channels in Virtualized Environments », ACM,‎ 2011 (lire en ligne)
• ANSSI, « Problématiques de sécurité associées à la virtualisation des systèmes d’information », ANSSI,‎ 2012 (lire en ligne)
• Dan Upton, « Detection and subversion of virtual machines », University of Virginia, CS 851 - Virtual Machines,‎ 2006 (lire en ligne)
• Danny Quist et Val Smith, « Detecting the presence of virtual machines using the local data table », Offensive Computing,‎ 2006 (lire en ligne)
• Phil Zinkewicz, « Dealing with data leakage », Rough Notes,‎ 2009 (lire en ligne)
• David May, Henk L. Mulle et Nigel P. Smar, « Non-Deterministic processors », Springer-Verlag, University of Bristol,‎ 2001 (lire en ligne)
• Tom Liston et Ed Skoudis, « On the Cutting Edge: Thwarting Virtual Machine Detection », Intel guardians,‎ 2006 (lire en ligne)
• Simon Moore, Ross Anderson et Markus Kuhn, « Improving Smartcard Security Using Self-timed Circuit Technology », ACiD-WG Workshop,‎ 2000 (lire en ligne)
• Subashini et Kavitha, « A survey on security issues in service delivery models of cloud computing », elsevier,‎ 2010 (lire en ligne)
• « Une autre plate-forme de jeu de Sony piratée », Le Monde,‎ 2010 (lire en ligne)
• « Le coût moyen des pertes de données par les entreprises françaises franchit la barre des 2,2 millions d'euros et la tendance n’est pas à la stabilisation, selon une étude du Ponemon Institute commandée par Symantec », Symantec,‎ 2011 (lire en ligne)

• Portail de la sécurité informatique