Une machine virtuelle empêche-t-elle les logiciels malveillants de nuire?
Je voudrais savoir s'il est sûr pour le système hôte d'une machine virtuelle (VM - VirtualBox OSE dans mon cas) d'exécuter un malware.
Un virus peut-il éclater et lire ou écrire des données à partir du système hôte? Peut-il établir une connexion Internet si je le désactive sur ma machine virtuelle?
Un VM est-il un environnement sûr pour essayer de découvrir ce que fait un virus?
Une fourchette peut-elle "tuer" le système hôte si je réduit la mémoire à environ 1/4 de ma mémoire réelle totale? Combien de temps CPU/ressources peut-il utiliser?
Théoriquement, le système invité est totalement isolé par le VM et ne peut même pas "voir" l'hôte, encore moins l'attaquer; afin que l'invité ne puisse pas sortir de la machine virtuelle. Bien sûr, dans la pratique, cela s'est parfois produit ( lien d'archive Web ). Une attaque nécessite d'exploiter un problème de sécurité (c'est-à-dire un bug de programmation qui s'avère avoir des conséquences désagréables) dans l'implémentation VM ou, éventuellement, les fonctionnalités matérielles sur lesquelles s'appuie VM. Il existe peu de routes de sortie pour les données hors de la machine virtuelle; Par exemple, pour l'accès à Internet, le VM émule une carte réseau virtuelle, qui ne traite que les paquets de niveau le plus bas, pas TCP/IP complet - ainsi, la plupart des problèmes de pile IP restent confinés dans le VM lui-même. Par conséquent, les bogues entraînant la sortie de VM ont tendance à rester rares.
Il existe certains types d'attaques contre lesquelles VM sont très efficaces, par exemple bombes à fourche. Du point de vue du système hôte, le VM est un processus unique. Une bombe fourchue dans l'invité mettra à genoux le planificateur dans le invité OS, mais pour l'hôte, cela sera totalement inoffensif. De même pour la mémoire: le VM émule une machine physique avec une quantité donnée de RAM, et aura besoin d'environ cette quantité de "vrai" RAM pour la sauvegarder efficacement. Indépendamment de ce que fait l'invité, le VM ne monopolisera jamais plus RAM que cela. (Vous voulez toujours limiter la taille de VM RAM à, disons, au plus la moitié de votre taille physique de RAM, parce que le "réel" supplémentaire RAM est pratique pour la mise en cache du disque; et le système d'exploitation hôte voudra également en utiliser.)
Disclaimer: je vais pour une compréhension de haut niveau. Si vous voulez un guide détaillé, c'est hors de portée. De plus, il existe d'autres façons (entièrement logicielles) d'implémenter des machines virtuelles auxquelles cela ne s'applique pas. Je me concentre également sur la "percée" par les mécanismes de virtualisation uniquement - c'est-à-dire pas ceux qui peuvent se produire de PC à PC sur de véritables hôtes en réseau dur.
J'aime les détails, alors on y va avec certains. Tout d'abord, codeproject a d'excellentes références d'assembleur sur le différents modes d'un CPU x86 (réel, protégé et long) et l'utilisation de virtualisation . Il y a un blog Intel VT (je ne sais pas si Intel écrit ceci) et enfin la première partie du Rootkit Arsenal est dédiée à l'explication de x86 et est une excellente lecture, complet avec soluces et diagrammes de Nice. Comprendre tout cela demande de la patience, donc ce que je vais faire ici est de donner une très brève introduction à son fonctionnement.
La façon dont nous avons basculé lorsque nous avons exécuté DOS
Les systèmes DOS et les premiers modes en mode réel 16 bits utilisent un modèle de mémoire segmentée. Il n'y a aucun contrôle sur la taille des segments et il n'y a aucun interrupteur de protection sur aucun de ces segments. Le code est chargé dans un segment de mémoire et il s'exécute; il peut de loin sauter dans d'autres segments, de sorte que n'importe quel code, n'importe où peut modifier n'importe quoi, y compris la production d'un morceau de code TSR (terminer et rester résident) qui pointe simplement l'une des entrées IVT (table de vecteur d'interruption) vers une adresse dans son espace, avant d'exécuter l'original. Fondamentalement, il n'y a aucune protection. Aucun. Nada.
L'essor du mode protégé 32 bits
Le mode protégé se complique rapidement. Il comprend trois parties: la segmentation, la radiomessagerie et le PAE. Chacun requiert une table de données qui informe le processeur de ce segment, de cette page ou l'aide à étendre l'espace d'adressage (PAE). Il s'agit notamment des fameux drapeaux en anneau (ils s'appliquent aux segments et aux pages) qui implémentent l'isolation des processus. La pagination est votre moyen de charger des données hors de RAM et sur le disque et de créer des choses fantaisistes comme la mémoire virtuelle (voir, le mot virtuel! Nous y arrivons!)
Mode long
Le mode long supprime la segmentation et rend simplement obligatoires les structures PAE/Paging. Encore une fois, pour banaliser totalement la mise en œuvre d'un système d'exploitation, la pagination est contrôlée par des structures en mémoire qui sont ensuite configurées via des instructions spéciales. Voila, on peut réaliser l'isolation du processus avec les bons paramètres. Encore une fois, je banalise légèrement ...
Donnez-moi la virtualisation!
D'accord. La virtualisation est le même concept général. Les machines virtuelles sont configurées à l'aide de structures de contrôle de machine virtuelle qui dictent la façon dont leur mémoire est mappée sur la mémoire physique, un peu comme la pagination. Surtout, dans certaines conditions, la machine virtuelle devra demander quelque chose au système d'exploitation hôte, un peu comme l'isolement du processus, un peu comme une interruption logicielle. Ceux-ci sont appelés VM quitte et fournit à l'hôte des informations telles que l'état des registres à la sortie. Un peu comme un appel système.
Un logiciel malveillant peut-il sortir d'une machine virtuelle?
Donc, en ce qui concerne le VM, l'OS hôte a tout son propre espace mémoire et peut être infecté/endommagé/détruit à sa guise).
En termes d'affectation directe de la mémoire de l'hôte, la machine virtuelle ne peut pas, car elle ne peut pas la voir. L'hôte doit mapper la mémoire requise dans l'espace de la machine virtuelle. Il doit également, dans cet espace mémoire, implémenter tout depuis le BIOS. Afin de communiquer avec certains périphériques hôtes pour certaines tâches, la machine hôte doit configurer ces conditions de sortie VM et la cible VM doit les déclencher. Quand cela arrive, le contrôle est transféré à l'hôte.
Il existe donc deux zones à risque possibles:
- Les actions que l'hôte entreprend en réponse à une sortie VM. S'il y a des bogues dans cette gestion, il peut être possible de persuader l'hôte d'exécuter quelque chose qu'il ne devrait pas faire.
- Tout accès hôte à l'espace mémoire de la machine invitée. N'oubliez pas que le code de la machine hôte s'exécutant dans l'anneau 0 peut valser et planter la fête où bon lui semble. Il se trouve que vous pouvez définir la mémoire de l'invité à partir de l'invité (de manière surprenante).
Cela vous amène à votre mécanisme d'exploitation. Vous avez besoin d'un bogue de gestion dans la routine de sortie VM, alors vous devez être en mesure de persuader ce code d'exécuter de la mémoire, idéalement du code que vous venez de mettre dans une page à partir du vm invité. Une fois terminé , dis au revoir au Kansas.
Comme le dit Tom Leek, les VM sont incroyablement efficaces pour se défendre contre les bombes à fourche. Dans la même veine que la façon dont le système d'exploitation peut limiter la quantité de mémoire qu'un processus peut allouer, il peut donc limiter la quantité de mémoire mappée sur la machine virtuelle. Manquez et le système d'exploitation invité pense qu'il n'y a plus de mémoire physique; l'hôte ne l'allouera pas plus sauf vous implémentez une sortie VM pour ce faire, ce qui serait un peu dangereux et je ne pense pas que cela soit fait.
Quelle est la probabilité?
Pas très. Cela dépend de ces VM sorties implémentations entièrement, ou de la lecture de la mémoire de l'invité sur l'hôte avec un joli bogue dans votre code de lecture. Cela nécessite également que ce bogue vous permette de contrôler le plantage dans de telle manière que vous pouvez forcer l'exécution à l'adresse mémoire que votre hôte détient. La sortie VM doit pouvoir accéder à cette mémoire.
Ce que je n'ai pas couvert?
- Attaques sur des piles logicielles existantes telles que TCPIP. Les vulnérabilités ici sont les mêmes que si vous aviez quand même deux PC physiques réels.
- Virtualisation entièrement implémentée par logiciel.
- Virtualisation sur tout autre type de puce. Cela s'applique aux configurations compatibles Intel VT.
Enfin, j'ai déjà soutenu que l'isolement des processus est une forme de sandboxing. En lisant cette réponse et celle-ci, vous devriez maintenant être en mesure de comprendre pourquoi je les définis ainsi. Il existe des similitudes remarquables entre l'isolation des processus et les machines virtuelles dans x86.
Mise à jour
Donc, j'ai creusé encore plus à ce sujet, en particulier dans la recherche sur la pilule bleue. Ce que j'ai décrit est une vue de haut niveau très simpliste. J'ai trouvé plus de détails. Voici un tout le papier qui lui est dédié de Invisible Things Lab. Il s'avère que leur défenses conversation incluait le concept de refuser l'accès en exécution aux pages en mode utilisateur de l'anneau 0, empêchant ainsi l'exécution directe des données que la machine virtuelle a placées en mémoire. Il s'avère que cela est implémenté dans les processeurs Intel et des correctifs existent actuellement dans le noyau Linux. Ainsi, selon la façon dont cela se passe, il se pourrait bien que les attaques de cette nature deviennent beaucoup plus difficiles, même s'il existe des exploits.
J'ai fait un peu d'expérimentation de logiciels malveillants dans un VM - principalement en utilisant backtrack4 pour passer d'un hôte à l'autre. Je suis principalement un utilisateur de VMware Workstation.
Le plus gros problème vient de la possibilité de la connexion réseau de votre VM transfert vers votre OS hôte. Vous souhaitez désactiver totalement la mise en réseau et/ou utiliser un réseau qui n'a pas accès à votre hôte .
Limiter la mémoire est une bonne pratique exemplaire. Je le garde généralement à environ un quart, comme vous. Le temps CPU est limité au nombre de cœurs ou (si vous avez des contrôles plus fins dans votre logiciel) au pourcentage de temps CPU défini pour votre VM spécifique.
Des attaques ciblées capables de sortir de l'environnement virtuel existent et sont disponibles dans le commerce - comme le mentionne cloudburst @Hendrick - mais sont relativement rares. Se tenir à jour sur vos correctifs de virtualisation est une très bonne idée.
En plus de toutes les bonnes informations ici pour savoir si le virus peut s'échapper de la machine virtuelle, permettez-moi de signaler un autre problème à considérer:
Il est possible que du code malveillant détecte s'il est exécuté à l'intérieur d'une machine virtuelle ou non . Cela s'appelle souvent détection de machine virtuelle ou "pilules rouges" , et il existe beaucouptechniques disponibles.
De plus, certains virus et autres logiciels malveillants utilisent ces techniques pour détecter s'ils sont exécutés sur une machine virtuelle et, dans l'affirmative, arrêter leur charge utile (éviter toute action malveillante). Ils le font pour essayer de rendre la vie plus difficile aux gens pour désosser le logiciel malveillant ou le détecter.
Par conséquent, un VM n'est pas un bon moyen de savoir ce que fait un logiciel malveillant. Le logiciel malveillant peut ne pas être en mesure de sortir de la machine virtuelle, mais en même temps, il peut ne pas faire quoi que ce soit lorsqu'il s'exécute à l'intérieur de la machine virtuelle. Si vous l'exécutez dans le VM et voyez qu'il ne fait rien, décidez qu'il est inoffensif, puis décidez de l'exécuter en dehors du VM - vous pourriez devenir propriétaire. Soyez prudent.