Vmware meldet kritische Sicherheitslücke

"Backdoor" ermöglicht Zugriff auf Systemdateien

Vmware warnt in einem Sicherheitsbulletin vor einer gefährlichen Lücke seiner Workstation-Produktlinie unter Windows. Mittels Shared Folders lassen sich zwischen Windows als Hostbetriebssystem und den Gastmaschinen Dateien austauschen. Allerdings können die Gastmaschinen damit auch lesend und schreibend auf die Windows-Systemdateien zugreifen und damit unbemerkt Schadsoftware einschleusen.

Wie ZDNet erfahren konnte, hat der Virtualisierungsmarktführer ein sogenanntes „Backdoor-I/O-Port-Interface“ implementiert, das die Sicherheitslücke verursacht. Teile dieses Interfaces sind an die Öffentlichkeit gelangt. Solche Hintertüren, mit denen manche Hersteller ihre Produkte versehen, gelten allgemein als verpönt.

Da momentan noch kein Patch zur Verfügung steht, rät Vmware, Shared Folders zu deaktivieren. Die Anwender sollten bis dahin den Austausch von Dateien mit anderen Mitteln, etwa Standard-Windows-File-Sharing, durchführen. Einen Termin, wann ein Patch zur Verfügung stehen wird, wollte der Hersteller nicht angeben.

Laut Vmware sind folgende Produktversionen betroffen: Vmware Workstation bis 6.0.2, Vmware Workstation bis 5.5.4, Vmware Player bis 2.0.2, Vmware Player bis 1.0.4, Vmware ACE bis 2.0.2 und Vmware ACE bis 1.0.2. Ausdrücklich weist Vmware darauf hin, dass alle auf ESX-Server basierenden Produkte, beispielsweise Vmware Infrastructure, sowie alle Produkte für Linux und Mac OS die Schwachstelle nicht aufweisen.

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

ZDNet für mobile Geräte
ZDNet-App für Android herunterladen Lesen Sie ZDNet-Artikel in Google Currents ZDNet-App für iOS

Artikel empfehlen:

Neueste Kommentare 

1 Kommentar zu Vmware meldet kritische Sicherheitslücke

Kommentar hinzufügen
  • Am 26. Februar 2008 um 9:39 von Nenad Cimerman

    Workaround mit subst?
    So wie ich die Exploit-Analysen verstehe, stützt sich der Exploit auf ".." als Referenz zu dem übergeordneten Verzeichnis im Dateisystem. Außerdem tritt das Problem nur unter Windows auf… insofern müsste es doch möglich sein, das Problem zu umgehen, indem man das Host-Verzeichnis, welches für das shared-folder Feature genutzt wird, per SUBST-Kommando einem eigenen "Windows Laufwerk" zuweist und dieses in der Liste der shared-folders verwendet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *