Qualys

Security CommunityLa communauté des experts sécuritéen savoir plus

SecurityVibesQualys Community

Left content

Virtualisation : Etat de l’Art des attaques techniques

auteur de l'article Jerome Saiz , dans la rubrique Menaces

La présentation de Nicola Ruff à l’occasion du petit-déjeuner SecurityVibes consacré à la sécurité de la virtualisation. Des attaques complexes, mais bien réelles.

Nicolas Ruff, chercheur au laboratoire de R&D sécurité d’EADS, a ouvert ce quatrième petit-déjeuner SecurityVibes par une présentation des risques techniques spécifiques aux environnements virtualisés.

Argument principal : l’incroyable quantité de lignes de code ajoutée par la virtualisation augmente naturellement la probabilité d’une vulnérabilité exploitable. « La virtualisation augmente la surface d’attaque du sytème invité, ne serait-ce qu’à cause des outils qui lui sont ajoutés », explique le chercheur. Des additions tels les VMware Tools, par exemple, peuvent affaiblir le sytème invité. Un attaquant qui aurait obtenu un accès non privilégié à un système via la vulnérabilité d’une application web, par exemple, pourrait exploiter une faille d’un outil tel les VMware Tools afin d’augmenter ses privilèges sur le système, chose impossible si ce dernier n’est pas virtualisé (et il s’agit là d’un scénario déjà rencontré ). Cas isolé pour autant ? Même pas : l’ajout par VMware de code spécifique au support 8086 dans les environnements 64 bits a, là aussi, déjà donné lieu à une vulnérabilité d’élevation de privilèges de ce type.

Nicolas Ruff est ensuite revenu sur le rôle central joué par l’hyperviseur, autre source de vulnérabilités potentielles. « Même si l’hyperviseur est conçu pour être sûr et fiable, il ne faut pas oublier qu’il fonctionne le plus souvent sur un système d’exploitation complet, qui souffre des vulnérabilités qui lui sont propres » poursuit le chercheur. Et s’il n’ignore pas, comme sa présentation le rappelle très justement, que les puristes préféreront séparer l’hyperviseur de l’hôte (selon le concept du « Bare-Metal Hypervisor »), c’est en pratique peu souvent le cas et c’est plutôt un bon vieux Windows ou Linux complet qui anime le tout. Et ces systèmes ne sont pas toujours adaptés aux exigences de la tâche : des vulnérabilités telles le bug WxH, qui permettait de faire crasher l’hyperviseur de différentes manières depuis un invité, ou encore la vulnérabilité du vénérable éditeur ed  qui a étonamment impacté VMware, ont montré qu’un système d’exploitation traditionnel n’était pas forcément le bon choix pour animer l’hyperviseur en toute sécurité.

Bien entendu, encore faut-il à l’attaquant être en mesure d’accèder au dit hyperviseur. Qu’à cela ne tienne : plusieurs attaques permettant l’évasion d’une machine invitée vers la machine hôte ont également été démontrées par le passé (Joanna Rutkowska sur Xen, ou la vulnérabilité VMware automatisée par Cloudburst, par exemple).

Enfin, toutes ces attaques peuvent être amplifiées, ou facilitées, par le manque de maîtrise de l’outil, devenu très complexe : « VMware, par exemple, dispose de très nombreuses options non documentées, au point qu’il faille analyser le code binaire pour découvrir le nom de ces options », poursuit Nicolas Ruff. Et parmi les options pourtant documentées, certaines peuvent avoir un impact sur la sécurité sans que les opérateurs n’en maîtrisent les détails. Qui fait par exemple la différence entre virtualisation logicielle ou matérielle, plutôt que de laisser le réglage « automatique » par défaut ? « On ne comprend rien à la configuration et on ignore l’impact sur la sécurité d’une erreur de configuration » confirmera d’ailleurs plus tard un participant lors du débat.

Ces risques, toutefois, sont à temperer par la complexité des opérations nécessaires à une exploitation réussie. C’est vrai pour la virtualisation basée sur du logiciel (VMware), mais plus encore pour les solutions basées sur de la virtualisation matérielle (Hyper-V). Toutefois là aussi, les attaques existent (voir le bug du chipset Q35 publié par Joanna Rutkowska, ou les discussions autours d’attaques contre le CPU lui-même) et il serait dangereux de les ignorer.

Pour autant, inutile de paniquer : les vulnérabilités traditionnelles des systèmes virtualisés, les failles liées à l’humain (manque de formation) ou les erreurs de configuration sont encore tellement présentes que les attaques pointues décrites ici seront a priori encore difficiles à observer à grande échelle pour un certain temps.


Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Notez L'article

Participez ou lancez la discussion!

2 réponses à Virtualisation : Etat de l’Art des attaques techniques

Catégories

Étiquettes

Archives

Ce site est une archive des messages à SecurityVibes de Septembre 2000 à Juillet 2014. S'il vous plaît visitez le Qualys Community pour les dernières nouvelles.