Sécurité des hyperviseurs

La sécurité des hyperviseurs est relative à toute menace ou toute attaque par des virus informatiques qui remettrait en question la sécurité (au sens informatique) basée sur les services de confidentialité, d’intégrité et de disponibilité.

Cet article aborde successivement la description, l’évolution de la sécurité et les risques encourus quant à l’utilisation des hyperviseurs. Puis, il traite de la vulnérabilité des hyperviseurs, des attaques et des solutions apportées pour les sécuriser.

Présentation

La virtualisation consiste à faire fonctionner un ou plusieurs systèmes d'exploitation ou applications sur un ou plusieurs ordinateurs/Serveur informatique au lieu d'en installer un(e) seul(e) par machine. Ces ordinateurs virtuels sont aussi appelés serveur privé virtuel (Virtual Private Server ou VPS) ou encore environnement virtuel (Virtual Environment ou VE). Un Hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une même machine physique en même temps. Les hyperviseurs sont classés en 2 catégories Type 1 natif et Type 2:

Architecture des hyperviseurs de type 1

• La paravirtualisation : ou hyperviseur de type 1 ou natif encore appelé "bare metal" (littéralement "métal nu"), est un logiciel qui s'exécute directement sur une plateforme matérielle. Cette plateforme est alors considérée comme outil de contrôle du système d'exploitation. Un système d'exploitation secondaire peut être exécuté au-dessus du matériel. Il implémente la plupart des services que fournissent les noyaux des systèmes d’exploitation courants, entre autres la gestion mémoire complète des machines virtuelles ainsi que leur ordonnancement. Parmi les solutions logicielles existantes figurent :
  1. XEN libre, hyperviseur supportant des noyaux Linux, Plan 9 from Bell Labs, NetBSD.
  2. Oracle VM propriétaire, hyperviseur sur plateforme x86.
  3. VMware ESX propriétaire, hyperviseur sur plateforme x86 (produits ESX et ESXi-gratuit).
  4. Hyper V propriétaire, hyperviseur sur plateforme x64 uniquement.
  5. KVM libre, module noyau Linux tirant parti des instructions de virtualisation des processeurs Intel et AMD (Intel VT ou AMD-V).

Architecture des hyperviseurs de type 2

• La virtualisation complète : ou hyperviseur de type 2 (hébergé, host-based) ou hypervisor call, ou hypercall, est un logiciel qui s'exécute à l'intérieur d'un autre système d'exploitation. Un système d'exploitation invité s'exécutera donc en troisième niveau au-dessus du matériel. Il utilise les services fournis par le système d’exploitation hôte pour gérer la mémoire et l’ordonnancement des machines virtuelles. Le microprocesseur, la mémoire de travail RAM (Random-access memory) ainsi que la mémoire de stockage sont directement accessibles aux machines virtuelles. Parmi les technologies existantes il faut noter :
  1. QEMU émulateur de plateformes x86, PPC, Sparc, ARM.
  2. Bochs émulateur de plateforme x86.
  3. VirtualBox émulateur de plateforme x86.
  4. VMware Server émulateur de plateforme x86 (produits VWware Server, VMware Player et VMware Workstation).
  5. Virtual PC propriétaire, émulateur de plateforme x86.
  6. MAC on Linux émulateur de plateforme Mac OS sur Linux PPC.

La sécurité en informatique est l’ensemble des moyens techniques, organisationnels, juridiques et humains nécessaires et mis en place pour conserver, rétablir et garantir la sécurité du système d’information.

La sécurité se définit sur 3 critères de base :

Disponibilité : propriété d'un système d'information capable d'assurer ses fonctions sans interruption.

Intégrité : propriété d'une donnée dont la valeur est conforme à celle définie par son propriétaire.

Confidentialité : propriété d'une donnée dont la diffusion doit être limitée aux seules personnes autorisées.

Évolution et sécurité de l'hyperviseur

Les technologies de virtualisation prennent une part de plus en plus importante depuis les années 2000. Ce phénomène est lié notamment au développement de nouveaux usages comme la virtualisation des postes de travail, la virtualisation des applications d’entreprise, la virtualisation du stockage, ou l’apparition du cloud computing.

Chronologie de la Virtualisation

De plus la virtualisation permet de faire des économies de place, d’énergie et de budget en diminuant le nombre de serveurs utilisés en les mutualisants et en optimisant leurs usages. Cette technologie est mise en avant comme élément d'amélioration que ce soit dans le cadre de la sécurité, de la fiabilité ou de la disponibilité. Cette technologie touche de plus en plus les grandes entreprises mais également les PME (Petite et Moyenne Entreprise) et PMI (Petite et Moyenne Industrie).

L'Hyperviseur améliore la sécurité du point de vue :

Disponibilité

L'Hyperviseur repose sur le matériel et en cas de défaillance sur la machine il suffit de posséder un équipement compatible avec le produit de virtualisation pour en fabriquer une équivalente.

Intégrité

Avec l’utilisation des solutions de stockage partagé de type SAN (Storage Area Network), l'Hyperviseur permet la réplication synchrone.

Confidentialité

L'Hyperviseur permet de concevoir des architectures isolées au sein d’un hôte. Il permet également d’œuvrer sur le réseau local sans utiliser physiquement de carte réseau.

Hyperviseur et ses risques

L'Hyperviseur de par sa technologie engendre de nouveaux risques comme les attaques entre machines virtuelles, la fuite d'information d’une machine virtuelle, la prise de contrôle du système hôte… Ci-dessous un ensemble des risques liés à ces nouvelles technologies:

Risque accru de compromission des systèmes

La compromission est la prise de contrôle par un acteur malveillant d’un système invité depuis un autre système invité ou de la couche d’abstraction depuis un système invité. Le risque qui en découle est la fuite d'information ou des perturbations du système pouvant aller jusqu'à l'indisponibilité d'un service. Il est essentiel que chaque brique matériel, système d’exploitation hôte et système d’exploitation invité soient à jour de tous les correctifs de sécurité.

Accroissement du risque d’indisponibilité

La panne d’une ressource commune peut engendrer l'indisponibilité simultanée de plusieurs systèmes et potentiellement tous les services hébergés sur la même machine.

Fuite d’information par manque de cloisonnement

Dans le cas de la virtualisation, les instances que sont le système d’exploitation, les applications, le système de stockage de données et autres… se partagent une même ressource. De ce fait il devient difficile de maitriser les différents échanges internes à une même machine physique et donc de garantir que les ressources bas niveaux partagés n'introduisent pas de possibilité de fuite d’information.

Prenons l'exemple avec l’accès au réseau d’une machine informatique :

Dans une architecture sans virtualisation, les machines communiquent sur des réseaux physiques au moyen d’une carte réseau spécifique. Les flux de données sont ainsi traités au niveau des machines par chaque carte réseau et peuvent être identifiés précisément.

Dans une architecture avec virtualisation, les machines virtuelles peuvent communiquer sur des réseaux physiques par le biais d’une carte unique appartenant à la machine physique qui les héberge. Les flux de données de chaque machine virtuelle sont donc traités par cette unique carte réseau. Dès lors, il n’est pas possible de garantir un cloisonnement des flux au niveau de la ressource partagée. La carte réseau a la possibilité en cas d’erreur ou de compromission de mélanger les différents flux d’information.

Complexification de l’administration

La virtualisation fait apparaitre des opérations d’administration nouvelles comme la mise en place des quotas sur des ressources partagées ou la gestion d'ajout de disque ou de périphérique de stockage réseau entre les machines virtuelles. L'administration s'en trouve complexifiée d'autant plus que ce sont en général des personnes différentes qui gèrent les parties réseaux, serveurs, sauvegardes et stockages.

Complexification de la supervision

Les opérations de supervision peuvent s’avérer complexes du fait de l’incompatibilité entre le cloisonnement nécessaire des machines virtuelles et la nécessité de vision d’ensemble de la part de la supervision. Dès lors il devient difficile de tracer un événement ou une action de bout en bout.

Prolifération non souhaitée des données et des systèmes

Les systèmes invités sont moins adhérents aux équipements c'est-à-dire qu'un système se voit reproduit à l'identique sur plusieurs machines. En conséquence la localisation précise d’une donnée s'en trouve complexifiée et les risques de copie non maîtrisée s'en trouve accrus avec les conséquences graves que cela peut engendrer comme la modification ou le vol d'informations.

Incapacité à gérer voire à comprendre les erreurs

Avec la virtualisation il est possible à la suite de dysfonctionnements d'arrêter et de redémarrer plusieurs systèmes invités sur un même système hôte mais il devient complexe de gérer ces erreurs sans leur prise en compte globale.

Il convient donc de mettre en place une centralisation et une corrélation des journaux sur l'ensemble des systèmes.

Investigations post incident plus difficiles

Certaines investigations menées après incident lié au partage de ressources matérielles par plusieurs systèmes peuvent s'avérer plus difficile. L'optimisation de la gestion de la mémoire vive par la solution de virtualisation rend plus délicate l'analyse de l'historique des états de la machine et par conséquent le traitement d'un incident dans la mesure où cette mémoire est réallouée à une autre machine virtuelle dès que celle-ci n’est plus utilisée.

Hyperviseurs vulnérabilités et attaques

Le contexte

Les hyperviseurs ont été graduellement utilisés dans des applications de plus en plus critiques, leur fiabilité est d'une importance vitale. Contrairement aux systèmes d'exploitation traditionnels qui doivent supporter le système de fichier, les piles réseaux, etc., un hyperviseur présente des abstractions relativement simples telles la CPU et la mémoire. En conséquence de ces propriétés, les hyperviseurs ont été largement considérés comme une architecture pour construire des systèmes d'exploitation sécurisés.

Cependant, il y a diverses inquiétudes concernant les hyperviseurs actuels. Avec de plus en plus de machines virtuelles déployées sur une seule plate-forme gérée par un seul hyperviseur, la robustesse est aussi un point posant problème. Les hyperviseurs modernes dérivent des systèmes d'exploitation contemporains. Malheureusement beaucoup de décisions de conception "restent inchangées, même si dans le même temps le matériel et logiciel ont évolué". Exemple de la conception monolithique qui utilise des langages procéduraux tels que le langage de programmation C. Un trop grand nombre de lignes de code n'est pas adapté à une vérification formelle. En fait les meilleurs techniques de vérification disponibles peuvent gérer environ 10K lignes de code. De cela résulte une piètre maintenabilité. Il est donc difficile d'étendre les fonctionnalités des hyperviseurs.

Pour construire un hyperviseur robuste le choix du langage de programmation est critique. Le langage doit être suffisamment efficace pour manipuler les objets de bas niveau, expressif et permettre de vérifier l'intégrité du code. Le TCB (Trusted Computing Base) est défini comme la totalité des mécanismes de protection dans un système informatique, incluant le hardware (matériel informatique), le firmware, et le software (logiciel).

De leur combinaison ressort la partie responsable du renforcement de la politique de sécurité. Ainsi, malgré une faible empreinte de l'hyperviseur en lui-même, ces plates-formes ont un large TCB. Un micro-hyperviseur tel NOVA propose une architecture dans laquelle la réduction du TCB fait partie intégrante de la conception.

Les plates-formes de virtualisation telles que Xen, Vmware ESX et Hyper-V sont responsables de l'isolation et de la gestion de la mémoire des machines virtuelles. Puisque l'hyperviseur s'exécute au plus haut niveau de privilège, il forme avec le matériel la partie dite TCB.

Architecturalement, ces plates-formes dépendent de composants additionnels, des pilotes logiciels, des composants d'émulation, etc.

La compromission d'un de ces composants permettra à un attaquant d'obtenir des privilèges tels que l'accès à des zones mémoires ou d'injecter du code malveillant.

L'hyperviseur est une couche entre le système d'exploitation de la machine hôte et l'environnement virtuel, il offre de nouvelles opportunités pour les logiciels malicieux.

L'hyperviseur étant lui-même un logiciel, il comporte en son sein les bugs traditionnels et les vulnérabilités inhérentes à la création de programmes informatique.

Les environnements virtualisés sont vulnérables du fait même des systèmes d'exploitations s'exécutant comme des machines virtuelles, à l'ensemble des exploits et attaques traditionnelles qui se retrouvent sur les environnements plus classiques.

L'attente sécuritaire pour les environnements virtuels est d'autant plus élevée qu'elle dépend du nombre de systèmes d'exploitation virtuels à protéger, du nombre de points d'entrées potentiels, du nombre de failles à patcher et des points d'interconnexions.

Dans un environnement non virtuel, les applications s'exécutant sur une machine peuvent se voir l'une ou l'autre et dans certains cas communiquer entre elles. Tandis que dans un environnement virtuel les programmes tournant sur une machine sont en principe isolés des autres programmes tournant sur les autres machines. De ce point de vue le degré d'isolation devrait être assez fort pour que les vulnérabilités d'une machine ne puissent pas affecter les autres machines virtuelles ainsi que la machine hôte.

La couche de virtualisation est très impliquée à travers tout le cycle de vie de la machine virtuelle. Chaque interaction entre la machine virtuelle et l'hyperviseur est un vecteur potentiel d'attaque qui peut être exploité par un système d'exploitation virtualisé non autorisé. La machine virtuelle interagit directement avec l'hyperviseur et indirectement avec le système d'exploitation de la machine hôte et l'émulateur à travers lequel la VM (Virtual Machine) fait ses appels systèmes.

Un appel système est un événement qui se produit quand la VM exécute un code de sortie alors le code l'hyperviseur gère un évènement (par exemple émuler un accès mémoire). Un hypercall est similaire à un appel système, il est utilisé par les machines virtuelles pour demander des services explicites à l'hyperviseur.

Exemples d'opcodes de sortie pour les VM

VM Exit	Reason
EPTV	An attempt to access memory with a guestphysicaladdress was disallowed by the configuration of the EPT paging structures.
APICACC	Guest software attempted to access memory at a physical address on the APIC-access page.
MSRWR	Guest software attempted to write machine specific register, MSR.
MSRRD	Guest software attempted to read machine specific register, MSR.
IOINSR	Guest software attempted to execute an I/O instruction.
DRACC	Guest software attempted to move data to or from a debug register.
CRACC	Guest software attempted to access CR0, CR3,CR4, or CR8 x86 control registers.
CPUID	Guest software attempted to execute CPUID instruction.
PNDVINT	Pending virtual interrupt.
EXTINT	An external interrupt arrived.
EXCNMI	Exception or non-maskable interrupt, NMI.

Chaque appel système de la machine virtuelle peut être vu comme un canal de communication où une VM envoie implicitement ou explicitement des informations à l'hyperviseur que ce dernier doit traiter. L'ensemble des appels représente une partie de la surface d'attaque. Certaines solutions telles que Nohype permettent de réduire la surface d'attaque en éliminant le besoin d'interaction entre les machines virtuelles et l'hyperviseur.

Isolation et les attaques afférentes

Un des premiers bénéfices apportés par la virtualisation est l'isolation, elle permet d'assurer qu'une application tournant sur une VM n'accède pas à une application tournant sur un autre VM. L'isolation doit être fortement maintenue, pour que l'intrusion dans une machine virtuelle ne permette pas l'accès aux autres machines virtuelles, à l'hyperviseur et à la machine hôte. Pour exemple, le partage du presse-papiers dans un environnement virtuel est une fonctionnalité pratique qui permet aux données d'être transférées entre les machines virtuelles et la machine hôte. Mais cette fonctionnalité peut aussi servir de passerelle pour transférer des données entre des codes malicieux agissant en collaboration au sein de différentes machines virtuelles. Certaines technologies de virtualisation ne mettent pas en œuvre l'isolation dans le but de permettre à des applications conçues pour un système d'exploitation, d'être opérationnelles sur un autre système d'exploitation, ce genre de solution permet l'exploitation des failles de sécurité des deux systèmes d'exploitation, et donne aussi un accès sans limites aux ressources de la machine hôte, telles que le système de fichiers.

Évasion de machine virtuelle

Les machines virtuelles sont autorisées à partager les ressources de la machine hôte mais tout en fournissant l'isolation entre machines virtuelles et entre les VM et l'hôte. Cela dit les machines virtuelles sont conçues de telle manière qu'un programme tournant sur l'une ne puisse communiquer avec les programmes tournant sur l'autre, ou avec les programmes s'exécutant sur la machine hôte. Mais en réalité les organisations compromettent l'isolation. Elles configurent des isolations "flexibles" pour répondre aux besoins de leur architecture. Dans cette situation l'évasion de machine virtuelle est l'attaque la plus grave si l'isolation entre les machines virtuelles est compromise. Dans l'évasion de machine virtuelle, le programme s'exécutant dans la VM est capable de contourner l'hyperviseur et obtenir l'accès à la machine hôte. La machine hôte étant la racine, le programme qui a obtenu l'accès acquiert les privilèges administrateur. Cela a pour résultat de rendre caduque la sécurité d'ensemble de l'environnement. L'exploit Cloudburst est un exemple d'évasion de VM, il prend l'avantage sur une fonction d'affichage d'un produit Vmware, ce qui a permis l'évasion d'une VM et ainsi d'accéder à l'hyperviseur.

