MS07-049, un danger virtuel bien réel

Parmi les derniers bulletins et correctifs de la firme de Redmond, je n’ai pas pu m’empêcher de sourire en lisant la nature du quarante-neuvième correctif de l’année : Il s’agit tout simplement de corriger une faille permettant à de vilains individus qui seraient confortablement installés sur une machine virtuelle, de prendre le contrôle du serveur hôle voire carrément le contrôle d’autres machines virtuelles fonctionnant sur ce même serveur.

Bien entendu, il s’agit d’un correctif Microsoft, donc cela ne concerne que leur produit Virtual PC. Pour le moment. Car rien n’est moins certain quant à la probabilité que le principal concurrent soit plus robuste. Disons que cette faille a le mérite de *prouver* aux personnes qui croient aveuglement à la sécurité ultime que procure la virtualisation qu’il n’en est rien.

Comment cela est-il possible ? Rappelons d’ores et déjà certaines bases : D’une part, une machine virtuelle fonctionne non pas de manière totalement autonome, mais partage certaines ressources (disque, mémoire, processeur, …) avec le système d’exploitation qui l’héberge. Cela est un fait non seulement avéré, mais indispensable. Sinon on ne parlerait plus de virtualisation mais de machines parallélisées avec chacune leur propre processeur, espace mémoire etc. La totalité des ressources physiques mises à disposition par le serveur hôte est donc répartie entre lui-même et les différentes machines virtuelle en fonctionnement. Si une machine virtuelle se met à consommer trop de mémoire, disque ou CPU, normalement le serveur hôte est capable d’éviter que cela n’impacte les autres machines virtuelles voire le serveur tout court. De bons algorithmes de scheduling permettent d’allouer à chaque machine virtuelle le temps CPU qui lui est octroyé, et des mécanismes de gestion de quota permettent de limiter les ressources réseau, disque et mémoire.

Tout semble donc parfait et l’isolation des machines semble totale. Sauf que..

Le principal souci est que, afin d’optimiser au mieux les ressources et pour permettre des prouesses telles que l’exécution de 8 machines virtuelles sur un serveur ne comportant qu’1Go de mémoire vive, il faut ruser. La solution consiste à installer des outils sur les machines virtuelles, qui vont interagir avec le système hôte et le système d’exploitation de la machine virtuelle pour en optimiser les ressources. Par exemple, ces outils (présents sous la forme de drivers) vont informer le serveur hôte de la structure mémoire (allocations en cours, etc…) du système virtuel, et si par hasard il se trouve que plusieurs machines virtuelles utilisent exactement les mêmes ressources, le serveur hôte va s’arranger pour mapper la même zone aux deux machines virtuelles. Cela optimise sacrément l’utilisation mémoire, mais comporte des risques.

Deuxième point: comme je l’ai expliqué, ces outils communiquent avec le serveur hôte. Par quel biais peuvent-ils le faire sans faire courir le risque que l’émulation puisse être parfois incompatible ? Les concepteurs de ces outils ont tout simplement rusé en utilisant des techniques que j’appellerai « instruction knocking », à la manière du « port knocking » utilisé dans le monde des réseaux et permettant d’ouvrir un canal de communication en envoyant une certaine séquence. Les outils de communication entre hôte et machine hébergée utilisent des séquences d’instructions assembleur peu communes, qui sont reconnues par le serveur hôte qui en décode la signification. Donc il est possible de communiquer avec le serveur hôte par ce biais.

Maintenant, si un débordement de buffer existe à ce niveau, on peur craindre le pire puisqu’une machine virtuelle peut alors communiquer avec le serveur hôte à coups de shellcodes.

Malgré tout, l’utilisation de la virtualisation est plus que bénéfique, et il ne faut pas s’arrêter face à de tels soucis, qui n’arrrivent que rarement et sont rapidement corrigés. Au mieux, afin de ne pas faire n’importe quoi, prenez plusieurs serveurs physiques dédiés chacun à un environnement. Et pensez que ces menaces mentionnées sont plus souvent en provenance de l’extérieur. Donc même si il est possible de virtualiser toute une DMZ, prenez cette hypothèse en considération.

Après tout, il y avait eu un débat similaire il y a quelques années sur les switches et la capacité à faire des débordements de VLANs…

Avant de finir, et pour approfondir ce même sujet, je vous conseille de lire l’excellent article écrit par Cédric Pernet sur le blog de son nouvel employeur.

3 Comments »

Bruno Kerouanton on août 21st 2007 in IT Security

3 Responses to “MS07-049, un danger virtuel bien réel”

  1. Sid responded on 21 Août 2007 at 12:40 #

    Le problème de la virtualisation de machines est bien plus vaste amha que celui des VLANs. En effet, dans ce dernier, l’attaquant reste extérieur au système et sa surface d’attaque est relativement faible. D’ailleurs, l’expérience montre qu’en dehors de grossières fautes de mise en oeuvre, certes aidées par la configuration par défaut, la saut de VLAN est très improbable. Mais pas impossible cependant.

    Avec la virtualisation de machines, l’attaquant interragit avec le système de manière nettement plus importante, parfois directe. On l’a vu avec l’exploitation de certains drivers « virtuels » qui permettent alors un accès direct à la mémoire de l’hôte.

    Bref, pour moi, la virtualisation en sécurité, ce ne sera pas mettre pleins de machines sur le même hardware, mais de ségréguer des applications et/ou de les monitorer. Et ceci se fera avec des outils développés dans ce but là.

  2. Cédric Pernet responded on 21 Août 2007 at 15:14 #

    Merci Bruno 😉

    Je crois que la virtualisation va encore faire couler beaucoup d’encre (et ruiner quelques touches de clavier) ces prochains temps…

  3. Bruno Kerouanton responded on 21 Août 2007 at 17:43 #

    @Sid: oui tu as raison, le débordement de vlans c’est assez difficile à réaliser, l’environnement de laboratoire le permet si on sature à fond le switch, et encore ça dépend de sa puissance CPU et de son implémentation de gestion des vlans. En pratique je n’ai jamais eu de souci de ce genre en prod. Bien plus ennuyeux, le port « trunk » taggué qui est mal relié et auquel on a branché une machine normale (voire un serveur ESX mal configuré au niveau des VLANs, en reparlant virtualisation) par erreur… Car cela permet à la personne ayant accès à ladite machine de faire bien des choses… mais passons.

    Là où tout cela devient intéressant, c’est avec les fameuses appliances virtuelles proposées par nombre de sociétés ou d’individus, et poussés en avant par VMware. Car il y a franchement de tout… du meilleur au pire. Et surtout de nombreux « équipements » de sécurité ou de gestion de réseau tels que firewalls, load-balancers, routeurs, proxies, etc… De là à virtualiser tous les équipements actifs et les DMZ il n’y a qu’un pas que certains ont déjà franchi.

    De quoi s’inquiéter un peu, sans doute…

Trackback URI | Comments RSS

Laisser un commentaire