Categories: Cloud

Schwachstelle Venom gefährdet Rechenzentren

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-Logo (Bild: Crowdstrike)

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: “Im Ganzen betrachtet weniger gefährlich.”

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]

Andre Borbe

Andre ist Jahrgang 1983 und unterstützte von September 2013 bis September 2015 die Redaktion von silicon.de als Volontär. Erste Erfahrungen sammelte er als Werkstudent in den Redaktionen von GMX und web.de. Anschließend absolvierte er ein redaktionelles Praktikum bei Weka Media Publishing. Andre hat erfolgreich ein Studium in politischen Wissenschaften an der Hochschule für Politik in München abgeschlossen. Privat interessiert er sich für Sport, Filme und Computerspiele. Aber die größte Leidenschaft ist die Fotografie.

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.

Recent Posts

Licht an!

Lampenwelt steigert mit SoftwareOne und Microsoft Azure ihre Effizienz.

1 Tag ago

KI-Agenten übernehmen zunehmend den B2B-Kundendienst

Weltweit werden bis 2028 voraussichtlich mehr als zwei Drittel aller Kundendienst- und Supportinteraktionen mit Technologieanbietern…

2 Tagen ago

RWE digitalisiert HR-Prozesse mit App von Insiders Technologies

Energiekonzern setzt auf KI-basierte Lösung und macht damit die Kommunikation und Übermittlung von Unterlagen für…

3 Tagen ago

KI ist kein IT-Projekt, sondern ein Veränderungsprozess

Fallstricke, Voraussetzungen und warum es beim Thema KI nicht um Tools, sondern um Struktur und…

3 Tagen ago

Verwaltung kritischer Geschäftsdaten auf Oracle EU Sovereign Cloud

RDV, BGN und Vertama nutzen souveräne Cloud-Funktionen, um sensible Workloads vollständig innerhalb der EU auszuführen.

3 Tagen ago

Wenn Fortschritt zum Stolperstein wird

Nicht immer bringt Digitalisierung den erhofften Effizienzgewinn, da stattdessen die Komplexität wächst. Welche Folgen hat…

4 Tagen ago