Fuite d'informations dans les environnements virtualisés

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.

Prise de contrôle de l'hôte grâce à une faille dans l'hyperviseur

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].