Antoine Benkemoun

21 Juin, 2010

La sécurité de la virtualisation

Posté par Antoine dans la catégorie Blog|Libre|Sécurité|Virtualisation

Ce weekend avait lieu la Nuit du Hack 2010. Il s’agit d’un événement orienté vers tous les types de hacking. De nombreuses conférences étaient proposées au public venu pour l’occasion avec notamment une présentation du hacking de l’iPhone et de la PS3.

Une présentation a particulièrement attiré mon attention mais pas pour de bonnes raisons. En fin de soirée avait lieu une conférence intitulé « Virtualisation et sécurité ». J’attendais donc avec impatience cette conférence. Autant dire que cela a été une grande déception. Le sujet était traité d’un point de vue beaucoup trop global mais, surtout, les informations soutenues étaient plus que discutables.

Je vais donc profiter de cette espace pour tenter d’éclaircir certains points par rapport à la sécurité de la virtualisation.

Classification

Avant de plonger dans l’étude à proprement dit de la sécurité dans la virtualisation, il est intéressant de se replonger dans la classification des solutions. Lors de la présentation, il avait été différencié les types de virtualisation suivants : « full virtualisation », « paravirtualisation » et « hyperviseurs ».

Un hyperviseur n’est pas un type de virtualisation mais une application qui peut effectuer de la virtualisation. Il est possible de les classifier selon deux catégories bien que cette division ne me plaise pas particulièrement.

La sécurisation de l’hyperviseur : DoS & DDoS

Lors de la présentation, le DoS (Denial of Service) et le DDoS (Distributed Denial of Service) ont été désignés comme des solutions simples et efficaces de neutraliser une plateforme de virtualisation.

Dans le cas de Xen, il est pratiquement impossible de communiquer avec l’hyperviseur. Il ne faut bien sur par confondre hyperviseur et domaine 0 (ou console de gestion dans le cas de VMWare). L’attaque DoS est donc difficile à imaginer dès le départ. L’interface de communication avec l’hyperviseur dont nous disposons est l’API des hypercalls, remplaçants des appels systèmes classiques dans le cas de la paravirtualisation.

L’utilisation des ces hypercalls est limitée par les algorithmes d’ordonnancement système ce qui empêche une utilisation abusive. Il s’agit du même mécanisme que celui utilisé pour le partage des ressources physiques. Le DoS semble donc impossible par ce biais.

Les outils d’administration sont également un potentiel point d’entrée supplémentaire. Ces outils ne sont accessibles qu’à partir du domaine 0 qui peut difficilement être considéré en tant que VM comme les autres. Un attaque DoS sur le domaine 0 rendrait les mêmes résultats qu’une attaque DoS sur les autres machines virtuelles étant donné les mécanismes d’ordonnancement.

La communication avec l’hyperviseur n’étant possible que par ces interfaces, il parait impossible d’y effectuer une attaque DoS capable d’atteindre toutes les machines virtuelles de la plateforme.

La sécurisation de l’hyperviseur : cloisonnement

Le cloisonnement des machines virtuelles est bien sûr une caractéristique élémentaire d’une plateforme de virtualisation. Contrairement à ce qui a été dit, l’hyperviseur n’a pas « la main » sur les machines virtuelles. Il a simplement la possibilité de les éteindre, de les démarrer ou de les mettre en pause. Ni plus, ni moins.

Le cloisonnement est géré par la restriction des accès mémoire. Les hyperviseurs ont été spécifiquement prévus afin d’éviter un débordement des accès vers la mémoire. Le seul vecteur d’exploitation de ce type de faille est les hypercalls dans le cas de Xen. A ce jour aucune faille connu permet d’accéder à des zones mémoires non autorisées.

De plus dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, les machines virtuelles ne disposent même pas d’interface spécifique avec l’hyperviseur ce qui rend pratiquement impraticable de ce type de vulnérabilité.

Les risques d’erreur de cloisonnement ne sont pas inexistants bien entendu cependant il ne faut pas perdre de vue qu’il s’agit de l’objectif même de la conception de l’hyperviseur et que les machines virtuelles disposent de très peu ou aucune interface de communication avec l’hyperviseur afin de l’induire en erreur.

Dans le prochain (et dernier épisode), nous étudierons les autres points abordés lors de la présentation et les risques réels associés à la virtualisation. Loin de moi l’idée de prêcher la sécurisation totale de la virtualisation, je pense cependant qu’il est très facile et réducteur d’agiter des menaces sans fondement pratique.

4 Commentaires to "La sécurité de la virtualisation"

2 | Istace Emmanuel

juin 27th, 2010 at 5 h 30 min

Avatar

Voici les slides de ma présentation.

http://www.nuitduhack.com/slides/2010/Istace%20NDH.pdf

Lors de la présentation, il avait été différencié les types de virtualisation suivants : « full virtualisation », « paravirtualisation » et « hyperviseurs ».

RElisez les slides svp. J’ai différencier des technologies de virtualisations : Hyperviseurs, isolation, user space kernel et hardware. La « full » et « para » virtualisation n’étant que certains cas précis d’application de la virtualisation

Par rapport au cloisement je vous renvois vers Mastering VmWare 4 chez Sybex qui explique très bien et noir sur blanc que les hyperviseurs ont un acces privilégié aux machines.

De manière plus globale je parle aussi et surtout de l’utilisation d’exploit résultant de bug de conception !!!

3 | Antoine

juin 27th, 2010 at 8 h 30 min

Avatar

Bonjour,

Par rapport aux types, il s’agit de ce que j’ai retenu de votre présentation… Après avoir revu vos slides, je constate que vous présentez VMWare comme une technologie qui effectue essentiellement de la paravirtualisation or ce n’est pas juste. Xen oui, VMWare non. La paravirtualisation est une option pratiquement inutilisée dans VMWare qui va être supprimée à terme. La différenciation qui était mon propos initial est plus ambigüe par rapport à votre troisième slide.
Il y a une différence entre un accès privilégié et « avoir la main » qui est ce que vous avez dit à l’oral. L’hyperviseur a l’accès à la mémoire vive ce qui est effectivement un accès privilégié.
Je pense que votre présentation n’est pas fausse dans son ensemble mais que vous présentez les choses de manière trop simpliste et trop globale… Les vecteurs de failles que vous présentiez n’ont jamais été exploités à ma connaissance.

4 | Istace Emmanuel

juin 29th, 2010 at 18 h 06 min

Avatar

Concernant VmWare ESX, son architecture est de type 1, au même titre que Xen. Dans ma description des hyperviseurs de type 1 je précise : « Si les OS hôtes sont conscient et optimisé que pour être virtualisé, alors on parle de para-virtualisation’. La slides suivant, paravirtualisation est mis entre guillemet car la plupart des systèmes utilisant un hyperviseur de type 1 font de la paravitualisation, mais je ne ciblait pas ESX en particulier. Pour le reste je m’excuse alors, on est bien d’accord sur le sujet (sur le fond), concernant l’accès privilégié on est d’accord. En effet j’ai du faire des raccourcis car présenter le sujet de manière globale pour faire un état des lieux des implémentations de solutions de virtualisation en 30min… De plus le niveau du public en terme de virtualisation était très très hétérogène, je me devais donc de trouver un juste milieu pour rendre le sujet accessible a tous.

Ajoutez votre commentaire

A propos de ce blog

Ce blog a pour objectif de partager des informations avec tous les internautes. Comme indiqué dans le titre, je traiterais de différrents sujets gravitant autour de la sécurité informatique, de la virtualisation, de la l'administration système et du réseau.