Sécurité : Comment Xen a pris de l’avance sur ESXi

D’importants travaux de recherche ont permis à l’hyperviseur ouvert de prendre une sérieuse avance sur son concurrent propriétaire en matière de sécurité des environnements virtualisés. Le fruit de son ouverture et des investissements d’Intel et de Bitdefender, notamment.

C’est un important pas en avant dont Bitdefender a annoncé l’accomplissement fin juillet. A cette date, l’éditeur a en effet revendiqué le développement « d’une technologie exclusive d’introspection de la mémoire basée sur l’hyperviseur ».

Les observateurs attentifs du domaine de la sécurité des environnements virtuels l’auront relevé : le sujet n’est pas exactement nouveau. En juillet 2010, Matt Northam, expert technique sécurité et conformité chez VMware pour l’Europe du Nord, faisait état de capacités comparables pour les API vSafe de son hyperviseur : celles-ci permettaient déjà l’inspection du trafic réseau avant qu’il n’arrive à la machine virtuelle ; elle devaient également permettre d’inspecter mémoire vive et stockage de l’extérieur, pour « par exemple détecter un rootkit directement dans la mémoire vive alors même que le système d’exploitation ne sait pas qu’il est attaqué ».

Une promesse de longue date

Une jolie promesse, alléchante sur le papier, que VMware n’a toutefois pas complètement concrétisée.

Dans un entretien téléphonique, Rares Stefan, directeur de la division Solutions d’entreprises de Bitdefender explique : l’introspection du stockage est bien là, avec ce que l’on appelle désormais vShield, et l’introspection du trafic réseau a été répliquée dans NSX, mais pour « l’introspection de la mémoire vive et des tâches, il n’y a jamais eu d’API de lancée ». Et Rares Stefan n’est pas étranger au domaine : il travaillait chez Third Brigade avant son rachat en mai 2009 par TrendMicro. Third Brigade venait alors d’annoncer une solution de sécurisation des environnements virtualisés tirant profit des API vSafe.

En 2010, Matt Northam expliquait lui que « l’architecture de Xen, avec la machine virtuelle du Dom0, ne permet pas de proposer une API de type vSafe directement dans l’hyperviseur ». De quoi laisse penser qu’il y avait là une impasse.

Ironie du sort, c’est bien avec Xen que se concrétise aujourd’hui l’introspection de la mémoire vive, et pas avec ESXi. De quoi faire dire à Rares Stefan qu’en la matière, « Xen est largement en avance ».

Le fruit de 5 ans d’efforts pour Mihai Dontu et d’Andrei Lutas, « les deux chercheurs au cœur de ce projet » chez Bitdefender, explique Rares Stefan.

Et Mihai Dontu d’ajouter que Xen dispose aujourd’hui de capacités d’introspection de la mémoire « matures et peu intrusives », grâce aux contribution de l’éditeur, mais également à celles d’Intel ou encore plus largement de la communauté.

Des défis importants

Mais pourquoi Xen ? Tout d’abord, parce que l’hyperviseur est open source. Dans une présentation, Mihai Dontu, chef de projet technique chez Bitdefender, souligne en outre que Xen est « relativement facile à modifier », profite d’une base de code « mature », et d’une communauté très active. S’il fallait l’illustrer, rappelons que Xen est la base de… µ-Xen, le micro-hyperviseur que Bromium utilise pour sécuriser les postes de travail.

Mais surtout, Xen est au cœur de nombreuses infrastructures Cloud comme celles d’Amazon, de Rackspace, d’Oracle. Et on le trouve bien sûr dans CloudStack et OpenStack.

Cela ne rend toutefois pas l’introspection de la mémoire plus aisée. Plusieurs défis bien connus s’imposent, à commencer par l’écart sémantique : comment corréler des accès en mémoire vive avec des « structures de données qui ont un sens pour le système d’exploitation » de la machine virtuelle ? « Quels objets sont au sein de la machine virtuelle ? Quelles opérations sont réalisées au sein de la machine virtuelle ? » relève Andrei Lutas, directeur de recherche sénior Introspection chez Bitdefender.

