Eine kritische Sicherheitslücke mit dem Namen Venom gefährdet Virtualisierungssoftware namhafter Anbieter, die in Rechenzentren genutzt wird. Entdeckt hat sie der Sicherheitsforscher und Crowdstrike-Mitarbeiter Jason Geffner. Ihm zufolge können Angreifer die Schwachstelle nutzen, um eine virtuelle Maschine zu verlassen und Zugang zum Host-System zu erhalten. Anschließend sei er in der Lage auf andere virtuelle Maschinen zuzugreifen und vertrauliche Daten zu stehlen.
Offenbar befindet sich der Fehler bereits seit elf Jahren im virtuellen Floppy Disk Controller (FDC). Der Open-Source-Emulator (QEMU) nutzt den FDC. Betroffen seien unter anderem die Virtualisierungsplattformen Xen, KVM, Virtualbox und natürlich der native QEMU-Client, so Geffner weiter. Nicht anfällig sind VMware, Microsofts Hyper-V und der Bochs-Hypervisor. Venom stelle eine Gefahr für tausende Unternehmen und Millionen von Endnutzern dar.
Eigentlich kommen Floppy-Laufwerke bereits seit vielen Jahren nicht mehr zum Einsatz, dennoch sind viele virtuelle Maschinen ab Werk noch mit dem virtuellen Floppy Disk Controller ausgestattet. Über einen Input/Output-Port kommuniziert das Gastbetriebssystem mit dem FDC. Dieser prüft zugleich, wie viele Daten er erhalten soll. Nach dem Erhalt der erwarteten Daten, führt er den Befehl aus und leert den Puffer für die nächste Übertragung.
Angreifer können Venom nutzen, um die Befehle mit einem bestimmten Parameter zu senden. Dieser löst anschließend einen Pufferüberlauf aus. Auf diese Weise lässt sich dann Schadcode einschleusen und ausführen.
Venom sei nicht die erste Sicherheitslücke, mit der Angreifer eine virtuelle Maschine verlassen können, so Crowdstrike weiter. Allerdings stelle sie das erste Mal eine Möglichkeit dar, dass virtuelle Maschinen in der Ausgangskonfiguration angreifbar seien. Bislang seien nur nicht voreingestellte Konfigurationen oder gar als unsicher geltende Einstellungen anfällig gewesen. Darüber hinaus sind von Venom mehrere Virtualisierungsplattformen betroffen.
Darüber hinaus glaubt Geffner, dass Venom sogar gefährlicher als die Heartbleed-Lücke in der Verschlüsselungssoftware OppenSSL sei. “Heartbleed lässt einen Bösewicht durch das Fenster eines Hauses schauen und die Informationen sammeln, die er sieht”, sagte Geffner in einem Telefoninterview mit ZDNet USA. “Venom erlaubt es einer Person, nicht nur in ein Haus einzubrechen, sondern auch in jedes andere Haus in der Nachbarschaft.”
Symantec schließt sich dieser Einschätzung jedoch nicht an. “Heartbleed betraf sehr viele Websites, Anwendungen, Server, VPNs und Netzwerk-Applikationen. Venom betrifft nur Virtualisierungssysteme die speziell QEMUs Floppy Disk Controller verwenden und hat keine Auswirkungen auf einige der am weitesten verbreiteten VM-Plattformen.”
Ein Angriff auf Betreiber anfälliger System, die darauf “kritische Dienste mit vielen vertraulichen Daten ausführen”, sei nach Ansicht von Symantec aber möglicherweise verheerend. Cyberkriminelle hätten mit Venom mehr Möglichkeiten als mit Heartbleed. Allerdings sei die Zahl der betroffenen System geringer. Aus diesem Grund ist der Bug Symantec zufolge im Ganzen betrachtet weniger gefährlich.
Ähnlich sieht es die auf Netzwerksicherheit spezialisierte Firma Tenable. “Diese Schwachstelle kann eine Gefahr darstellen, solange sie nicht gepatcht wurde. Allerdings müssen Angreifer dazu Admin- oder Root-Rechte im Root-OS besitzen, und bisher ist noch kein derartiger Fall bekannt. Es gab zwar schon einiges Getöse um CVE 2015-3456, allerdings liegen noch keine Belege dafür vor, dass die Auswirkungen tatsächlich so groß sind, wie der Hype vermuten lässt.”
Crowdstrike hat die Lücke nach eigenen Angaben Ende April vertraulich an die betroffenen Hersteller gemeldet. Laut Karl Sigler, Thread Intelligence Manager bei Trustwave, sind bisher keine Angriffe auf die Schwachstelle bekannt. Zudem haben viele Anbieter inzwischen Patches für ihre Produkte bereitgestellt. Xen hat die Lücke beispielsweise in der Version 4.2x oder höher seines Hypervisors geschlossen. Oracle will sie in Kürze mit dem Wartungsupdate Virtualbox 4.3 beseitigen.
[mit Material von Stefan Beiersmann, ZDNet.de]
LLMs besitzen einerseits innovative neue Fähigkeiten, stellen Unternehmen allerdings auch vor diverse Herausforderungen: ob EU…
Server-Ausbau in den USA und China macht große Fortschritte, deutscher Weltmarktanteil sinkt. Lichtblicke in Frankfurt…
Der Markt für Workplace Services gerät in Bewegung. Das bestmögliche digitale Nutzererlebnis gilt als Schlüssel…
Schutz für 10.000 Postfächer über rund 200 Domains: Private-Stack-Variante kombiniert Vorteile einer Cloud-Lösung mit Sicherheit…
Huawei Connect Paris: Innovationen rund um Data Center, Storage und IT-Sicherheit.
Mit KI optimieren Hacker ihre Angriffsversuche. Ist CIAM eine Lösung, mit der sich Unternehmen vor…
View Comments
"Allerdings müssen Angreifer dazu Admin- oder Root-Rechte im Root-OS besitzen"
Das ist eine ziemlich zentrale Information, die da im zweitletzten Absatz versteckt wird! Sie lässt die Einschätzung der Situation von "beängstigend" auf "tja, selber Schuld wer davon betroffen ist" kippen.
Deutsch gesagt heisst das, dass ein Angreifer bereits vollen Zugriff auf das System, auf welchem die VM ausgeführt wird, haben muss. Schafft er dies durch einen Angriff, ist das Aushebeln der VM-Sandbox wohl eher ein vernachlässigbares Detail, angesichts des anderen Schadens den er anrichten kann. Hat er ohnehin bereits auf das System Zugriff, trifft die betreffende Organisation grössere Schuld als den Bug.
Die Aussage, das "XEN" betroffen sei, ist nur insofern korrekt, wie XEN im (weniger performanten/effizienten) Vollvirtualisierungsmodus betrieben wird, der von QEMU "abhängig" ist - im (gerade bei vielen professionelleren Hostern) eingesetzte Paravirtualisierungsmodus ist damit afaik nicht betroffen.
Und zu meinem Vorkommentator (Daniel): Der Schritt vom Root eienr VM in eine HV Umgebung ist alles andere als ein" vernachlässigbares Detail", da viele Anbieter virtueller Hosts (oder neudeutsch zuweilen auch "Cloud Anbieter") selbstverständlich VMs anbieten, auf die der User/Kunde volle Root-Rechte hat. derlei Plattformen sind darauf angwiesen, das eine rechte-/ressourcentechnische Kapselung binnen VMs auch funktioniert.
Und ach diese Anbieter müssen damit rechnen, das Unbefugte Dritte Root Zugriff auf VMs erhalten, zB weil die jeweiligen Sysadmins der VMs "geschludert" haben.
Natürlich gibt es auch Setups, in denen bereits ein Root-Zugriff Dritter unerwünscht wie gefährlich wäre (zB primär private Clouds bzw. Setups, wo Virtualisierung "intern" zur Ressourcenverwaltung im Einsatz ist) - pauschalisiert jedoch funktioniert das so nicht.