VMs können definitiv überkreuzen. Normalerweise haben Sie sie vernetzt, sodass sich Malware mit einer Netzwerkkomponente (d. H. Würmer) überall dort ausbreitet, wo ihre Adressierung / Weiterleitung dies zulässt. Normale Viren arbeiten normalerweise nur im Benutzermodus. Obwohl sie nicht offen kommunizieren konnten, konnten sie dennoch einen verdeckten Kanal einrichten. Wenn Sie CPUs gemeinsam nutzen, kann ein ausgelasteter Prozess auf einer VM den Status effektiv an eine andere VM kommunizieren (dies ist Ihr prototypischer verdeckter Timing-Kanal). Der verdeckte Speicherkanal wäre etwas schwieriger, da die virtuellen Festplatten in der Regel stark eingeschränkt sind. Wenn Sie also kein System haben, das übermäßig viel Speicherplatz beanspruchen kann, sollte dies kein Problem darstellen.

Die Der interessanteste Ansatz zum Sichern von VMs ist der Separation Kernel. Es ist ein Ergebnis von John Rushbys 1981er Papier, in dem es im Wesentlichen heißt, dass der Computer seine Ressourcen auf eine Weise exportieren muss, die der physischen Trennung entspricht, damit VMs auf eine Weise isoliert werden können, die einer physischen Trennung entspricht Es macht keinen Sinn, dass eine Ressource, die den Status speichern kann, von VMs gemeinsam genutzt wird. Dies hat tiefgreifende Konsequenzen, da die zugrunde liegende Computerarchitektur so gestaltet werden muss, dass dies auf nicht umgehbare Weise möglich ist.

30 Jahre nach diesem Dokument haben wir endlich nur wenige Produkte, die dies tun behaupten, es zu tun. x86 ist nicht die beste Plattform dafür, da es viele Anweisungen gibt, die nicht virtualisiert werden können, um die Idee des "No Sharing" vollständig zu unterstützen. Für gängige Systeme ist dies auch nicht sehr praktisch, da für vier VMs vier Festplatten erforderlich sind, die an vier Festplattencontrollern, vier Grafikkarten, vier USB-Controllern mit vier Mäusen usw. hängen.

Update 2020: Alle aktuellen hardwarebasierten Schwachstellen (Meltdown, Spectre, Foreshadow, ZombieLoad, CacheOut, SPOILER usw.) sind ein gutes Beispiel dafür, wie VMs immer kommunizieren können, einfach weil sie Hardware gemeinsam nutzen (Caches, TLB, Verzweigungsvorhersage, TSX, SGX), die niemals für die Partitionierung und Isolierung vorgesehen oder vorbereitet waren.

Im Laufe der Jahre wurden einige Whitepaper veröffentlicht, in denen beschrieben wurde, wie es Forschern gelungen ist, ein Host-Betriebssystem von einer VM aus zu befallen. Diese werden normalerweise zu Recht von den VM-Anbietern als Sicherheitslücken angesehen und als solche behandelt. Seit ich diese Artikel zum ersten Mal gesehen habe, hat Intel einige wesentliche Verbesserungen an den Prozessoranweisungen vorgenommen, um die Trennung von VM und Hypervisor zu ermöglichen.

Die wenigen Sicherheitslücken, die ich heutzutage sehe, basieren mehr auf dem Abschnitt 'vmtools'. Dies ist die Software, die Sie installieren, damit das Gastbetriebssystem effizienter ausgeführt wird (für VMWare ermöglicht dies die sofortige Erfassung des Cursors und die gemeinsame Nutzung zwischen Gast und Host ohne Netzwerk). Dies ist ein spezieller Softwarepfad für Infektionen. Installieren Sie die Tools nicht und weisen Sie keine Sicherheitsanfälligkeit auf.

Einige Malware-Programme können erkennen , dass sie in einer VM ausgeführt werden, und ändern daher ihr Verhalten , sehr zur Erschwerung von Malware-Forschern, die versuchen, VMs zum Testen von Malware zu verwenden. Ich weiß allerdings nicht, wie weit verbreitet es heutzutage ist.

Ein Beispiel für die Ausführung von Gast-zu-Host-Code finden Sie im Cloudburst-Exploit. Es gibt ein Video , das es demonstriert, und ein Dokument von Immunity , in dem der Erfolg von VMware Workstation 6.5.0 build118166 unter Windows Vista SP1 und VMware Workstation 6.5.1 build126130 unter Windows beschrieben wird Vista SP1 und (noch beängstigender) VMware ESX Server 4.0.0 build133495.

Dies bietet wahrscheinlich wenig Komfort, aber ich habe noch nie davon gehört, dass dies in freier Wildbahn verwendet wird, und der Exploit stammt aus dem Jahr 2009. Dieses Buch wurde 2010 veröffentlicht, daher sollte der Autor diese Aussage bereinigen.

Eine virtuelle Maschine ist genau das, eine logisch getrennte Maschine, daher müssen dieselben Sicherheitsebenen darauf platziert sein wie bei einem Bare-Metal-System. Die Verwendung einer virtuellen Maschine stoppt einen Vul nicht, wenn normale Kanäle verwendet werden, um zur Host-Maschine zu gelangen.

Die wahre Schönheit der Virtualisierung besteht in der Möglichkeit, VMs in einen Zustand zurückzusetzen, in dem sie nicht betroffen waren sowie die Möglichkeit, verfügbare Ressourcen besser zu verwalten.