Isolation et trafic réseau

Dans le cas du trafic réseau, l'isolation dépend complètement de la manière dont l'environnement virtuel est connecté. Dans la majorité des cas la machine virtuelle est reliée à l'hôte au moyen d'un switch virtuel, ce qui permet à la VM d'utiliser l'ARP poisoning pour rediriger les paquets venant et entrant d'une autre machine virtuelle. L'isolation requiert un Hyperviseur sans défaut de conception et sans bug.

Modification externe de l'hyperviseur

L'hyperviseur est responsable de l'isolation entre les machines virtuelles, les VM sont protégées si l'hyperviseur se comporte correctement. Dans le cas contraire l'hyperviseur introduit une faille de sécurité à l'ensemble de système. Une solution est de protéger l'hyperviseur de toutes modifications non autorisées.

Attaques sur les migrations à chaud de machine virtuelle

Lors de la migration à chaud de machine virtuelle, les trois principales ressources physiques utilisées sont la mémoire, le réseau et le disque local.

La mémoire peut être copié directement d'un hôte vers l'autre, pour le disque local et l'interface réseau la migration n'est pas trivial.

La migration à chaud de machines virtuelles est une caractéristique essentielle de la virtualisation. Elle permet le transfert d'une machine virtuelle d'un serveur physique vers un autre sans interrompre les services en cours d'exécution sur la VM. La migration à chaud offre les avantages suivants : équilibrage de la charge de travail, la consolidation des machines virtuelles, etc.

L'hyperviseur est un logiciel qui émule la partie matérielle vue par les machines virtuelles, il contrôle complètement les ressources du système. La plupart des versions commerciales et open source des hyperviseurs supportent la migration à chaud.

La migration à chaud inclut beaucoup d'état de transferts à travers le réseau. Durant la procédure, protéger le contenu des fichiers d'état de la VM est important. La plupart des travaux, pour mettre en œuvre la migration à chaud, se sont concentrés sur l'implémentation de cette migration avec peu ou pas de considération pour la sécurité s'y rattachant. La mémoire est un point crucial par ce qu'il est difficile pour une machine virtuelle de chiffrer sa propre mémoire. Les protocoles de migration à chaud ne chiffrant pas les données en cours de transferts, toutes les données migrantes, tel que les mots de passe sont transmises en clair. De plus, après la migration l'environnement d'exécution de la machine virtuelle, aura peut-être changé en termes de ressources processeur, mémoire, drivers. De tels changements peuvent être détectés, et un attaquant capable de caractériser ces changements pourrait déclencher des attaques de type side-channel.

Politiques de contrôle d'accès inappropriées

Une politique d'accès inappropriée permet à un utilisateur non autorisé d'initialiser, de migrer ou d'arrêter une machine virtuelle. La politique de contrôle d'accès prend aussi en compte l'accès à l'hyperviseur, l'isolation entre les VM, le partage des ressources, etc. Une politique d'accès inappropriés permettra à un attaquant de réaliser les attaques suivantes :

• Déni de service : l'attaquant peut déclencher un très grand nombre de migrations et ainsi surcharger le serveur cible, affecter ses performances et au pire perturber les services offerts. L'attaquant peut aussi faire des migrations de serveur à serveur réduisant ainsi la performance de service rendu par la machine virtuelle.
• Les attaques internes : un attaquant peut déclencher la migration d'une machine virtuelle contenant un code malicieux ayant pour cible l'hyperviseur. Ce type d'attaque fournit une plate-forme pour des VM malicieuses d'effectuer des attaques internes sur un système cible.
• Attaque de machine virtuelle : un attaquant peut déclencher une requête sur une migration en cours d'une machine virtuelle. Une fois la requête migrée l'attaquant peut prendre le contrôle de la machine virtuelle.
• Attaque inter VM: les machines virtuelles s'exécutant sur une même machine physique sont susceptibles de pouvoir communiquer entre elles. Si une politique n'est pas définie pour contrôler la communication, une VM malicieuse peut attaquer les autres VM se trouvant sur la machine physique.

Canal de transmission non protégé

Le protocole de migration ne chiffre pas les données lors de leur circulation sur le réseau. Il est donc possible de mettre en place des attaques passives ou actives en utilisant des techniques telles que l'ARP/DHCP poisoning, DNS poisoning et l'IP/route hijacking. Les attaques passives peuvent être par exemple l'écoute du réseau pour récupérer des données sensibles. Les attaques actives peuvent être la manipulation des services d'authentification telles que sshd/bin/login ou la manipulation de la mémoire noyau. Il a été montré que le RTT (Round-trip delay time) des paquets ICMP est une métrique prometteuse pour détecter à distance le processus de migration d'une machine virtuelle. En ciblant une machine virtuelle avec les paquets ICMP, il est possible de déterminer quand cette machine a migré sur une autre machine physique .

Promotion de fausses ressources

Dans un environnement où les migrations à chaud sont initiées automatiquement pour distribuer la charge sur un grand nombre de serveurs, un attaquant pourrait faire la "promotion " de fausses ressources via le "Control Plane". Ainsi l'attaquant pourra influencer le "Control Plane" pour migrer une VM vers un hyperviseur compromis. Le "Control Plane" est le mécanisme de communication employé par les machines virtuelles pour déclencher et gérer les migrations à chaud.

Vulnérabilités dans le module de migration

Le module de migration implémente les fonctionnalités nécessaires à la migration des machines virtuelles, il doit donc être résistant aux attaques. Les vulnérabilités dans les modules de migration sont les débordements de pile, de tas, etc.. De telles vulnérabilités peuvent être utilisées par un attaquant pour y injecter du code malicieux ou même arrêter le processus de migration. Le module de migration de l'hyperviseur peut donner la possibilité à l'attaquant d'atteindre l'ensemble des machines virtuelles, le code du module de migration doit être scruté en profondeur pour y supprimer de telles vulnérabilités. Une approche pour sécuriser la migration à chaud est d'isoler le trafic en assignant les VM à un Virtual Lan (Vlan). Le problème principal posé par les VLAN est l'augmentation de la complexité et le coût administratif élevé quand le nombre de machines virtuelles croît.

Attaques via les drivers

Les hyperviseurs ne peuvent en principe s'attaquer directement l'un l'autre, parce que chaque instance s'exécute dans son propre espace d'adressage et un canal direct de communication n'existe pas entre les hyperviseurs.

Pour contourner cela un attaquant devra passer par des services partagés par plusieurs hyperviseurs, par exemple les pilotes. Les pilotes utilisent un canal de communication dédié pour chaque hyperviseur. Quand un hyperviseur malicieux exécute une attaque de type déni de service en soumettant trop de requêtes, le pilote peut couper le canal de communication. La première préoccupation de sécurité concernant les drivers et leur utilisation de la DMA (Direct Memory Access). Si une plate-forme n'inclut pas un IOMMU (Input/Output Memory Management Unit (en)), alors tout pilote qui accède directement à la mémoire doit être de confiance.

Sur les nouvelles plates-formes qui fournissent une IOMMU, l'hyperviseur réduit l'usage de la DMA, un pilote compromis ou un driver malicieux peut seulement affecter la disponibilité de son propriétaire, l'intégrité et la confidentialité de la région mémoire qui lui est assignée. Donc si un hyperviseur délègue l'ensemble de la mémoire physique d'une machine virtuelle à un driver alors ce dernier pourra manipuler la VM tout entière. En utilisant la IOMMU l'hyperviseur bloque les transferts vers sa propre zone mémoire et restreint les vecteurs d'interruption disponibles pour les pilotes. Dans les architectures où les drivers sont intégrés à l'hyperviseur, un matériel non sûr peut saper la sécurité du système dans son entier.

DMA capable devices : ce sont des dispositifs qui peuvent directement lire la mémoire sans intervention de la CPU. Ainsi ils peuvent passer outre aux protections de l'hyperviseur. Ces attaques peuvent être en grande partie réalisées par l’émergence de dispositifs d'entrées/sorties virtuels.

