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

Podcast: Zero Trust zum Schutz von IT- und OT-Infrastruktur

"Das Grundprinzip der Zero Trust Architektur hat sich bis heute nicht geändert, ist aber relevanter…

1 Tag ago

Malware April 2024: Aufstieg des Multi-Plattform-Trojaners „Androxgh0st“

Androxgh0st zielt auf Windows-, Mac- und Linux-Plattformen ab und breitet sich rasant aus. In Deutschland…

1 Tag ago

Selbstangriff ist die beste Verteidigung

Mit autonomen Pentests aus der Cloud lassen sich eigene Schwachstelle identifizieren.

2 Tagen ago

Prozessautomatisierung im Distributionslager

Die Drogeriekette Rossmann wird ihr neues Zentrallager in Ungarn mit Software von PSI steuern.

2 Tagen ago

Wie autonome Fahrzeuge durch Quantencomputing sicherer werden können

Automobilhersteller planen, Quantentechnologie zunehmend auch bei fortschrittlichen Fahrerassistenzsystemen (ADAS) einzusetzen.

3 Tagen ago

Heineken plant Bedarfe mit KI-Lösung von Blue Yonder

Blue Yonder soll mehr Nachhaltigkeit entlang der Lieferkette der internationale Brauerei ermöglichen.

3 Tagen ago