Les VM peuvent certainement se croiser. Habituellement, vous les avez mis en réseau, de sorte que tout logiciel malveillant avec un composant réseau (c'est-à-dire des vers) se propage là où son adressage / routage le permet. Les virus ordinaires ont tendance à ne fonctionner qu'en mode utilisateur, donc même s'ils ne peuvent pas communiquer ouvertement, ils peuvent toujours mettre en place un canal secret. Si vous partagez des processeurs, un processus occupé sur une machine virtuelle peut communiquer efficacement l'état à une autre machine virtuelle (c'est votre canal caché de synchronisation prototypique). Le canal secret de stockage serait un peu plus difficile car les disques virtuels ont tendance à avoir une limite stricte, donc à moins que vous n'ayez un système qui peut surcharger l'espace disque, cela ne devrait pas être un problème.

Le L'approche la plus intéressante pour sécuriser les VM est appelée le noyau de séparation. C'est le résultat de l ' article de 1981 de John Rushby qui déclare essentiellement que pour avoir des VM isolées d'une manière qui pourrait être équivalente à une séparation physique, l'ordinateur doit exporter ses ressources vers des VM spécifiques d'une manière où à aucune ressource qui peut stocker l'état n'est partagée entre les VM. Cela a des conséquences profondes, car cela nécessite que l'architecture informatique sous-jacente soit conçue de manière à ce que cela puisse être réalisé de manière non contournable.

30 ans après cet article, nous avons finalement peu de produits qui prétendre le faire. x86 n'est pas la meilleure plate-forme pour cela, car il existe de nombreuses instructions qui ne peuvent pas être virtualisées, pour prendre pleinement en charge l'idée du «pas de partage». Ce n'est pas non plus très pratique pour les systèmes courants, car pour avoir quatre VM, il faudrait quatre disques durs suspendus à quatre contrôleurs de disque, quatre cartes vidéo, quatre contrôleurs USB avec quatre souris, etc.

Mise à jour 2020: toutes les vulnérabilités matérielles récentes (Meltdown, Spectre, Foreshadow, ZombieLoad, CacheOut, SPOILER, etc.) de la famille de vulnérabilités sont de bons exemples de la façon dont les VM pourront toujours communiquer, simplement parce qu'elles partagent du matériel (caches, TLB, prédiction de branche, TSX, SGX) qui n'ont jamais été prévus ou préparés pour être partitionnés et isolés.

Des livres blancs ont été publiés au fil des ans décrivant les moyens par lesquels les chercheurs ont réussi à infester un système d'exploitation hôte à partir d'une VM. Celles-ci sont généralement considérées, à juste titre, comme des failles de sécurité par les fournisseurs de VM et traitées comme telles. Depuis que j'ai vu ces articles pour la première fois, Intel a apporté des améliorations significatives au jeu d'instructions du processeur en permettant la séparation de la VM et de l'hyperviseur.

Les quelques vulnérabilités que je vois ces jours-ci sont davantage basées sur la partie «vmtools». C'est le logiciel que vous installez pour rendre le système d'exploitation invité plus efficace (pour VMWare, c'est ce qui permet la capture du curseur à la volée et le partage entre l'invité et l'hôte sans réseau). Il s'agit d'une voie logicielle spéciale pour l'infection; n'installez pas les outils, ne possédez pas la vulnérabilité.

Certains logiciels malveillants ont montré la capacité de détecter qu'ils sont exécutés à l'intérieur d'une VM et donc de modifier leur comportement , en grande partie à l'aggravation des chercheurs de logiciels malveillants qui tentent d'utiliser des machines virtuelles pour tester des logiciels malveillants. Cependant, je ne sais pas à quel point c'est répandu de nos jours.

Un exemple d'exécution de code d'invité à hôte peut être trouvé dans l'exploit Cloudburst. Il existe une vidéo la démontrant et un article d'Immunity détaillant leur succès sur VMware Workstation 6.5.0 build118166 sur Windows Vista SP1, VMware Workstation 6.5.1 build126130 sur Windows Vista SP1 et (encore plus effrayant) VMware ESX Server 4.0.0 build133495.

Cela n'apporte probablement que peu de réconfort, mais je n'ai jamais entendu parler de cette utilisation dans la nature et l'exploit date de 2009. Ce livre a été publié en 2010, donc l'auteur devrait nettoyer cette déclaration.

Une machine virtuelle est exactement cela, une machine logiquement séparée, donc elle doit avoir les mêmes couches de sécurité placées dessus que vous le feriez pour un système nu. L'utilisation d'une machine virtuelle n'arrêtera pas une vul si elle utilise des canaux normaux pour accéder à la machine hôte.

La vraie beauté de la virtualisation est la possibilité de ramener les VM à un état où elles n'ont pas été affectées, comme ainsi que la possibilité de mieux gérer les ressources disponibles.

Si les mesures appropriées sont prises pour protéger la machine hôte, la virtualisation peut être extrêmement sécurisée. Des pratiques telles que le maintien de la gestion du serveur ESX / VM sur un réseau logique différent et le fait de ne pas utiliser d'outils d'interfaçage VM-hôte garderont les attaquants inconscients du fait qu'une machine est virtuelle, sans parler de la façon d'accéder à l'hôte.

De plus, il existe des exploits connus qui affectent les hôtes VM (j'ai joué avec eux dans VMWare et Hyper-V). Je ne suis actuellement au courant des exploits de l'hôte DoS qu'en ce qui concerne l'hyper-v (voir ceci), mais je suis sûr qu'il y a d'autres découvertes à l'horizon. VMWare en a aussi dans son histoire (c'est-à-dire ceci, il est basé sur des outils VMWare, mais cela s'applique toujours).

En fonction de ce que vous faites, il existe des outils en ligne qui peut être en mesure de supprimer votre besoin de faire l'analyse sur votre propre machine. Voici quelques sites à consulter:
- Threatexpert.com
- anubis.iseclab.org
- virustotal. com

Ce que signifie le matériel Security +, c'est que jusqu'à présent, les logiciels malveillants n'ont pas pu s'échapper du bac à sable de la VM en exploitant le fait qu'il s'agit d'une VM et en frappant d'une manière ou d'une autre l'hyperviseur. D'autres mécanismes, tels que la diffusion sur un réseau partagé, sont les mêmes que s'il s'agissait de boîtes physiques différentes.

Ils ne sont pas parfaitement sécurisés, comme le démontre cet exploit:

VENOM, CVE-2015-3456, est une vulnérabilité de sécurité qui affecte certaines plates-formes de virtualisation informatique courantes, notamment Xen, KVM, VirtualBox, et le client QEMU natif.

Cette vulnérabilité peut permettre à un attaquant de s'échapper des limites d'un invité de machine virtuelle (VM) affecté et d'obtenir potentiellement un accès d'exécution de code à l'hôte. Vous trouverez plus de détails sur la vulnérabilité ici.

Je pense que l'affirmation de l'auteur n'est pas complètement vraie. En fait, il existe deux types d ' hyperviseur dans la zone de virtualisation. Hypervisor est un logiciel, un micrologiciel ou un matériel informatique qui crée et exécute des machines virtuelles . Ces types sont:

• Hyperviseurs de type 1
• Hyperviseurs de type 2

L'hyperviseur de type 1 s'exécute directement sur le matériel de l'hôte pour contrôler le matériel et gérer les systèmes d'exploitation invités. Pour cette raison, ils sont parfois appelés hyperviseurs bare metal alors que l'hyperviseur de type 2 fonctionne sur un système d'exploitation conventionnel tout comme le font d'autres programmes informatiques. VMWare ou VirtualBox sont des exemples d'hyperviseur de type 2 car ils sont exécutés en tant que programmes dans les OS hôtes.

Pour les hyperviseurs de type 2, il existe un projet RoboLinux qui possède une fonctionnalité unique appelée Stealth VM . Programme d'installation du logiciel Stealth VM qui vous permet de créer un clone Windows 7 s'exécutant sur une partition Linux sécurisée . Le système est protégé contre les logiciels malveillants, tout ce que vous téléchargez sera contenu dans la machine virtuelle et il est destiné aux personnes qui doivent avoir un programme Windows spécifique avec la commodité de pouvoir restaurer le système d'exploitation comme nouveau en seulement deux clics.

Il existe Qubes OS qui est développé sous Linux et Xen comme un exemple pour les hyperviseurs de type 1. Qubes OS adopte une approche appelée sécurité par isolation , ce qui, dans ce contexte, signifie garder les choses que vous faites sur votre ordinateur isolées de manière sécurisée dans différentes VM afin qu’une VM compromise gagne » t affecter les autres. Contrairement aux hyperviseurs de type 2, il dispose d'un système de transfert de fichiers entre VM sécurisé pour gérer le risque de partage des dossiers. En théorie, cette organisation est plus sécurisée que la virtualisation de type 2 selon les développeurs.

En bref, l'auteur doit indiquer quel hyperviseur ou système virtuel.

• https://en.wikipedia.org/wiki/Hypervisor
• https://www.qubes-os.org/
• http://www.robolinux.org
• http://www.xenproject.org/
• http://www.hacker10.com/computer-security/vpn-ready-linux-distribution -robolinux /

D'intérêt et de pertinence, le concours de sécurité "Pwn2Own" pour 2016 a comme l'une de ses compétitions, échapper à une machine virtuelle VMWare Workstation. (D'autres incluent l'échappement des sandbox de navigateur ou la reprise de machines physiques). Cela devrait donner une idée que 1) c'est au moins plausible et 2) si c'est facile, nous avons un moyen de l'entendre - il suffit de vérifier le résultat :)

Plus généralement, la sécurité des VM pourrait en théorie être échappée dans plusieurs façons. Par exemple -

• Invité pour héberger des commandes et des API (par exemple des outils VMware)

• Faiblesses exploitables dans le système d'exploitation hôte lui-même qui sont non atténué par l'exécution dans un processus de machine virtuelle (si certains appels du système d'exploitation invité sont jugés à tort "sûrs" et transmis directement par un pilote invité au système d'exploitation hôte ou au pilote de périphérique pour la vitesse, mais qu'un exploit existe)

• Bogues dans les pilotes du fournisseur ou le code du fournisseur (par exemple, un pilote d'hôte permet le pontage réseau pour le système d'exploitation invité; peut-être qu'un bogue pourrait permettre d'effectuer des appels ou du code sur l'hôte au niveau du noyau). / p>

• Vulnérabilités résultant d'autres logiciels sur l'hôte (exemple artificiel - si l'antivirus local intercepte tout le trafic réseau de l'hôte à analyser, et le trafic invité est analysé dans le cadre de cela (par opposition être ignoré en raison d'un périphérique NIC virtuel), alors une vulnérabilité du moteur A / V à un trafic ou un paquet malveillant pourrait être capable de permettre au trafic provenant de la VM de s'échapper vers l'hôte)

• Mauvaise configuration par utilisateur (fichiers hôtes mappés ou insuffisamment sécurisés / séparés pour que l'invité puisse les atteindre)

La portée existe, et étant donné la prévalence, elle est sûrement en cours d'examen activement pour les exploits. Des vulnérabilités, sinon des exploits, seront régulièrement découvertes et nécessiteront des correctifs.

Les exploits spécialement conçus pour s'exécuter dans vms et cibler les bogues dans le noyau hôte sous-jacent sont inévitables. Recherchez-les d'abord sur les plates-formes cloud populaires.