Wenn die richtigen Schritte zum Schutz des Host-Computers unternommen werden, kann die Virtualisierung äußerst sicher sein. Praktiken wie das Beibehalten der ESX / VM-Serververwaltung in einem anderen logischen Netzwerk und das Nichtverwenden von VM-Host-Schnittstellentools lassen Angreifer die Tatsache, dass eine Maschine virtuell ist, weitgehend außer Acht, geschweige denn, wie sie zum Host gelangen.

Es sind auch Exploits bekannt, die sich auf VM-Hosts auswirken (ich habe mit ihnen in VMWare und Hyper-V gespielt). Derzeit sind mir nur Host-DoS-Exploits bekannt, wenn es um Hyper-V geht (siehe dies), aber ich bin mir sicher, dass weitere Funde am Horizont stehen. VMWare hat auch einige in seiner Geschichte (dh dies, es basiert auf VMWare-Tools, aber es gilt immer noch).

Je nachdem, was Sie tun, gibt es einige Online-Tools, die Möglicherweise können Sie die Analyse nicht mehr auf Ihrem eigenen Computer durchführen. Hier sind einige Websites, die Sie sich ansehen sollten:
- Threatexpert.com
- anubis.iseclab.org
- virustotal. com

Mit dem Security + -Material ist gemeint, dass Malware bisher nicht in der Lage war, der Sandbox der VM zu entkommen, indem sie die Tatsache ausnutzte, dass es sich um eine VM handelt und irgendwie auf den Hypervisor traf. Andere Mechanismen, z. B. die Verteilung über ein gemeinsam genutztes Netzwerk, sind dieselben, als wären dies unterschiedliche physische Boxen.

Sie sind nicht perfekt sicher, wie dieser Exploit zeigt:

VENOM, CVE-2015-3456, ist eine Sicherheitslücke, die sich auf einige gängige Computervirtualisierungsplattformen auswirkt, insbesondere Xen, KVM, VirtualBox, und der native QEMU-Client.

Diese Sicherheitsanfälligkeit kann es einem Angreifer ermöglichen, aus den Grenzen eines betroffenen VM-Gasts (Virtual Machine) zu entkommen und möglicherweise Code-Ausführungszugriff auf den Host zu erhalten. Weitere Details zur Sicherheitsanfälligkeit finden Sie hier.

Ich denke, dass die Behauptung des Autors nicht vollständig wahr ist. Tatsächlich gibt es im Virtualisierungsbereich zwei Arten von Hypervisor . Hypervisor ist eine Computersoftware, Firmware oder Hardware, die erstellt und virtuelle Maschinen ausführt. Diese Typen sind:

• Typ-1-Hypervisoren

Typ-1-Hypervisor wird direkt auf der Hardware des Hosts ausgeführt, um die Hardware zu steuern und Gastbetriebssysteme zu verwalten. Aus diesem Grund werden sie manchmal als Bare-Metal-Hypervisoren bezeichnet, während Typ-2-Hypervisor auf einem herkömmlichen Betriebssystem ausgeführt wird genau wie andere Computerprogramme. VMWare oder VirtualBox sind Beispiele für Typ-2-Hypervisor, da sie als Programme in Host-Betriebssystemen ausgeführt werden.

Für Typ-2-Hypervisoren gibt es ein RoboLinux Projekt mit einer einzigartigen Funktion namens Stealth VM . Stealth VM-Software-Installationsprogramm , mit dem Sie einen Windows 7-Klon erstellen können, der in einer sicheren Linux-Partition ausgeführt wird. Das System ist vor Malware geschützt. Alles, was Sie herunterladen, befindet sich in der virtuellen Maschine und ist für Personen gedacht, die über ein bestimmtes Windows-Programm verfügen müssen, um das Betriebssystem als wiederherstellen zu können Neu in nur zwei Klicks.

Es gibt Qubes OS , das unter Linux und Xen as entwickelt wurde Ein Beispiel für Typ-1-Hypervisoren. Qubes OS verfolgt einen Ansatz namens Sicherheit durch Isolation . In diesem Zusammenhang bedeutet dies, dass die auf Ihrem Computer ausgeführten Aktionen in verschiedenen VMs sicher isoliert bleiben, sodass eine kompromittierte VM gewinnt. t beeinflussen die anderen. Im Gegensatz zu Typ-2-Hypervisoren verfügt es über ein sicheres Dateiübertragungssystem zwischen VMs , um das Risiko der Freigabe von Ordnern zu bewältigen. Theoretisch ist diese Organisation laut Entwicklern sicherer als die Typ-2-Virtualisierung.

Kurz gesagt, der Autor sollte angeben, welcher Hypervisor oder welches virtuelle System.

Referenzen :

• 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 /

Von Interesse und Relevanz ist der Sicherheitswettbewerb "Pwn2Own" für 2016 einer seiner Wettbewerbe, der einer virtuellen VMWare Workstation-Maschine entkommt. (Andere beinhalten das Entkommen von Browser-Sandboxen oder die Übernahme physischer Maschinen). Das sollte eine Vorstellung davon geben, dass 1) es zumindest plausibel ist und 2) wenn es einfach ist, wir eine Möglichkeit haben, es zu hören - überprüfen Sie einfach das Ergebnis :)

Im Allgemeinen könnte die VM-Sicherheit theoretisch entgangen werden viele Möglichkeiten. Beispiel:

Der Gültigkeitsbereich ist vorhanden und wird aufgrund seiner Verbreitung sicherlich geprüft aktiv für Exploits. Sicherlich werden Schwachstellen, wenn nicht Exploits, regelmäßig gefunden und müssen gepatcht werden.

Exploits, die speziell für die Ausführung in VMs und Zielfehlern im zugrunde liegenden Host-Kernel entwickelt wurden, sind unvermeidlich. Suchen Sie zuerst in den beliebten Cloud-Plattformen nach ihnen.