Attaque sur les Hypercalls

Un hypercall est l'équivalent d'un appel système sur les systèmes d'exploitations classiques . D'un point de vue sécuritaire les hypercall sont des véhicules commodes pour un attaquant. Si un attaquant compromet une machine virtuelle pour lancer un hypercall malicieux, il peut causer de sérieux problèmes à l'ensemble du système virtualisé. Des études récentes suggèrent que les interfaces des hypercalls peuvent être exploitées pour injecter du code malicieux dans l'hyperviseur. Ci-dessous le scenario typique d'une attaque d'hypercall dans une architecture XEN :

1. l'attaquant compromet une des applications sur une des machines virtuelles. Ce qui est possible car les VM peuvent communiquer avec le monde extérieur et être ainsi infectées par un malware ;
2. l'attaquant escalade ses privilèges en utilisant des appels systèmes classiques ;
3. quand l'attaquant parvient à entrer dans le noyau de la VM, il peut alors lancer une attaque vers l'hyperviseur via les hypercall.

Attaque de la mémoire virtualisée

Bien qu'une machine virtuelle ne puisse directement modifier les structures de données tels les tables, les descripteurs globaux… Ces opérations peuvent être demandées à travers les hypercalls. Si un attaquant peut modifier un hypercall, il peut potentiellement modifier les droits d'accès à ces structures de données. Il peut ainsi avoir accès aux pages mémoire d'autres machines virtuelles ou modifier le code de ces machines. Il peut aussi causer un déni de service à l'encontre des utilisateurs légitimes de la VM.

Compromettre le système de cryptographie

Rejouer un machine virtuelle peut être pratique pour le diagnostic mais cela peut créer des problèmes pour certains algorithmes de cryptographie. Par exemple, la valeur occasionnelle d'une clé symétrique ne devrait jamais être réutilisée. Si une machine virtuelle est réinitialisée à un état précédent, une même valeur pourrait être répétée. Un attaquant pourrait exploiter cette propriété pour réaliser une attaque contre le système de cryptographie.

Attaques side channel

Ces attaques exploitent les propriétés physiques du matériel pour récolter des informations pouvant donner un schéma ou pattern de fonctionnement du système à attaquer. Le fait que plusieurs machines virtuelles partagent le même matériel rend l'attaque side channel relativement aisée à réaliser. Sans mise en place de dispositif de sécurité au niveau matériel, le partage du matériel est dangereux. L'un des buts de ce type d'attaque est de révéler les clés cryptographiques. Ces attaques sont généralement catégorisées en trois classes :

• time-driven side-channel attack : cette attaque est possible quand le temps total d'exécution des opérations cryptographiques à clé fixe est influencé par la valeur de la clé du fait de la structure de l'implémentation cryptographique. Cette influence peut être exploitée par un attaquant qui peut mesurer ces temps pour en déduire statistiquement des informations sur la clé.
• trace-driven side-channel attack : ces attaques surveillent en continu certains aspects d'un dispositif matériel à travers une opération cryptographique (e.g. la consommation électrique).
• access-driven side-channel attack : dans ce type d'attaque, un attaquant lance l'exécution d'un programme sur le système cryptographique qui gère l'opération ayant de l'intérêt pour l'attaquant. Le programme surveille l'utilisation d'un composant partagé dans l'architecture pour obtenir des informations sur la clé (e.g., le cache de données).

Dans les environnements Cloud Computing, il est possible de mapper l'infrastructure et d'identifier là-où une machine virtuelle réside. Il est alors possible d'instancier de nouvelles machines virtuelles, jusqu'à ce qu'une soit placée en corésidence avec la VM cible. Après ce placement la VM instanciée peut extraire des données confidentielles en provenance de la VM légitime. Ceci est un type d'attaque side-channel.

Les attaques side-channel sont donc très liées à l'existence de phénomènes physiques causés par le traitement sous-jacent des données par les dispositifs électroniques. Quelles sont les contre-mesures?

• Au niveau physique : utilisation de boucliers, de fonctions physiquement non clonables…
• Au niveau technologique : réduire la dépendance des données par rapport à la consommation électrique.
• Au niveau algorithmique : la randomisation du temps, le masquage des fuites mémoires…
• Au niveau protocolaire : mise à jour des clés.

Hyperjacking

Cette attaque consiste à installer un hyperviseur non autorisé qui prendra le contrôle complet du serveur. Les mesures standards de sécurité sont dans ces cas inefficaces, car le système d'exploitation ne se rendra pas compte que la machine a été compromise. Des attaques telles que l'hyperjacking peuvent mettre en balance la sécurité d'architecture comme le cloud computing.

Les solutions de sécurité apportées aux hyperviseurs

Pour faire face aux failles et/ou aux attaques de plus en plus sophistiquées révélées par l’utilisation des hyperviseurs, les entreprises ont besoin d'une suite complète de solutions pour les sécuriser.

Vax VMM

L'une des premières tentatives pour concevoir un hyperviseur sécurisé est faite par Karger & al lors d’une recherche menée entre 1981 et 1990 sur la production d’un noyau de sécurité Virtual Machine Monitor (VMM). Ce projet de recherche a obtenu le niveau de sécurité A1 par le National Computer Security Center (NCSC). Il s’agit du niveau de sécurité le plus élevé conformément aux critères d’évaluation du Trusted Computer System Evaluation Criterial publié par NCSC en 1985 et qui est également connu sous le nom de Livre Orange. Le développement du noyau de sécurité VMM est effectué à partir de l’extension d’adresse virtuelle de l'architecture VAX conçue par Digital Equipment Corporation au cours des années 1970.

Conformément aux exigences du niveau de sécurité A1, le VAX Hyperviseur prend en compte les systèmes de contrôle d’accès DAC et MAC de toutes les machines virtuelles. Avec MAC, le VMM VAX utilise le modèle de protection Bell-Lapadula Model pour la protection de la vie privée et le modèle de protection d’intégrité Biba.

Le noyau de sécurité VAX prend en compte et fait fonctionner simultanément et en toute sécurité plusieurs machines virtuelles sur un seul système physique VAX tout en assurant l’isolement et le partage contrôlé des données sensibles. Il est doté d’un système d’authentification sécurisé, avec un niveau de performance élevé et des outils de gestion du système très développés soumettant ainsi les machines virtuelles à des contrôles d’accès et d’audits obligatoires. Ainsi chaque machine virtuelle est dotée d’une classe d’accès composée d’une classe secrète et d’une classe d’intégrité similaire aux classes dans les VMS Security Enhancement Services (VMS SES).

Les mécanismes Vax VMM

Pour répondre à la fois aux exigences du niveau élevé de sécurité A1 et aux exigences du monde réel des utilisateurs, les techniques suivantes sont introduites dans le noyau de sécurité VAX.

Architecture Vax VMM

• Création et Modifications de code  : Toute modification apportée au code subit à la fois les révisions de conception avec des revisions du code indépendamment du fait que le code soit fiable ou pas ou qu'il s'agit d'une toute nouvelle couche ou d’une correction de bug. Les révisions de conception même pour les plus petites corrections permettent de s’assurer que les effets sur l’ensemble du système sont pris en compte. Chaque couche a un propriétaire qui participe dans l'examen de la conception et est responsable de la qualité de cette couche. Chaque changement de code est examiné à la fois dans le contexte de sa propre couche, dans les contextes de sa vocation et dans le contexte où il appelle d'autres couches, de manière à prendre en considération les problèmes liés aux inters couches.

Tout comme les contrôles d'accès, les lignes directrices de conception et le code sont obligatoires ou discrétionnaires. Les lignes directrices obligatoires sont fondées sur une expérience préalable dans l'évolution du noyau de sécurité. Des lignes directrices facultatives sont utilisées pour éviter les pièges bien connus dans la programmation et pour avoir des codes lisibles et cohérents.

