Binary Planting: Windows-Sicherheitslücke betrifft dutzende Anwendungen

Die Art und Weise, wie Anwendungen DLL-Dateien behandeln, hat weitreichende Folgen für die Sicherheit von Windows . Zahlreiche Anwendungen können zum Einschleusen und Ausführen von Schadcode missbraucht werden, wenn die Entwickler beim Nachladen von DLLs nicht aufgepasst haben. Viel Schutz gibt es nicht, zudem ist der veröffentlichte Workaround kompliziert in der Handhabung.

24. August 2010 um 11:21 Uhr / Andreas Sebayang

Mehrere Anwendungen sind von einer kritischen Sicherheitslücke bei der DLL-Behandlung betroffen, die es erlaubt, Schadcode auszuführen. Microsoft bestätigt Berichte von Sicherheitsforschern, laut denen Anwendungen, die DLL-Dateien in unsicherer Art und Weise nachladen, anfällig sind.

Gegenüber The Register hat ein Sicherheitsexperte die Vermutung geäußert , dass etwa 200 Anwendungen von der Sicherheitslücke betroffen sind.

Das Risiko der Sicherheitslücke ist von den Einstellungen des Anwenders abhängig. Möglicher Schadcode wird im Kontext des Nutzers ausgeführt. Wer also seine Rechte einschränkt oder wessen Rechte durch andere eingeschränkt wurden, kann nicht besonders tief mit Schadcode in ein System eindringen. Für eine Verbreitung des Schadcodes dürfte dies in vielen Fällen trotzdem ausreichen.

Problematisch sind Anwendungen, die höhere Rechte erfordern, und davon gibt es auch heute noch einige. Wer sogar grundsätzlich mit Administratorrechten arbeitet, macht es dem Angreifer besonders einfach.

Für einen erfolgreichen Angriff muss der Nutzer dazu gebracht werden, ein SMB-Netzlaufwerk oder auch ein WebDAV-Laufwerk zu nutzen, auf dem der Schadcode abgelegt wurde. Angriffe sollen sich aber nicht nur auf diese beiden Protokolltypen beschränken. Für einen erfolgreichen Angriff genügt es, eine ungefährliche Datei – beispielsweise eine MP3-Datei oder ein Office-Dokument – zu öffnen. Neben dieser Datei liegt im selben Verzeichnis eine unauffällige Bibliothek, die anfällige Anwendungen Schadcode ausführen lässt. Diese DLL-Datei wird gegebenenfalls automatisch geladen, wenn die Anwendung nicht nach der DLL mit einer Pfadangabe sucht (fully qualified path). In dem Fall sucht die Anwendung nach der DLL in Verzeichnissen des sogenannten DLL Search Path, der das derzeitige Arbeitsverzeichnis mit einschließt.

Das Design des Betriebssystems erlaubt es Microsoft nicht, das Problem selbst zu beheben. Es ist vorgesehen, dass Anwendungen bei Bedarf DLLs im Arbeitsverzeichnis direkt nachladen können. Entwickler müssen aber sicherstellen, dass DLL-Dateien und deren Pfade korrekt behandelt werden. Würde Microsoft dieses Verhalten wegpatchen, hätte das zur Folge, dass zahlreiche Anwendungen nicht mehr funktionieren würden.

Viele Updates zu erwarten

Einen Ausweg gibt es nur durch die Entwickler betroffener Anwendungen. Sie müssen überprüfen, ob ihre Anwendungen den Development Best Practices folgen . Aufgrund der Masse der betroffenen Anwendungen müssen sich Nutzer wohl auf viele Updates in den kommenden Wochen einrichten. Der Anwender selbst hat wenig Chancen, anfällige Programme selbst aufzuspüren.

Microsoft will jetzt die eigenen Anwendungen auf die Schwachstelle hin überprüfen. Außerdem existiert ein Mitigation Tool , das die Problematik zumindest abschwächen soll. Das Tool erstellt in der Registrierung einen Eintrag mit dem Namen CWDIllegalInDllSearch. Dieser Registrierungseintrag erlaubt es, gezielt den DLL Search Path für Anwendungen einzuschränken. Auch global können Einschränkungen gesetzt werden. Sie erfordern vom Anwender allerdings Erfahrung im Umgang mit dem Registrierungseditor.

Von der Anleitung des Mitigation Tools gibt es auch eine deutsche Übersetzung , der derzeit jedoch die Downloadlinks fehlen. Das Mitigation Tool gibt es für Windows XP SP3, Vista, 7 sowie die Servervarianten 2003, 2008 und 2008 R2.

Microsoft beschreibt das Problem im Detail im Blog Security Research & Defense und im Security Advisory 2269637 .