La sécurité de la virtualisation : vulnérabilités

Je sais, je sais ! Le précédent article est intitulé « La sécurité de la virtualisation : suite et fin » induisant donc la fin de cette série de billets. Ce ne sera cependant pas le cas. Je souhaiterai aller un peu plus loin sur ce sujet particulièrement intéressant qu’est la sécurité des systèmes de virtualisation. Depuis mon retour de vacances, j’ai eu l’occasion de lire divers documents très intéressants à ce sujet et d’y réfléchir longuement.

Dans les billets précédents, l’objectif avait été de proposer quelques ajustements vis à vis de la conférence sur la sécurité de la virtualisation lors de la Nuit de Hack. Ces articles s’étaient donc voulus plutôt rassurants cependant il est nécessaire de mitiger ce portrait. Les risques liés à la sécurité de la virtualisation existent bien. Affirmer le contraire serait au mieux une vulgaire erreur.

Nous allons aujourd’hui nous intéresser aux vulnérabilités qui ont déjà été trouvées dans des produits de virtualisation et leurs implications.

Xen

Nous allons premièrement nous intéresser au produit Xen open source. Le produit Citrix est un produit hybride s’inspirant largement du produit open source mais disposant de nombreuses modifications qui dépassent le périmètre de ce dernier. La conception de Xen se veut sécurisée par le biais, notamment, de l’utilisation des différents anneaux de protection système. Son histoire n’est cependant pas exempte de vulnérabilités.

La plus grosse vulnérabilité de Xen date de Septembre 2007. Il s’agissait d’une faille qui permettait à un domU d’exécuter des commandes dans le dom0 lors de l’utilisation de l’outil pygrub. L’outil pygrub permet à un domU de disposer d’un bootloader similaire à celui que l’on peut trouver sur une machine physique classique. Cette faille est extrêmement problématique dans la mesure où le dom0 est un domaine exceptionnellement sensible qui dispose de très nombreuses interactions directes avec le matériel et l’hyperviseur. Vous pourrez trouver plus d’informations sur cette faille sur l’OSVDB.

D’autres vulnérabilités ont été trouvées dans Xen permettant à un domU de sortir de son isolation. La plupart de ces failles nécessitent des conditions très particulières afin d’être exploitables ou ne permettent au mieux qu’un DoS local. La liste des failles est disponible sur l’OSVDB.

VMWare

Nous allons ensuite nous intéresser au produit VMWare. La liste des vulnérabilités pour ce produit est nettement plus longue avec un net pic en 2008. Le plus grand nombre de vulnérabilités s’explique surement en partie par la grande étendue des produits VMWare qui incluent aussi bien l’hyperviseur que tous les outils de gestion associés (Virtual Center, Service Console, …).

Parmi toutes ces vulnérabilités, on en recense 4 qui permettent une violation de l’isolation des machines virtuelles. Ces élévations de privilèges se font à travers les VMWare Tools quant il s’agit de machines virtuelles ou à travers les produits connexes à l’hyperviseurs.

Conclusion

Les produits de virtualisation ne sont clairement pas exempts de vulnérabilités quoi que l’on puisse dire. L’impact d’une vulnérabilité sur une plateforme de virtualisation sera largement plus important par rapport à une architecture classique. Il est cependant nécessaire de nuancer ces propos. De nombreuses mesures sont prises afin d’éviter que ces vulnérabilités puissent avoir un impact quelconque sur le reste de la plateforme. De plus jusqu’à présent, l’impact des failles de sécurité est relativement minime et leur fréquence plutôt faible. Il convient donc de rester vigilant aux évolutions des plateformes de virtualisation en matière de sécurité.

Pour en savoir plus, je vous conseille la présentation de Julien Raeis et Nicolas Collignon à ce sujet. Les deux tableaux récapitulatifs présents dans cet article sont extraits de cette présentation.