• Environnement de développement : Le noyau de sécurité VAX est mis en place dans un système de sécurité VAX répondant aux exigences de sécurité A1. Les VMS sont utilisés pour développer et tester les codes non approuvés qui s'exécutent dans les systèmes d’exploitation VMS et ULTRIX-32. Les rôles du gestionnaire de système et du gestionnaire de sécurité sont séparés comme le recommande les critères d’évaluation du NCSC. L'intégration d'une tâche de codage nécessite que le développeur exécute une suite de tests de régression standard. Cette suite de tests de régression se compose de deux parties : les tests de couches et les tests KCALL.
  1. Les tests de couche se déroulent dans le noyau et contrôlent les couches d’interfaces et les tests de routines internes en les appelant directement et en vérifiant leur résultat.
  2. Les essais KCALL fonctionnent dans la machine virtuelle. Ils vérifient l'émission de demandes légales, illégales et malformées pour contrôler l'interface de la machine virtuelle. Une suite de tests séparés supplémentaires émis par la DEC VAX/Test Manager (DTM), est exécutée une fois toutes les deux semaines afin de tester les commandes utilisateur de l’interface.
• Méthode formelle : le niveau de sécurité A1 exige qu'un modèle formel de la politique de sécurité soit écrit, qu'une spécification formelle ou Formal Top-Level Specification(FTLS) de la conception du système soit écrite, qu’elle réponde au modèle de politique de sécurité et qu’il soit démontré que la mise en œuvre du système est en accord avec les FTLS et que les méthodes formelles doivent être utilisées dans l'analyse des canaux cachés du système. Pour répondre à ces exigences les auteurs du VMM VAX utilisent la Méthode Formelle de Développement (FDM) de spécification et de vérification.
• Contrôle de la configuration : un contrôle strict de la configuration est maintenu sur de nombreux articles, y compris des documents de conception, le code du noyau de confiance, des suites de tests, des documents de l'utilisateur et les documents de vérification. Tout le code est maintenu dans le système de gestion pour conserver un historique de chaque changement pour chaque module.
• Répartition de confiance : pour assurer un niveau élevé de confiance à l'utilisateur final d'un noyau sécurisé, le matériel et le logiciel bénéficient de différents critères de répartition de confiance et de sécurité.

Le matériel : les auteurs de Vax VMM mettent en place un programme de sécurité qui permet de fournir une preuve de tentative d’accès par un intrus. Un dispositif de verrouillage se combine avec les procédures de sécurité pour assurer une livraison fiable au client.

Le logiciel : Le logiciel de traitement de la console et le microcode du processeur doivent être installés et cryptographiquement vérifiés avec une succession de contrôle logiciel autonome pour détecter toute falsification ou tentative de falsification. Ensuite, le code de confiance est installé par l'intermédiaire du code VMS non fiable et le résultat est cryptographiquement vérifié pour s’assurer que le code non fiable n'a pas altéré le code de confiance.

Fonctionnement de Vax VMM

À chaque fois qu'un utilisateur veut accéder à une machine virtuelle, il doit d'abord s'authentifier au VMM VAX. À cet effet, le VAX hyperviseur offre un processus de confiance en cours d'exécution dans le noyau. Ce processus ne s'exécute qu’après validation de l’Authentification de l’utilisateur. Puis, le VAX hyperviseur crée un chemin de confiance entre le processus serveur et l'utilisateur. Le serveur fournit des commandes permettant à l'utilisateur de se connecter à une machine virtuelle en fonction de ses droits d'accès. Dans le cas où l'utilisateur a les droits nécessaires pour se connecter à une machine virtuelle une autre voie de sécurité est établie entre l'utilisateur et la machine virtuelle, lui permettant d'interagir avec le système d'exploitation en cours d'exécution dans la machine virtuelle.

En résumé, le VMM VAX offre un niveau de sécurité élevé en répondant aux niveaux d'exigence de sécurité A1 avec non seulement la mise en œuvre des modèles de sécurité formels, DAC, MAC, de l'analyse des canaux cachés mais aussi aux exigences du monde réel avec une distribution sécurisée des ressources finales et un niveau élevé de confiance à l'utilisateur.

Terra

En 2003, Tal Garfinkel et al ont écrit un article présentant une Machine virtuelle basée sur une plateforme de confiance appelée Terra. L'architecture Terra est basée sur un moniteur de machine virtuelle qui permet à plusieurs machines virtuelles d'être multiplexées sur une seule machine physique. Terra utilise le moniteur de machine virtuelle sécurisée appelée Trusted Virtual Monitor Machine (TVMM). L’architecture TVMM propose des services variés avec des mécanismes de protection avancés.

Les avantages Terra

• Isolement : le TVMM permet d’exécuter plusieurs applications dans différentes machines virtuelles. Chaque machine virtuelle s’exécute dans son propre domaine matériel offrant ainsi une isolation forte entre les machines virtuelles. L'isolement sécurisé est essentiel pour fournir la confidentialité et l'intégrité requises par la boîte fermée des machines virtuelles.
• Extensibilité : Terra propose une approche unique pour fournir un système d'exploitation pour la plate-forme de confiance en faisant converger toutes les applications vers une même interface. Pour permettre aux concepteurs d'applications de sélectionner le système d'exploitation qui répond le mieux à leurs exigences en matière de sécurité, de compatibilité et de performance tout en leur permettant d’inclure uniquement les composants nécessaires à leurs applications, Terra leur met à disposition une Open-box VM et une Closed-box. Contrairement à la Closed-box VM, la Open-box VM n'est pas spécialement protégée par le TVMM.
• Compatibilité : Terra peut exécuter les systèmes d'exploitation actuels comme Linux et Microsoft Windows et les applications sans modification.
• Sécurité : avec TVMM, Terra propose trois fonctionnalités supplémentaires qui ne se trouvent pas dans les VMM traditionnels. Ces fonctions sont essentiellement comprises dans une boîte fermée ou (closed-box). Il s'agit de :
  1. Racine sécurisée : l’administrateur de la plate-forme ne peut pas briser les garanties de base de confidentialité et d'isolement de la TVMM fournit par la boîte fermée.

     

     Attestation de Terra

  2. Attestation (voir schéma ci-contre) : cette fonction permet à une application qui s'exécute dans une boîte fermée de s'identifier cryptographiquement à un tiers distant, c'est-à-dire d'informer la partie distante de ce qui est exécuté à l'intérieur de la boîte fermée. Ce qui permet à la partie distante de faire confiance à la demande et de savoir que l'application se comportera comme souhaité. Le processus de certification comporte les 3 étapes pour chaque composant :
     1. Le composant qui veut être certifié doit fournir sa paire de clé publique/clé privée
     2. Ensuite le composant remet sa clé publique et les données d’application supplémentaires du composant de niveau inférieur qu’il veut valider en utilisant la norme "ENDORSE" API.
     3. Le composant de niveau inférieur utilise sa clé privée pour signer le certificat qui contient la clé publique et les données d’application supplémentaires qu’il a reçu ainsi que le hachage des parties attestables du composant de niveau supérieur.
  3. Chemin de confiance : TVMM fournit un trajet sécurisé entre l'utilisateur et l'application. Ce chemin de confiance est essentiel pour bâtir des applications sécurisées. La voie de sécurité proposée par TVMM permet à un utilisateur de déterminer quelles sont les machines virtuelles qui tournent tout en permettant à une machine virtuelle de s'assurer qu'il communique avec un utilisateur humain. Le chemin de confiance proposé assure également la protection des renseignements personnels et l'intégrité des communications entre les utilisateurs et les machines virtuelles, ce qui empêche l'altération par des programmes malveillants.

Les mécanismes Terra

Pour atteindre ces objectifs en matière de sécurité le TVMM offre une interface pour le maintien de l'application en sécurité. À cet effet, Terra fournit plusieurs classes de disques virtuels qui sont utilisés pour assurer la Confidentialité et l'intégrité des données. Le TVMM chiffre/déchiffre et HMAC les données d’une VM au nom de cette VM assurant ainsi l'intimité du stockage et de l'intégrité.

• Le TVMM utilise la technique de HMAC pour empêcher toute manipulation des disques dont l’intégrité reste importante bien qu’ils n'exigent pas de vie privée.
• Pour la mise en œuvre de l'attestation, le TVMM utilise une table de hachage et s’assure que les données chargées correspondent effectivement à ses hachages. Si les paragraphes d'une entité hachée doivent être vérifiés de façon indépendante, Terra divise les paragraphes en bloc de taille fixe et chaque bloc est haché séparément.
• Pour l’attestation d’interface, le TVMM fournit une interface étroite à coffret fermé pour soutenir l’attestation. Cette interface fournit les opérations suivantes :

Cert ← Endorse (cert-req) :

La commande met le hachage de la VM dans le champ du nom commun d'un certificat et place le contenu de cert-req dans le certificat. L’interface signe le certificat avec la clé privée du TVMM et il revient à la machine virtuelle. L'argument cert-req contient la clé publique de la machine virtuelle et toutes autres données d'application utilisées pour authentifier la machine virtuelle. Cette fonction constitue la base de l'attestation.

