Une machine virtuelle (VM) peut-elle pirater une autre machine virtuelle exécutée sur la même machine physique?

Des questions:

• si une machine virtuelle est corrompue (piratée), qu'est-ce que je risque sur d'autres machines virtuelles exécutées sur la même machine physique?
• Quel genre de problèmes de sécurité existe-t-il entre les machines virtuelles exécutées sur le même hôte physique?
• Existe-t-il (pouvez-vous dresser) une liste de ces faiblesses et / ou problèmes (potentiels)?

Avertissement:

Je sais que de nombreux types / solutions de virtualisation existent et peuvent présenter différentes faiblesses. Cependant, je recherche principalement des problèmes de sécurité généraux concernant les techniques de virtualisation, plutôt qu'un bug de fournisseur particulier.

Veuillez fournir des faits réels, des études (sérieuses), des problèmes rencontrés ou des explications techniques. Être spécifique. Ne donnez pas (seulement) votre avis.

• Exemples:

Il y a deux ans, j'ai entendu dire qu'il pourrait y avoir des problèmes de sécurité liés à la MMU (accéder à la mémoire principale d'autres machines, je pense), mais je ne sais pas si c'est une menace pratique à ce jour, ou juste une recherche théorique matière.

EDIT: J'ai également trouvé cette attaque "Flush + Reload" capable de récupérer des clés secrètes GnuPG sur la même machine physique, en exploitant le cache CPU L3, même si GnuPG fonctionne sur une autre VM. GnuPG a été corrigé depuis.

Bien sûr, il est possible d'exploiter une autre VM fonctionnant sur le même matériel, à condition qu'un exploit fonctionne. De plus, un peut exister. Votre question cite des travaux récents en montrant un. Je ne vais pas partager d'exploits spécifiques ou de PoC ici, mais je serai heureux de dire comment ils peuvent être réalisés.

Les exploits utilisés dans ce contexte sont naturellement différents de ceux qui fonctionnent lorsque vous exécutez sur la même machine sur laquelle vous essayez d'exploiter un service, et ils ont tendance à être un peu plus difficiles en raison de l'isolement accru. Cependant, certaines approches générales qui peuvent être utilisées pour accomplir un tel exploit incluent:

• Attaquez l'hyperviseur . Si vous pouvez obtenir un shell suffisamment privilégié sur l'hyperviseur donné à une machine virtuelle, vous pouvez prendre le contrôle de n'importe quelle machine virtuelle sur le système. La façon d'aborder cela consiste à rechercher les flux de données qui existent de la machine virtuelle vers l'hyperviseur et qui dépendent fortement de l'hyperviseur; des éléments comme les pilotes paravirtualisés, le partage du presse-papiers, la sortie d'affichage et le trafic réseau ont tendance à créer ce type de canal. Par exemple, un appel malveillant à un périphérique réseau paravirtualisé peut conduire à l'exécution de code arbitraire dans le contexte de l'hyperviseur responsable de la transmission de ce trafic au pilote NIC physique.
• Attaquez le matériel sur l'hôte . De nombreux appareils permettent des mises à jour du micrologiciel, et s'il s'avère possible d'accéder au mécanisme pour cela à partir d'une machine virtuelle, vous pouvez télécharger un nouveau micrologiciel qui favorise vos intentions. Par exemple, si vous êtes autorisé à mettre à jour le micrologiciel sur la carte réseau, vous pouvez le faire dupliquer le trafic lié à une adresse MAC (celle de la victime), mais avec une autre adresse MAC de destination (la vôtre). Pour cette raison, de nombreux hyperviseurs filtrent ces commandes lorsque cela est possible; ESXi filtre les mises à jour du microcode du processeur lorsqu'elles proviennent d'une machine virtuelle.
• Attaquer l'architecture de l'hôte. L'attaque que vous avez citée, essentiellement une autre attaque de divulgation de clé basée sur le timing, fait cela: elle exploite l'impact du mécanisme de mise en cache sur le timing de l'opération pour discerner les données utilisées par la machine virtuelle victime dans ses opérations. Au cœur de la virtualisation se trouve le partage de composants; lorsqu'un composant est partagé, la possibilité d'un canal latéral existe. Dans la mesure où une autre machine virtuelle sur le même hôte est capable d'influencer le comportement du matériel lors de l'exécution dans le contexte de la machine virtuelle victime, la machine virtuelle victime est contrôlée par l'attaquant. L'attaque référencée utilise la capacité de la machine virtuelle à contrôler le comportement du cache CPU (état universel essentiellement partagé) afin que les temps d'accès à la mémoire de la victime révèlent plus précisément les données auxquelles elle accède; partout où existe un état mondial partagé, la possibilité d'une divulgation existe également. Pour entrer dans l'hypothétique pour donner des exemples, imaginez une attaque qui masse le VMFS d'ESXi et fait que des parties de volumes virtuels référencent les mêmes adresses de disque physique, ou une attaque qui fait croire à un système de ballon de mémoire qu'une partie de la mémoire peut être partagée alors qu'en fait, elle devrait être privé (c'est très similaire à la façon dont les exploits d'utilisation après libération ou de double allocation fonctionnent). Considérons un MSR CPU hypothétique (registre spécifique au modèle) auquel l'hyperviseur ignore mais autorise l'accès; cela pourrait être utilisé pour transmettre des données entre machines virtuelles, rompant l'isolement que l'hyperviseur est censé fournir. Considérez également la possibilité que la compression soit utilisée afin que les composants en double des disques virtuels ne soient stockés qu'une seule fois - un canal latéral (très difficile) peut exister dans certaines configurations où un attaquant peut discerner le contenu des autres disques virtuels en écrivant sur le sien et en observant ce que fait l'hyperviseur. Bien sûr, un hyperviseur est censé se prémunir contre cela et les exemples hypothétiques seraient des bogues de sécurité critiques, mais parfois ces choses passent à travers.
• Attaquez directement l'autre VM . Si vous avez un hôte proximal vers la machine virtuelle victime, vous pourrez peut-être bénéficier d'un contrôle d'accès détendu ou d'une communication intentionnelle entre machines virtuelles selon la configuration de l'hôte et les hypothèses émises lors du déploiement du contrôle d'accès. Ce n'est que légèrement pertinent, mais cela mérite d'être mentionné.

Des attaques spécifiques surviendront et seront corrigées au fil du temps, il n'est donc jamais valable de classer un mécanisme particulier comme étant exploitable, exploitable uniquement dans des conditions de laboratoire ou inexploitable. Comme vous pouvez le voir, les attaques ont tendance à être impliquées et difficiles, mais celles qui sont réalisables à un moment donné sont quelque chose qui change rapidement, et vous devez être prêt.

Cela dit, les vecteurs que j'ai mentionnés ci-dessus (à l'exception peut-être du dernier dans certains cas) n'existent tout simplement pas dans les environnements de métal nu. Alors oui, étant donné que la sécurité consiste à se protéger contre les exploits que vous ne connaissez pas et qui ne sont pas dans la nature ainsi que ceux qui ont été divulgués publiquement, vous pouvez gagner un peu de sécurité en exécutant en métal nu ou à au moins dans un environnement où l'hyperviseur n'héberge pas de VM pour tout le monde.

