Aperçu
Le 13 mai 2015, le chercheur en sécurité Jason Geffner de CrowdStrike a révélé publiquement une vulnérabilité dans certaines plateformes de virtualisation qui pourrait permettre un attaquant de sortir du bac à sable d'une machine virtuelle (VM) et d'accéder à l'hôte de virtualisation protégé. La vulnérabilité a été baptisée "VENOM", pour Virtualized Environment Neglected Operations Manipulation (CVE-2015-345) et affecte tout hôte de virtualisation non corrigé construit sur l'émulateur open source QEMU, y compris Xen, KVM et VirtualBox d'Oracle. Les technologies qui n'utilisent pas QEMU, telles que VMWare, Hyper-V de Microsoft et Bochs, ne sont pas affectées.
Introduction à la virtualisation
La virtualisation, en termes généraux, est une implémentation technologique qui permet à un gros ordinateur de subdiviser ses ressources (processeur, mémoire, espace disque dur, par exemple) pour exécuter de nombreux ordinateurs virtuels plus petits. Chacune de ces machines virtuelles fonctionne comme s'il s'agissait d'un système discret, isolé des autres machines virtuelles exécutées sur le même hôte. Cette architecture permet aux opérateurs de serveurs de gérer et de déployer plus facilement des serveurs, car ils peuvent créer une nouvelle machine virtuelle en beaucoup moins de temps qu'il n'en faudrait pour créer une version physique. Il permet également aux opérateurs de centres de données et aux fournisseurs d'hébergement d'utiliser plus efficacement leurs ressources. Un hôte de virtualisation exécutant, par exemple, 10 VM utilise une fraction de l'espace, de l'alimentation et du refroidissement utilisés par 10 machines physiques équivalentes.
Que peut faire un exploit contre VENOM ?
L'un des autres avantages d'une plate-forme de virtualisation est la possibilité de séparer les machines virtuelles. Ainsi, même si elles utilisent le même matériel partagé, les VM sont isolées. Une telle isolation permet à un administrateur de serveur de provisionner différentes machines virtuelles, exécutant différents systèmes d'exploitation, pour différents clients. Ces clients ne sauraient jamais qu'ils partagent des ressources sur un hôte de virtualisation avec d'autres clients. Et même s'ils avaient des privilèges root ou administrateur sur leurs VM, le confinement les empêche de faire quoi que ce soit qui affecterait n'importe quelle autre VM.
Ce concept d'infrastructure cloisonnée est ce qui rend l'idée d'une vulnérabilité comme VENOM si préoccupante. Comme le décrit Geffner sur le site Web de CrowdStrike :
Cette vulnérabilité peut permettre à un attaquant de s'échapper des limites d'un invité de machine virtuelle (VM) affecté et d'obtenir potentiellement un accès d'exécution de code à l'hôte. En l'absence d'atténuation, cet échappement de VM pourrait ouvrir l'accès au système hôte et à toutes les autres VM exécutées sur cet hôte, donnant potentiellement aux adversaires un accès élevé significatif au réseau local de l'hôte et aux systèmes adjacents.
Pour un fournisseur qui s'est appuyé sur la sécurité de l'isolation des machines virtuelles, une telle vulnérabilité peut être alarmante.
Combien d'alarme ?
Bien que l'annonce de cette vulnérabilité ait été comparée, dans certains médias, à Heartbleed, il est important de peser ce qui est connu par rapport à ce qui est possible et probable.
Selon Geffner, la "vulnérabilité VENOM existe depuis 2004", bien qu'aucun exploit connu (à ce jour) n'ait été documenté dans la nature. Geffner a partagé ses découvertes avec les principaux fournisseurs de virtualisation qui utilisent QEMU le 20 avril 2015. Une fois qu'un correctif a été développé, il a publié ses découvertes sur le site Web de CrowdStrike le 13 mai 2015.
À ce jour, cependant, aucune preuve de concept publique n'a été démontrée. Nous ne savons pas actuellement à quel point il est simple ou difficile de créer un code capable d'exploiter VENOM. Étant donné que VENOM laisse un système ouvert aux attaques via le vieil ami du pirate, le débordement de la mémoire tampon, il pourrait, dans sa forme la plus simple, être exploité pour faire planter la machine hôte, entraînant un déni de service. Avec plus de soin et d'intelligence, un attaquant pourrait potentiellement accéder à l'hôte de virtualisation lui-même et être en mesure de compromettre les autres machines virtuelles exécutées sur ce même hôte.
Que pouvons-nous faire pour nous protéger ?
Étant donné que VENOM a été divulgué de manière responsable, ce qui a donné aux fournisseurs le temps de produire un correctif, il incombe aux administrateurs de l'hôte de virtualisation d'appliquer le correctif aussi rapidement que possible. Les personnes dont les services s'exécutent sur des machines virtuelles s'exécutant sur une plate-forme de virtualisation partagée ne peuvent pas faire grand-chose par elles-mêmes. Ils peuvent cependant visiter le site Web de leur fournisseur pour voir s'ils sont vulnérables et quelles mesures sont prises pour remédier à la vulnérabilité. Si nécessaire, ils peuvent faire pression pour pousser leurs administrateurs à corriger leurs systèmes avant que cette menace potentielle ne devienne un exploit fonctionnel largement utilisé par le côté obscur d'Internet.
Pour en savoir plus sur ce que fait Atlantic.Net pour remédier à la vulnérabilité VENOM, consultez notre blog pour les dernières nouvelles. Nous nous efforçons constamment d'offrir les serveurs privés virtuels les plus sécurisés offrant le meilleur des applications d'installation en un clic comme l'hébergement cPanel, entre autres.
Mise à jour le 15 mai 2015 pour inclure le lien vers le blog Atlantic.Net