Hash ← GET-ID() :

La commande récupère les hachages de la machine virtuelle d'appel. Cet appel est utile pour une machine virtuelle qui souhaite vérifier si le hachage dans l'attestation d'un tiers distant correspond à sa propre hachage.

• Gestion de l’interface : Terra délègue des fonctions d'administration de la VM à une machine virtuelle spéciale appelée gestionnaire de VM. Il fournit une interface utilisateur pour le démarrage, l'arrêt et la commande de l'exécution des machines virtuelles, et la connexion VM via des interfaces de périphériques virtuels. Le TVMM fournit des services de base, comme support pour l'exécution de plusieurs machines virtuelles isolées mais le gestionnaire de VM est responsable pour l'affectation des ressources de niveau supérieur et de la gestion.

Architecture Terra

En conclusion, Terra présente une architecture très flexible qui fournit certaines fonctions de sécurité très importantes dont l'attestation. Toutefois, pour pouvoir utiliser toutes les fonctions de sécurité offertes par Terra, le système doit être exécuté sur du matériel inviolable. Ce qui n’est pas le cas pour les puces matérielles pour PC. Ceci étant, cela peut changer dans un proche avenir avec le Module TPM implémenté dans les PC depuis 2010.

sHype

L'architecture de sécurité sHype est surement l’une des approches les plus connues quand il s’agit de créer un hyperviseur sûr. Elle est née d’un projet de recherche d’IBM développé pour IBMs rHype avec un hyperviseur open-source. Peu de temps après la sortie de sa première version, elle est implémentée dans un hyperviseur Open source. Son objectif principal est de contrôler les flux d’information explicites entre les machines virtuelles. sHype utilise la politique de sécurité formelle MAC.

sHype utilise le concept d'un moniteur de référence qui applique les relations d’accès autorisées entre les sujets et objets d'un système. Cela signifie que le moniteur de référence est appelé chaque fois qu’un utilisateur veut accéder à un objet. Toutefois, le moniteur de référence ne décide pas si un utilisateur peut accéder à un objet. Il impose seulement la décision qui est souvent prise ailleurs dans le système. C’est le Module de Contrôle d’Accès (MAC) qui est responsable de cette décision. Le MAC utilise la politique de sécurité formelle avec des étiquettes qui sont fixées sur les sujets et les objets du système et le type d'opération qu’un sujet peut exécuter pour rendre une Access Control Decision (DAC). Ainsi le flux de travail complet que le système exécute si un sujet tente d'accéder à un objet est la suivante : l'appel d'accès de l'objet est intercepté par le moniteur de référence, qui à son tour appelle le MAC en plaçant une requête d'autorisation (Authorization Query : AQ). Cet AQ contient les étiquettes de l'objet et les opérations qui peuvent être exécutées sur l'objet (lecture, écriture ...). Le MAC utilise la politique de sécurité formelle et les données de l'AQ pour faire un DAC qui est ensuite renvoyé à l'écran de référence. Enfin, le moniteur de référence applique le DAC en autorisant ou en refusant d’exécuter l'opération. Dans ce processus, le moniteur de référence est effectivement mis en œuvre en utilisant des crochets d'exécution qui sont répartis sur l'hyperviseur.

Les mécanismes sHype

L'élément clé de l'architecture sHype pour répondre à son objectif de contrôler les flux d’information explicites entre les machines virtuelles est le moniteur de référence qui isole sHype des machines virtuelles et permet le partage des ressources entre les machines virtuelles uniquement si cela est permis par un contrôle d’accès obligatoire (Mandatory Access Control).

Par l’intermédiaire de MAC, sHype applique la politique de contrôle d'accès basée sur l'application des contraintes inter-partition aux flux d'information. sHype contrôle le flux d'information explicite par l'utilisation de ressources partagées explicitement virtuel (ex : VLAN) pour garantir la surveillance de l’accès non exclusif aux ressources de la partition virtuelle et assurer l’assignement exclusif des ressources virtuelles aux partitions.

Le contrôle d’accès aux domaines MAC limite l'accès aux ressources virtuelles uniquement à des domaines qui appartiennent à la même coalition que la ressource virtuelle. Les domaines MAC deviennent ainsi partie intégrante de la base informatique sécurisée ou Trusted Computing Base.

sHype utilise l’attestation Trusted Platform Module qui offre la possibilité de générer et d’apporter des mesures d'intégrité d'exécution sur l'hyperviseur et les Machines virtuelles. Cela permet aux systèmes distants de déduire les propriétés d'intégrité du système en cours d'exécution.

Pour répondre aux exigences métier, sHype utilise les différentes politiques MAC comme le Modèle de Biba, le Modèle Bell-LaPadula, Caermarvon ainsi que le Chinese Wall.

En conclusion, la sécurité proposée par le sHype repose sur l'isolement fourni par le noyau qu’il complète par la supervision du partage des ressources entre les machines virtuelles. Le sHype agit en tant que médiateur à l'intérieur de l'hyperviseur et entre les machines virtuelles dans la gestion des ressources en fonction de la politique de sécurité active et du contrôle d'accès dans les communications inter-virtuelles. Tout ceci concourt à une grande flexibilité de l’architecture sHype avec des politiques de sécurité mesurées et indépendantes de la mise en œuvre technique.

HyperWall

Une autre approche pour assurer la sécurité est proposée avec l’architecture HyperWall. Il s’agit de protéger les machines virtuelles invitées à partir d'un hyperviseur non fiable. Avec HyperWall, l’hyperviseur gère librement la mémoire, les cœurs de processeur et d'autres ressources d'une plate-forme. Une fois les machines virtuelles créées, le CIP (Confidentiality and Integrity Protection) protège la mémoire des machines virtuelles invitées à partir de l'hyperviseur ou par le DMA(Direct Memory Access) selon les spécifications du client. Le client peut spécifier que certaines plages de mémoire soient protégées contre les accès par l'hyperviseur ou par le DMA. L’HyperWall est l’élément clé qui assure la protection de la confidentialité et de l'intégrité des objets qui ne sont accessibles que par le matériel. Ils protègent tout ou partie de la mémoire d'une machine virtuelle basée sur les spécifications du client.

Les mécanismes HyperWall

Pour assurer son objectif de protéger les machines virtuelles invitées quand l’hyperviseur est compromis, l’HyperWall utilise les mécanismes de protection qui sont détaillées ci-dessous :

Architecture HyperWall

De nouvelles tables de protection de confidentialité et d'intégrité (CIP) sont introduites dans les machines virtuelles pour garantir à la fois la confidentialité et l’intégrité des données de la machine virtuelle et les codes des régions de la machine virtuelle que le client souhaite protéger. L’utilisation des tables CIP pour isoler la machine virtuelle est combinée à la cryptographie pour augmenter la sécurité.

• Les tables CIP : l’architecture de HyperWall est conçue de manière qu’une partie de la mémoire physique DRAM puisse être utilisée pour mémoriser les tables CIP. L’affectation de cette portion de la mémoire est faite au démarrage de l'ordinateur par le contrôleur de mémoire DRAM. Les tables CIP ne sont accessibles qu’au matériel. Les tables CIP stockent la cartographie de l'hyperviseur et les droits d'accès du DMA aux pages mémoire de la machine. Ces informations sont utilisées pour assurer les protections de la mémoire de la machine virtuelle invitée. Pour chaque page mémoire de la machine, la table CIP stocke les bits de protection qui sont utilisés pour coder les informations de protection de la page. Les tables CIP sont consultées par l’Unité de Gestion de la Mémoire (MMU) dans le microprocesseur lors de l'exécution du code de l’hyperviseur pour vérifier qu'un emplacement mémoire peut être consulté.
• Protection des régions de la mémoire : quand une machine virtuelle invitée est en marche, la mémoire physique utilisée par cette machine est protégée. De plus, les tables CIP protègent la mémoire qui contient les tables de pages avec la cartographie de la mémoire de la machine physique (marquée P2M tables) pour le client. Au cours d'une mise à jour de la cartographie de la mémoire, la cartographie ancienne (tables P2M) et la nouvelle cartographie (marquée tables P2M suivantes) sont protégées. Les protections demandées par le client sont stockés dans la zone marquée pré-CIP. Le pré-CIP précise les pages auxquelles l’accès par l’hyperviseur ou par le DMA est autorisé ou interdit. Le pré-CIP doit être sauvegardé afin que les protections d'origine puissent être demandées et vérifiées à chaque fois que l'hyperviseur tente de mettre à jour la cartographie de la mémoire de l’invité.
• Les Clés cryptographiques : la stratégie de protection des tables CIP est l’isolement par un contrôle d’accès matériel. Pour renforcer la sécurité apportée par l’isolement elle est combinée à la cryptographie qui permet à un client de valider véritablement le serveur HyperWall. Par conséquent, la clé privée SKcpu est insérée dans la puce du microprocesseur et n'est pas accessible à n'importe quel autre logiciel.