Surtout, ce travail de corrélation doit pouvoir se faire rapidement, sans dégrader les performances ni de l’hôte ni des machines virtuelles qu’il abrite. Des travaux de recherche universitaires ont montré que cette question peut trouver des solutions, même avec des outils qui n’ont rien de particulièrement neuf, comme LibVMI. Mais Bitdefender s’appuie sur une librairie dérivée de LibVMI.

Dans un e-mail à la liste de diffusion des développeurs Xen, Razvan Cojocaru, lui aussi de Bitdefender explique que l’éditeur s’appuie sur Libbdvmi pour répondre à deux problèmes : réduire l’adhérence à l’OS de la machine virtuelle – LibVMI collecte des informations à son sujet via des outils Python – et à des librairies externes comme glib, dont la librairie de Bitdefender parvient à se passer.

Résoudre l’écart sémantique

Le code source de Libbdvmi est accessible publiquement sur l’entrepôt de code source GitHub de Rzvan Cojocaru. Mais c’est loin d’être la seule contribution de Bitdefender à la communauté Xen pour l’introspection de la mémoire basée sur l’hyperviseur.

Dans un entretien téléphonique, Andrei Lutas donne un aperçu des travaux de l’éditeur : « Il y a beaucoup de recherche académiques sur l’écart sémantique. Dans notre cas, nous utilisons principalement la connaissance du système d’exploitation et la couplons avec la logique d’introspection. Nous utilisons des signatures invariables pour identifier des structures clés des systèmes d’exploitation, ce qui revient à modéliser des structures spécifiques au système d’exploitation ». Ce qui revient à « transposer certains aspects du système d’exploitation au sein de la logique d’introspection ». D’autres, relève Andrei Lutas, préfère se reposer sur des éléments de code injectés dans la VM, comme des pilotes par exemple, mais Bitdefender a fait le choix de ne pas interférer avec la VM.

L’un des points de l’approche de l’éditeur réside les extensions du sous-système de gestion des événements de la VM, VM events, développées par l’équipe de Mihai Dontu : « cette couche est utilisée pour communiquer avec l’hyperviseur », explique Andrei Lutas, « et pour accéder à des fonctions de bas niveau comme cartographier la mémoire, interroger l’état du CPU et de ses registres, etc. »

De nombreuses contributions publiques

Pour aboutir à cela, les équipes de Bitdefender ont apporté d’importantes contributions à Xen. Et cela commence, comme l’explique Andrei Lutas, par une capacité d’émulation d’instruction et d’empêchement de modification de la mémoire : « les résultats de l’instruction ne sont pas effectivement écrits en mémoire. Cela permet d’empêcher par exemple un rootkit de modifier une fonction du système d’exploitation. Celui-ci conserve donc son intégrité ».

La seconde est tout aussi importante pour l’introspection, renvoie encore à l’écart sémantique et aux performances, en attachant l’état de la VM à ses événements mémoire, ou plutôt de violation des protections EPT : « avant, il fallait interroger l’hyperviseur pour avoir ces informations sur l’état du vCPU, ce qui était extrêmement lent ». Mihai Dontu précise que les correctifs apportés fournissent en outre des informations sur des événements supplémentaires. A cela s’en ajoutent d’autres, permettant de cacher des contenus de la mémoire, ou encore d’interdire certaines écritures dans les registres à partir de la VM.

L’un des enjeux, pour l’éditeur, consiste à n’avoir aucune adhérence avec le système d’exploitation des VM, « ce qui permet un déploiement rapide, au niveau de l’hyperviseur », souligne Rares Stefan. Et Andrei Lutas d’ajouter que ce déploiement permet « de détecter à la voler les VM qui ont besoin de protection et de la leur fournir immédiatement », sans rien installer manuellement sur les machines virtuelles.

Aujourd’hui, Bitdefender entend employer cette technologie sur tous les terminaux supportant la virtualisation – client lourd et terminaux mobiles – et bien sûr les infrastructures Cloud pour protéger notamment, et en particulier, contre les attaques avancées persistantes.