Deux failles dans l'hypervisor Xen permettent à une VM malveillante de lire et écrire la mémoire des autres machines virtuelles.

Le Xen Project a publié le 3 novembre un avis de sécurité préoccupant. Deux vulnérabilités touchent l’hypervisor Xen. En effet, elles permettent à une machine virtuelle invitée malveillante de lire et d’écrire dans la mémoire d’autres VM hébergées sur le même serveur. Le dom0 figure notamment parmi les cibles possibles.

Des correctifs sont disponibles. En revanche, aucune mesure d’atténuation n’est connue. Les administrateurs n’ont donc qu’une solution : appliquer les mises à jour.

Ce que révèlent les failles de l’hypervisor Xen

Un hypervisor est la couche logicielle qui fait fonctionner plusieurs machines virtuelles sur un même matériel. Sa mission principale consiste à les isoler les unes des autres. Ainsi, chaque VM doit croire qu’elle est seule sur la machine.

Pourtant, les deux failles annoncées brisent précisément cette promesse. Une VM invitée contrôlée par un attaquant peut accéder à la mémoire d’un autre invité. Elle peut non seulement la lire, mais aussi la modifier.

Ces deux capacités n’ont pas les mêmes conséquences. D’abord, la lecture ouvre la porte au vol d’informations sensibles. Il peut s’agir, par exemple, de clés de chiffrement, de mots de passe ou de données applicatives. Ensuite, l’écriture permet d’altérer le comportement d’un système. Un attaquant pourrait ainsi modifier des données ou des processus en cours d’exécution.

Dans un tel scénario, la frontière entre les machines virtuelles n’a plus de valeur. Par conséquent, le cloisonnement, pilier de la virtualisation, devient inopérant.

Pourquoi le dom0 change la gravité de l’attaque

Le dom0 occupe une place à part dans l’architecture Xen. Par défaut, cette machine virtuelle dispose de tous les droits. De plus, elle gère les autres VM du serveur.

Par conséquent, y accéder en lecture et en écriture est particulièrement grave. Un attaquant qui atteint la mémoire du dom0 se place au cœur de l’administration de l’hôte. Il peut ainsi potentiellement observer ou perturber l’ensemble de l’environnement virtualisé.

Autrement dit, une simple VM invitée compromise pourrait servir de tremplin. Elle permettrait de viser le composant le plus privilégié de la plateforme. Les autres machines virtuelles seraient alors exposées à leur tour.

Cette situation concerne surtout les environnements où plusieurs clients ou plusieurs services partagent la même infrastructure. Dans ces cas, une VM peut appartenir à un tiers moins fiable. Le risque d’un invité hostile y est donc plus réaliste.

Versions de l’hypervisor Xen concernées et absence de contournement

L’avis précise que toutes les versions de Xen à partir de la 4.6 sont vulnérables. Le périmètre est donc large. Il couvre en effet de nombreuses installations, y compris des déploiements anciens. Ceux-ci restent parfois en production pendant des années.

Par ailleurs, le Xen Project indique ne connaître aucune mitigation. Il n’existe pas de réglage de configuration ou de contournement temporaire à mettre en place. Les équipes ne peuvent donc pas se contenter de réduire la surface d’attaque en attendant mieux.

Cette absence d’alternative rend l’application des correctifs d’autant plus urgente. Elle pose également une difficulté pratique. En effet, mettre à jour un hyperviseur implique souvent de planifier une maintenance. Il faut parfois redémarrer l’hôte ou migrer des machines virtuelles. Les équipes doivent donc s’organiser rapidement.

Les éléments disponibles ne mentionnent aucune exploitation active de ces failles. Toutefois, l’absence de mention ne garantit pas leur absence. C’est pourquoi il vaut mieux traiter ces vulnérabilités comme une priorité. Pour les détails techniques et les identifiants associés, il convient de consulter l’avis officiel du Xen Project.

Ce qu’il faut retenir

• Nature du risque : deux failles permettent à une VM invitée malveillante de lire et d’écrire la mémoire d’autres VM du même hôte, dom0 compris.
• Versions touchées : toutes les versions de Xen depuis la 4.6.
• Correctifs : ils sont disponibles depuis l’avis publié le 3 novembre par le Xen Project.
• Contournement : aucune mitigation connue à ce jour.

Pour réagir efficacement, les équipes peuvent suivre quelques étapes simples :

1. D’abord, recenser tous les hôtes qui utilisent Xen, y compris les plus anciens.
2. Ensuite, vérifier la version installée et la comparer à celles concernées.
3. Puis récupérer les correctifs auprès du Xen Project ou de la distribution utilisée.
4. Par ailleurs, planifier sans attendre les redémarrages ou les migrations nécessaires.
5. Enfin, surveiller en priorité les hôtes qui exécutent des VM de tiers ou peu fiables.

Enfin, ces failles rappellent une règle de base. La sécurité d’une infrastructure virtualisée repose d’abord sur celle de son hyperviseur. Un suivi régulier des avis de sécurité reste donc indispensable.

Source : Xen Hypervisor Flaws Let One Malicious VM Read and Write Any Other VM's Memory