D’autres clés telles que Kenc et Khash sont utilisées par le matériel HyperWall et sont stockées dans la mémoire protégée. Les clés sont générées au cours de chaque cycle d'amorçage. Elles sont utilisés chaque fois qu'une machine virtuelle est interrompue. Les clés sont stockées dans des endroits protégés de la mémoire partagée DRAM.

Une autre clé privée unique PKvm est introduite dans chaque machine virtuelle. Cette clé est stockée à l'intérieur de la zone de mémoire qui est spécifiée comme privée et interdite d’accès à l’hyperviseur et au DMA.

Avec HyperWall, l'hyperviseur est capable de gérer entièrement la plateforme, pour démarrer, mettre en pause ou en arrêt les machines virtuelles ou de modifier l'affectation de la mémoire, de vérifier que l'hyperviseur n’a pas un comportement contraire à ce qui est attendu. Pour ce faire, l’HyperWall fournit des données de hachage pour attester que l'image du client VM initiale et les protections spécifiées étaient instanciées lors du lancement de la machine virtuelle. En outre, les preuves de confiance peuvent être générées pendant la durée de vie de la machine virtuelle pour vérifier que ses protections spécifiées ne sont pas corrompues. Lorsque la machine virtuelle est interrompue, sa mémoire protégée est mis à zéro par le matériel pour prévenir la fuite de données ou de code. Ainsi l'hyperviseur et le DMA retrouvent les droits d'accès à la mémoire de la machine virtuelle.

Trusted eXecution Technology

En 2009, David Grawrock annonce la notion de Trusted Computing avec une approche modulaire de la conception de la sécurité des plateformes et PC dans son livre Dynamics of a Trusted Platform. Le processeur Intel Trusted Execution Technology (TXT) est un bloc utilisé pour créer une plateforme sécurisée en implémentant des fonctionnalités de sécurité et de nouvelles capacités dans le processeur. L’utilisation de la technologie d’exécution fiabilisée Intel TXT permet la protection de l’infrastructure informatique contre les attaques logicielles au démarrage d’un serveur ou d’un ordinateur.

Le fonctionnement de Intel TXT

Intel TXT fonctionne en créant un environnement de lancement mesuré (MLE) qui permet de lancer certains éléments essentiels de l'environnement par rapport à une source connue servant de référence. Intel TXT crée un identifiant cryptographique unique pour chaque lancement de code approuvé. Ce mécanisme permet de bloquer le lancement des codes non approuvés. Cette solution basée sur la sécurisation du matériel fournit la plateforme sécurisée sur laquelle les solutions de confiance peuvent être déployées pour se protéger contre les attaques logicielles qui menacent l'intégrité, la confidentialité, la fiabilité et la disponibilité du système.

Les avantages de Intel TXT

• Lancement vérifié : Intel offre une chaîne basée sur le matériel de confiance qui permet le lancement de l’environnement MLE dans un bon état. Tout changement de l’environnement MLE est détecté par des mesures cryptographiques.
• Lancer la politique de contrôle : Intel TXT propose un moteur de règles pour la création et la mise en œuvre de la liste des codes approuvés pour exécution.
• Protection des secrets : Intel TXT offre une assistance matérielle avec des méthodes qui éliminent les données résiduelles après un arrêt incorrect du MLE en assurant la protection des données contre l’espionnage de la mémoire par des logiciels et contre la réinitialisation des attaques.
• Attestation : Intel TXT fournit des informations d'identification de mesure de la plateforme pour les utilisateurs locaux ou distants pour compléter le processus de vérification de la confiance et le soutien aux contrôles d’audit.

Les mécanismes Intel TXT

Pour atteindre ses objectifs, les serveurs Intel TXT intègrent :

• de nouvelles innovations de traitement sécurisé telles que  :
  • l’intégration de l’extension sécurisée dans le silicium (processeur Intel Xeon et Chipset)
  • le module d’authentification des codes (MAC)
  • le lancement des outils de la politique de contrôle
• des composants importants qui proviennent également d'autres entités comme :
  • Trusted Platform Module (TPM)
  • Intel TXT BIOS compatible avec l’hyperviseur et le système d’exploitation

L’intégration de ces éléments est complétée par les principales caractéristiques des deux méthodes suivantes dans ces serveurs pour avoir une racine de confiance ou Root of Trust :

