Übersicht
Am 13. Mai 2015 gab der Sicherheitsforscher Jason Geffner von CrowdStrike öffentlich eine Sicherheitslücke in einigen Virtualisierungsplattformen bekannt, die dies ermöglichen könnte einem Angreifer, aus der Sandbox einer virtuellen Maschine (VM) zu springen und sich Zugriff auf den geschützten Virtualisierungshost zu verschaffen. Die Schwachstelle wurde „VENOM“ getauft, für Virtualized Environment Neglected Operations Manipulation (CVE-2015-345) und betrifft jeden ungepatchten Virtualisierungshost, der auf dem Open-Source-QEMU-Emulator basiert, einschließlich Xen, KVM und VirtualBox von Oracle. Technologien, die kein QEMU verwenden, wie z. B. VMWare, Microsofts Hyper-V und Bochs, sind nicht betroffen.
Virtualisierungs-Primer
Virtualisierung ist im weitesten Sinne eine Technologieimplementierung, die es einem großen Computer ermöglicht, seine Ressourcen (z. B. Prozessor, Arbeitsspeicher, Festplattenspeicher) zu unterteilen, um viele kleinere virtuelle Computer auszuführen. Jede dieser VMs wird so ausgeführt, als wäre sie ein separates System, isoliert von den anderen VMs, die auf demselben Host ausgeführt werden. Diese Architektur ermöglicht es Serverbetreibern, Server einfacher zu verwalten und bereitzustellen, da sie eine neue VM in viel kürzerer Zeit erstellen können, als dies für den Aufbau einer physischen Version erforderlich wäre. Außerdem können Betreiber von Rechenzentren und Hosting-Anbieter ihre Ressourcen effizienter nutzen. Ein Virtualisierungshost, auf dem beispielsweise 10 VMs ausgeführt werden, benötigt einen Bruchteil des Speicherplatzes, der Energie und der Kühlung, die 10 gleichwertige physische Maschinen benötigen.
Was kann ein Exploit gegen VENOM bewirken?
Einer der weiteren Vorteile einer Virtualisierungsplattform ist die Möglichkeit, VMs zu trennen. Obwohl sie dieselbe gemeinsam genutzte Hardware verwenden, sind die VMs also isoliert. Eine solche Isolierung ermöglicht es einem Serveradministrator, unterschiedliche VMs mit unterschiedlichen Betriebssystemen für unterschiedliche Kunden bereitzustellen. Diese Kunden würden nie erfahren, dass sie Ressourcen auf einem Virtualisierungshost mit anderen Kunden teilen. Und selbst wenn sie Root- oder Administratorrechte auf ihren VMs hätten, hindert sie die Eindämmung daran, irgendetwas zu tun, das sich auf andere VMs auswirken würde.
Dieses isolierte Infrastrukturkonzept macht die Idee einer Schwachstelle wie VENOM so besorgniserregend. Wie Geffner auf der CrowdStrike-Website beschreibt:
Diese Schwachstelle kann es einem Angreifer ermöglichen, aus den Grenzen eines betroffenen Gastes einer virtuellen Maschine (VM) zu entkommen und möglicherweise Zugriff auf den Host zur Codeausführung zu erhalten. Ohne Gegenmaßnahmen könnte dieses VM-Escape den Zugriff auf das Hostsystem und alle anderen VMs öffnen, die auf diesem Host ausgeführt werden, und Angreifern potenziell erheblich erhöhten Zugriff auf das lokale Netzwerk des Hosts und benachbarte Systeme gewähren.
Für einen Anbieter, der sich auf die Sicherheit der VM-Isolierung verlassen hat, kann eine solche Schwachstelle ziemlichen Alarm auslösen.
Wie viel Alarm?
Während die Ankündigung dieser Schwachstelle in einigen Medien mit Heartbleed verglichen wurde, ist es wichtig, das Bekannte gegen das Mögliche und Wahrscheinliche abzuwägen.
Laut Geffner besteht die „VENOM-Schwachstelle seit 2004“, obwohl noch kein bekannter Exploit (zum jetzigen Zeitpunkt) in freier Wildbahn dokumentiert wurde. Geffner teilte seine Ergebnisse am 20. April 2015 mit den großen Virtualisierungsanbietern, die QEMU verwenden. Sobald ein Patch entwickelt war, veröffentlichte er seine Ergebnisse am 13. Mai 2015 auf der CrowdStrike-Website.
Bisher wurde jedoch kein öffentlicher Proof of Concept demonstriert. Wir wissen derzeit nicht, wie einfach oder schwierig es ist, Code zu erstellen, der VENOM ausnutzen kann. Da VENOM ein System für Angriffe über den alten Freund des Hackers, den Pufferüberlauf, offen lässt, könnte es im einfachsten Fall ausgenutzt werden, um den Host-Computer zum Absturz zu bringen, was zu einem Denial-of-Service führt. Mit mehr Sorgfalt und Klugheit könnte ein Angreifer möglicherweise Zugriff auf den Virtualisierungshost selbst erlangen und die anderen VMs kompromittieren, die auf demselben Host ausgeführt werden.
Was können wir tun, um uns zu schützen?
Da VENOM verantwortungsvoll offengelegt wurde und den Anbietern Zeit gab, einen Patch zu erstellen, ist es Aufgabe der Administratoren von Virtualisierungshosts, den Patch so schnell wie möglich anzuwenden. Einzelpersonen, deren Dienste auf VMs ausgeführt werden, die auf einer gemeinsam genutzten Virtualisierungsplattform ausgeführt werden, können alleine wenig tun. Sie können jedoch die Website ihres Anbieters besuchen, um zu sehen, ob sie anfällig sind und welche Schritte unternommen werden, um die Schwachstelle zu beheben. Bei Bedarf können sie Druck ausüben, um ihre Administratoren dazu zu drängen, ihre Systeme zu patchen, bevor diese potenzielle Bedrohung zu einem funktionalen Exploit wird, das von der dunkleren Seite des Internets weit verbreitet ist.
Um mehr darüber zu erfahren, was Atlantic.Net zur Behebung der VENOM-Schwachstelle unternimmt, finden Sie in unserem Blog die neuesten Informationen. Wir sind ständig bestrebt, die sichersten Virtual Private Server anzubieten, die unter anderem die besten Ein-Klick-Installationsanwendungen wie cPanel-Hosting bieten.
Aktualisiert am 15. Mai 2015, um den Atlantic.Net-Blog-Link aufzunehmen