News VENOM: Sicherheitslücke lässt aus VM-Gastsystemen ausbrechen

Mittels „Virtualized Environment Neglected Operations Manipulation“, kurz VENOM, können Angreifer durch eine fehlerhafte Diskettenlaufwerksimplementierung aus bestimmten virtuellen Maschinen ausbrechen und so Zugriff auf das Host-System sowie auf andere darauf laufende VMs erhalten.

Zur News: VENOM: Sicherheitslücke lässt aus VM-Gastsystemen ausbrechen

Das ist schon seit ein paar Jahren schwer nachzuvollziehen, dass in der Default-Konfiguration bei der Erstellung einer VM innerhalb der gängigen Hypervisors noch ein Floppy-Controller hängt.

Ja, ab und an wird es für ein paar Spezialfälle nochmal benötigt, aber dann bitte optional und manuell hinzufügen. Aus dem Standard gehört es m.E. raus.

Naja, dass Virtualisierung nicht wirklich eine höhere Sicherheit bringt sollte ja bekannt sein.
Aber dann halt mal alle Virtualisierungsserver updaten...

HVM ist für mich auch ein Spezialfall. Bei uns läuft eigentlich alles paravirtualisiert. Übrig bleiben die Windows büchsen Ich hab mal n GRML als HVM gebootet, aber kein FDD gesehen. Auch der QEMU-Prozess hatte kein fdd-Parameter ... eventuell ist das in der XenServer-Konfiguration nicht aktiv. Wobei ich mich erinnere auch mal ein FDD Laufwerk in ner Windows-VM gesehen zu haben

MusicJunkie666 schrieb:

Naja, dass Virtualisierung nicht wirklich eine höhere Sicherheit bringt sollte ja bekannt sein.

Zum Vergrößern anklicken....

Seit wann?
Was bringt denn nach deiner Definition überhaupt eine höhere Sicherheit?

Und das man über Root/Admin Rechte in der VM verfügen muss, das lässt ihr mal gekonnt weg.
Geffner kann sich zwar auch ein Angriff über Malware vorstellen, aber auch das ist nur eine Vorstellung.

​

Ich meine damit das "Security by Virtualization" Konzept, das manche verfolgen. Also bspw. verschiedene Dienste in verschiedenen VMs laufen lassen, damit nicht einer den anderen Beeinflussen kann. Aber letztendlich läuft alles auf der gleichen Hardware...

@-=Azrael=-: Sicherheitslücken, die Root-Rechte verschaffen soll es ja auch geben. Inzwischen eher selten, aber weiterhin ein Thema.

Gut das du mich drauf aufmerksam gemacht hast, das habe ich jetzt wirklich nicht bedacht.....

Und was hat Hardware mit einem Pufferüberlauf im FDD Controller des Hypervisors zu tun....

MusicJunkie666:

Es läuft auf der selben Hardware ja, aber:

Das Prinzip "Security by Virtualization" basiert nicht nur auf der Idee, dass einzelne Dienste in separate VMs gepackt werden, sondern das grundsätzlich das Betriebssystem keine uneingeschränkten Zugriffsrechte auf die Hardware hat.

In der Kurzfassung: Es gibt ein so genanntes Ring-System:

Ring 0 - Kernel Mode
Ring 1- User Mode
Ring 2 - User Mode
Ring 3 - User Mode

Bei einem normalen unvirtualisierten System laufen nur der Betriebssystem-Kernel und die Systemtreiber in der höchsten Stufe (Ring 0) und haben damit direkten Hardwarezugriff. Die restlichen Level müssen über Abstraktionsschichten auf die Hardware zugreifen und können dementsprechend gesteuert werden.

Bei einem Hypervisor + VMs sieht das ganze dann etwas anders aus. Dort hat nämlich nur der Hypervisor den direkten Zugriff auf die Hardware. Die VMs bekommen lediglich eine Emulation bereitgestellt. Das Problem daran ist, dass normale unmodifizierte Betriebssysteme darauf ausgelegt sind, dass ihr Kern einen Ring-0-Zugriff erhält. Was hat man also gemacht: Durch die Virtualisierungsfunktionen in der CPU (VT bei Intel, AMD-V bei AMD) ist man hingegangen, und hat eine Art "Ring -1" geschaffen, der in echt aber ein Ring 0 ist. Den Gastbetriebssystem wird somit vorgegaukelt, einen direkten Hardwarezugriff zu haben, hat der aber nicht. Sämtliche priviligierten Zugriffe werden vom Virtual Machine Monitor abgefangen und entsprechend weiterverarbeitet (gefiltert, umgesetzt). Dazu kommt noch eine Speicher-Isolierung, die verhindert, dass VMs direkt in den Speicherbereich von anderen VMs zugreifen können.

Somit hat man durch die Virtualisierung von Systemen schon einen gewissen grad an zusätzlicher Sicherheit. Es wurden in der Vergangenheit zwar durchaus mal Rootkits und Breakouts aus der VM-Umgebung raus gefunden, das ist aber nix für Wochenend-Skriptkiddies.

-=Azrael=- schrieb:

Gut das du mich drauf aufmerksam gemacht hast, das habe ich jetzt wirklich nicht bedacht.....

Und was hat Hardware mit einem Pufferüberlauf im FDD Controller des Hypervisors zu tun....

Zum Vergrößern anklicken....

Warte auch noch auf die Antwort

Ich kann nur annehmen, daß der Dichter dicht ist oder einfach zu viele Themen ohne Zusammenhang miteinander "verwurstelt" hat.

"Heikel ist der Fehler zudem unter anderem auch, weil die emulierten Diskettenlaufwerke standardmäßig gesetzt werden und auch beim Entfernen der Code bestehen bleibt, was für eine große Verbreitung sorgt."

Versteh ich das richtig, dass grundsätzlich alle VMs angreifbar sind egal ob mit oder ohne Floppy und schon allein die Fähigkeit ein Laufwerk einzubinden reicht?