• La première méthode est Racine de Confiance de Mesure Dynamique ou Dynamic Root of Trusted for Measurement (D-RTM) où les propriétés de confiance des composants sont ignorées jusqu'à ce qu'un évènement sécurisé se déclenche et initialise le système à partir de la racine de la mesure initiale . L’utilisation de cette méthode permet à Intel TXT d’introduire certains éléments du BIOS dans Trusted Computing Base (TCB) pour détecter l’état de lancement.
• La seconde méthode est appelée Racine de Confiance de Mesure Statique ou Static Root of Trust for Measurement (S-RTM) qui commence avec une réinitialisation des éléments de la plateforme et de la racine immuable (comme un bloc d'initialisation du BIOS) et se poursuit dans le système d'exploitation et ses composants.

L'architecture Intel TXT utilise le modèle S-RTM pour fournir des méthodes pour mesurer et enregistrer dans le module TPM un des logiciels du système qui se trouve dans la zone de confiance .

Intel TXT

Utilisation de Intel TXT

Cette approche est utilisée par VMware ESXi pour renforcer la sécurité matérielle dans sa nouvelle architecture vSphere 5.0 et a supprimé le système d’exploitation en Console (COS) et les fonctionnalités d’administration nécessaires ont été directement intégrées dans le noyau VM kernel au cœur de l’architecture. La suppression des failles de sécurité associées au système d’exploitation générique contribue à améliorer la sécurité et la fiabilité.

Hypersafe

En 2010, toujours dans l’optique de sécuriser les hyperviseurs Xuxian Jiang et son étudiant en doctorat Zhi Wang proposent l’Isolation de l’hyperviseur via Hypersafe. Il s’agit d’un logiciel appelé HyperSafe qui tire parti des fonctionnalités matérielles existantes pour garantir les hyperviseurs contre de telles attaques. Les programmes malveillants doivent exécuter leur propre code dans l’hyperviseur. Pour éviter que cela se produise, le logiciel Hypersafe utilise une technique de verrouillage mémoire non contournable qui interdit de manière fiable l’introduction d’un nouveau code dans l’hyperviseur par une personne en dehors de l’administrateur de l’hyperviseur tout en empêchant toute tentative de modification du programme source de l’hyperviseur par des utilisateurs externes par la technique d’indexation.

Les mécanismes Hypersafe

Pour répondre à ses objectifs de protéger l’hyperviseur, les auteurs de Hypersafe utilisent un matériel de confiance de type TPM assistée d’une racine statique/dynamique (Trusted Boot) où sont implémentées les deux techniques principales suivantes :

• La technique de la pagination de la mémoire : elle permet le verrouillage de la mémoire qui devient non contournable et restreint ainsi son accès. Une fois qu'une page de mémoire est verrouillée, cette technique impose que la page soit déverrouillée pour être modifiée. Et par cette conception, la logique de déverrouillage interdit toute tentative de modification du code source de l’hyperviseur et l’exécution d’un code malveillant dans l’espace de l’hyperviseur. Il s’agit donc d’un verrouillage des pages mémoire protégées en écriture (les données sont en lecture seule), ainsi que leurs attributs (dans les tables de pages), empêchant ainsi leur modification et de-là, garantit l’intégrité du code hyperviseur.
• La technique de limitation du pointeur d’indexation : elle s’appuie essentiellement sur la technique de verrouillage de la mémoire et étend la couverture de la protection du code hyperviseur pour contrôler les données. Elle consiste à appliquer une mesure de sécurité puissante qui est l’intégrité du contrôle de flux (CFI). Le CFI dicte strictement le chemin d’exécution du logiciel. Si les chemins d'exécution du logiciel suivent le graphe de contrôle, les attaquants ne peuvent pas contrôler le flux d'exécution du système.

En conclusion et comme le dit Jiang : “We can guarantee the integrity of the underlying hypervisor by protecting it from being compromised by any malware downloaded by an individual user, ” “By doing so, we can ensure the hypervisor’s isolation.”, le logiciel Hypersafe garantit seulement l'isolation de l'Hyperviseur et pas son intégrité en le protégeant contre les attaques malveillantes.

Comparaison des architectures de sécurisation proposées

Les approches énumérées ci-dessus pour sécuriser les hyperviseurs proposent dans l’ensemble un niveau de sécurité élevé mais avec quelques nuances.

Le VAX Hypervisor propose le plus haut niveau de sécurité car cette approche répond au niveau d’exigence de sécurité A1 du NCSC en combinant :

• les niveaux de sécurité formels
• les modèles d’accès de sécurités MAC et DAC additionnés d’un système de détection d’intrus
• des fonctions d’audit

En plus des fonctions de sécurité, le Vax Hyperviseur impose des obligations pour le processus de développement logiciel avec des normes de codage sécurisées. Cependant, ce haut niveau de sécurité est limité à la plateforme VMM VAX sans prendre en compte les processeurs VAX. l’architecture proposée par le Vax Hypervisor est complexe et peu flexible.

L’architecture Terra offre une bonne flexibilité sans apporter un niveau de sécurité similaire à ceux de VAX Hyperviseur et de SHype. Ceci est du essentiellement au fait que Terra ne propose pas le mandataire d’accès contrôlé (MAC). De ce fait, Terra n’est pas en mesure de sécuriser de façon fiable la circulation des informations. Terra reste donc une architecture très flexible qui s’adapte au besoin avec les boites Open-Box et Closed-Box.

sHype offre une architecture très souple avec l’option MAC lui permettant de respecter les différents modèles de sécurité formels. Avec MAC, sHype gère les flux d'information explicites et offre des garanties d'intégrité du contenu. Aussi, le SHype sécurise la circulation des informations en la limitant à lui-même et réduit également le nombre de canaux cachés dans l'architecture. sHype s’appuie sur l’isolement fournit par le noyau et traduit l'isolement sous-jacent de la machine virtuelle dans les propriétés d'isolation liées aux charges différentes de travail. Les canaux cachés constituent un problème pour l’architecture sHype. Ce problème peut être résolu dans un proche avenir avec les travaux en cours. Ces travaux en cours vont permettre une attestation à distance pour sHype. Le sHype ne repond pas aujourd’hui aux objectifs fixés contrairement à l’architecture Vax Hypervisor. Cependant, le niveau de sécurité offert par sHype est convenable et sera amélioré avec les travaux en cours dans un proche avenir.

Il est à noter que pour sécuriser les hyperviseurs, il faut vérifier que le système est mis en œuvre correctement et ne contient aucune lacune grave susceptible de compromettre la sécurité de l’ensemble du système.

Liens externes

• (fr) IBM Corporation, « IBM System Virtualization », 2005
• (en) Clark Scheffy, « Virtualization for dummies, AMD Special Edition », Wiley Publishing, Inc.,‎ 2007 (ISBN 9780470131565)
• (fr) Schauer Hervé, « VMware et sécurité », HSC, juin 2008, p. 5-7
• (en) Dico du Net, « DicoNet »
• (en) Marc De Villepin, « Cloud computing et apports aux métiers de l'entreprise »
• (en) Vmware, « Virtualisez votre infrastructure informatique »
• (en) Nicolas Aubé, « La virtualisation : économie, écologie et performance »
• (en) Reseau Informatique, « Virtualisation : quels enjeux pour l'entreprise ? »
• (en) Clusir, « Virtualisation de la sécurité ou Sécurité de la virtualisation » [archive du 22 juin 2013] (consulté le 24 janvier 2013)
• (en) Shengmei Luo, « Virtualization security for cloud computing service », IEEE Conference Publications,‎ décembre 2011, p. 176 (DOI 10.1109/CSC.2011.6138516)
• (en) G. Aljabari, « Virtualization of IT infrastructure for small and medium businesses », IEEE Conference Publications,‎ juin 2012, p. 129 - 133 (DOI 10.1109/ICCITechnol.2012.6285775)
• (fr) Jakub Szefer et Ruby Lee, « Architectural support for hypervisor-secure virtualization », mars 2012
• (fr) Secrétariat général de la sécurité nationale, « Problématiques de sécurité associées à la virtualisation des systèmes d’information », mai 2012, p. 7-11
• (fr) Gengembre Charles, « Sécurité des infrastructures virtualisées », Les Echos, avril 2012
• (fr) Premier Ministre, « Agence nationale de la sécurité des systèmes d'information », 2012
• (en) « ExpertGlossary »
• (en) chen/zan, « A Case for Secure and Scalable Hypervisor using Safe Language »
• (en) colp/nanazati/zhu/aiello/coker/deegan/loscocco/warfiel, « Breaking Up is Hard to Do: Security and Functionality in a. Commodity Hypervisor »
• (en) Jenni Susan Reuben, « A Survey on Virtual Machine Security »
• (en) Jakub Szefer, Eric Keller, Ruby B. Lee and Jennifer Rexford, « Eliminating the Hypervisor Attack Surface for a More Secure Cloud »
• (en) Prashant Dewan, David Durham, Hormuzd Khosravi, Men Long, Gayathri Nagabhushan, « A Hypervisor-Based System for Protecting Software Runtime Memory and Persistent Storage »
• (en) Krishna Chaltanya.Y, Bhavani Shankar.Y, Kali Rama Krishna.V, V Srinivasa Rao, « Study of security issues in cloud computing »
• (en) Diego Perez-Botero, « A Brief Tutorial on Live Virtual Machine Migration From a Security Perspective » [archive du 3 mars 2016] (consulté le 24 janvier 2013)
• (en) Jyoti Shetty, Anala M R, Shobha G, « A Survey on Techniques of Secure Live Migration of Virtual Machine »
• (en) Cuong Hoang H. Le, « Protecting Xen hypercalls »
• (en) Udo Steinberg /Bernhard Kauer, « NOVA: A Microhypervisor-Based Secure Virtualization Architecture »
• (en) Yinqian Zhang/Ari Juels/Michael K. Reiter/Thomas Ristenpart, « Cross-VM Side Channels and Their Use to Extract Private Keys »
• (en) Bhrugu Sevak, « Security against Side Channel Attack in Cloud Computing » [archive du 1^er avril 2015] (consulté le 24 janvier 2013)
• (en) Dimitri McKay, « A Deep Dive Into Hyperjacking »
• (en) Jon Oberheide, Evan Cooke, Farnam Jahanian, « Empirical Exploitation of Live Virtual Machine Migration »

• (en) Hidekazu Tadokoro, Kenichi Kourai,Shigeru Chiba, « Preventing Information Leakage from Virtual Machines’ Memory in IaaS Clouds »
• (en) Paul A. Karger, Mary E Zurko, Douglas W Bonin, Andrew H Mason et Clifford E Kahn, « A VMM Security Kernel for the VAX Architecture », 1990, p. 14
• (en) Paul A. Karger, Mary E Zurko, Douglas W Bonin, Andrew H Mason et Clifford E Kahn, « A Retrospective on The VAX VMM Security Kernel », novembre 1991
• (en) Donald C. Latham, « Department of Defense Trusted Computer System Evaluation Criteria », décembre 1985
• (en) Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum, Dan Boneh et R. Goldberg, « Terra : A Virtual Machine-Based Platform for Trusted Computing », décembre 2003
• (en) H. Scherzer, R. Canetti, P. A Karger H. Krawczyk, T Rabin et D.C. Toll, « Authenticating Mandatory Access Controls and Preserving Privacy for a High-Assurance Smart Card », 2003, p. 192-197
• (en) Paul A. Karger, Mary E Zurko, Douglas W Bonin, Andrew H Mason et Clifford E Kahn, « A VMM Security Kernel for the VAX Architecture », p. 2-19
• (en) Jakub Szefer et Ruby B Lee, « Architectural Support for Hypervisor-Secure Virtualization », mars 2012

• http://www.nist.gov/index.html

Articles connexes

• Input–output memory management unit (en)