En général, une stratégie efficace pour la programmation d'applications sécurisées consisterait à supposer qu'un ordinateur a d'autres processus en cours d'exécution qui pourraient être contrôlés par des attaquants ou malveillants et à utiliser des techniques de programmation sensibles aux exploits, même si vous pensez que vous ne garantissez pas un tel processus existe dans votre VM. Cependant, en particulier avec les deux premières catégories, rappelez-vous que celui qui touche le matériel gagne en premier.

En théorie, non. L'intérêt de l'hyperviseur est d'isoler les machines virtuelles les unes des autres.

Dans la pratique, il y a eu (et il pourrait y avoir à l'avenir) des bogues de sécurité dans divers hyperviseurs qui pourraient permettre à une machine virtuelle d'affecter l'hyperviseur ou d'autres machines virtuelles sur le même hôte. Des mesures de sécurité telles que sVirt (pour KVM / QEMU) sont destinées à résoudre ce problème.

Edit: Je pensais que ce sujet avait été fait il y a des mois, mais il vient d'être relancé et maintenant OP demande plus de `` faits réels, d'études citées '', etc., alors j'ai compris ce que le diable.

Les exploits de cette nature sont:

1. Rare
2. Sensibles par nature et donc non partagés ouvertement, et lorsqu'ils le sont, les exploits seront corrigés par le vendeur avant que quiconque sur ce site ne les connaisse
3. Compliqué et variera selon le fournisseur

Nous ne pouvons pas dire qu'il est impossible de pirater un hyperviseur et d'accéder à d'autres machines virtuelles. Nous ne pouvons pas non plus quantifier le risque, sauf que l'expérience nous montre qu'il est assez faible, étant donné que vous ne trouverez pas beaucoup d'histoires d'attaques utilisant des exploits d'hyperviseur.

Voici une sorte d'article intéressant à l'effet contraire qui suggère que plus de quelques attaques basées sur l'hyperviseur ont été exécutées.

Cependant, la technologie dépendant d'hyperviseurs maintenant plus que jamais, de tels exploits seraient corrigés et protégés contre plus d'urgence que presque tout autre type d'exploit.

Voici un extrait du rapport sur les tendances et les risques semestriels d'IBM X-Force 2010:

(Veuillez ouvrir cette image dans un nouvel onglet pour l'afficher en taille réelle.)

Remarquez le pourcentage mesuré des vulnérabilités "Escape to hypervisor", ce qui me semble assez effrayant. Naturellement, vous voudriez lire le reste du rapport car il contient beaucoup plus de données pour sauvegarder les revendications.

Voici une histoire sur un éventuel exploit réalisé sur l'hyperviseur Playstation 3, ce qui est amusant. Peut-être pas aussi impactant pour votre entreprise, sauf si votre entreprise est Sony, auquel cas c'est extrêmement impactant.

Voici un merveilleux article d'Eric Horschman de VMware, dans lequel il me vient un peu comme un adolescent complètement anti-Micro $ oft, mais c'est toujours un bon article. Dans cet article, vous trouverez des friandises comme celle-ci:

Les résidents de la maison de verre de Microsoft avaient d'autres pierres à nous jeter. Microsoft a cité CVE-2009-1244 comme exemple de vulnérabilité de rupture d'invité dans ESX et ESXi. Un exploit d'évasion d'invité est une affaire sérieuse, mais, encore une fois, Microsoft déforme les faits. VMware a réagi rapidement pour corriger cette vulnérabilité dans nos produits, et ESX a été beaucoup moins affecté que Microsoft ne le laisse croire:

Chicanant entre concurrents. Mais probablement la chose la plus lucide qu'il dit dans tout l'article est la suivante:

La vérité est que les vulnérabilités et les exploits ne disparaîtront jamais complètement pour aucun logiciel d'entreprise.

Le toujours cité Theo de Raddt du projet OpenBSD:

Vous êtes absolument trompé, sinon stupide, si vous pensez qu'une collection mondiale d'ingénieurs logiciels qui ne peuvent pas écrire de systèmes d'exploitation ou d'applications sans failles de sécurité, peuvent alors se retourner et écrire soudainement des couches de virtualisation sans failles de sécurité.

Un peu incendiaire mais son argument est bien pris. En théorie, la virtualisation est censée fournir une isolation complète entre les machines virtuelles et leur hôte. Dans la pratique, il existe des vulnérabilités de sécurité occasionnelles qui permettent aux attaquants avancés de contourner ces protections et d'accéder à d'autres machines virtuelles ou pire encore à leur hôte (voir Une étude empirique sur l'exposition de la sécurité aux hôtes des environnements virtualisés hostiles ). Comme Ryan Ries le mentionne, ces types de vulnérabilités sont assez rares (ce qui ne signifie pas qu'elles ne sont pas là) et souvent non divulguées par les fournisseurs, mais elles existent.

Si vous êtes préoccupé par le potentiel de ces types d'attaques (et je pense que vous devriez l'être dans une certaine mesure), je vous recommande de ne pas mélanger les zones de sécurité sur un seul hôte virtuel ou cluster d'hôte virtuel. Par exemple - vous auriez un cluster d'hôte virtuel dédié à deux hôtes pour les machines virtuelles DMZ, un cluster dédié pour le middleware et un cluster dédié pour les actifs protégés. De cette façon, dans le cas où une vulnérabilité est exploitée de manière à permettre à un attaquant de subvertir d'autres machines virtuelles ou pire, l'hyperviseur lui-même, votre modèle de sécurité est toujours intact.