Binary Planting Test und Gegenmaßnahmen

Seit Tagen wird in einschlägigen Medien über eine Sicherheitslücke unter Microsoft Windows berichtet. Anwendungen können DLLs nicht nur aus ihrem Installationsverzeichnis und den Systemverzeichnissen laden, sondern auch aus dem aktuellen Arbeitsverzeichnis. Dieses Verzeichnis wird bspw. beim Öffnen einer Daten in der Anwendung festgelegt. Somit kann ein Angreifer eine DLL mit Schadcode in einem beliebigen Verzeichnis mit Dateien ablegen und darauf hoffen, dass eine Anwendung durch Zufall genau diese DLL sucht und aus dem Verzeichnis lädt. Das Ganze ist noch etwas komplexer und im Security Advisory 2269637 von Microsoft beschrieben.

Testanwendung

Zum gefahrlosen Testen des eigenen Systems habe ich eine kleine Anwendung und eine DLL erstellt. Die Anwendung versucht die DLL zu laden. Die DLL macht nichts weiter als eine Meldung anzuzeigen, wenn sie geladen wurde. Sie enthält keinerlei Funktionalität und auch keinen Schadcode.

Folgendermaßen können Sie den Test durchführen:

1. Laden Sie die Testanwendung nebst DLL herunter.
2. Entpacken Sie das Archiv und verschieben Sie die DLL DllSearchDll.dll in ein Verzeichnis auf einem Netzlaufwerk.
3. Öffnen Sie die Eingabeaufforderung und wechseln Sie zum Netzlaufwerk-Verzeichnis mit der DLL.
4. Starten Sie in der Eingabeaufforderung die Anwendung DllSearch.exe, indem Sie den vollständigen Dateipfad der Anwendung angeben.

Wenn nun die Meldung Die potenziell gefährliche DLL wurde geladen. erscheint, hat die Anwendung die DLL aus dem Arbeitsverzeichnis geladen. Ihr System weist also die diskutierte Schwachstelle auf.

Meldet die Anwendung hingegen in der Eingabeaufforderung DllSearchDll.dll wurde nicht gefunden., scheint das Laden der DLL aus dem Arbeitsverzeichnis nicht möglich.

Wenn Sie sich vergewissern wollen, dass die Testanwendung und die DLL keinen Schadcode enthalten können Sie den Quellcode herunterladen und die Anwendung mit dem Visual Studio oder einem anderen Entwicklungswerkzeug selbst erstellen.

Hinweis zum DLL-Namen: Falls der Name DllSearchDll.dll auf Ihrem System tatsächlich von einer "echten" DLL verwendet wird, können Sie die Test-DLL auch umbenennen. Sie müssen den DLL-Namen dann beim Start der Testanwendung als Parameter angeben.

Gegenmaßnahmen

Die einzige wirksame Gegenmaßnahme ist momentan die Installation eines von Microsoft bereitgestellten Windows-Updates, welches die Möglichkeit des Nachladens von DLLs aus dem Arbeitsverzeichnis unterbindet. Das Update und dessen Konfiguration ist im Artikel Ein neuer Registrierungseintrag "CWDIllegalInDllSearch" zum Steuern des DLL-Suchpfadalgorithmus ist verfügbar zu finden. Ich habe gleich die radikale Variante gewählt und den Registrierungseintrag CWDIllegalInDllSearch im Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ auf 0xFFFFFFFF gesetzt, was das Laden von DLLs aus dem Arbeitsverzeichnis komplett unterbindet. Bisher ist mir noch nicht aufgefallen, dass ein Programm damit Probleme hat. Meine Testanwendung kann die DLL aber nicht mehr laden, was auch Ziel der Übung war.

Update: Negative Auswirkungen der Gegenmaßnahme auf Outlook 2003

Leider haben sich durch das rigorose Unterbinden des Ladens von DLLs aus dem Arbeitsverzeichnis negative Auswirkungen in Microsoft Outlook 2003 gezeigt:

• Das Adressbuch wird nicht mehr angezeigt. Es erscheint die Fehlermeldung "Die Messaging-Programmschnittstelle hat einen unbekannten Fehler zurückgeliefert. Falls das Problem weiterbesteht, starten Sie Outlook neu.".
• Beim Rechtsklick auf ein enzelnes Element, z. B. eine E-Mail, wird das Kontextmenü nicht mehr angezeigt.
• Terminserien lassen sich im Kalender in der Tages-, Wochen- oder Monatsansicht nicht mehr öffnen, da der Dialog zur Auswahl "Serie oder Serienelement öffnen" nicht angezeigt werden kann.
• Benutzerdefinierte Formulare lassen sich nicht mehr öffnen oder bearbeiten.
• Beim Einrichten eines neuen Outlook-Profils erscheint die Fehlermeldung "OUTEX.DLL am angegebenen Dateipfad nicht gefunden" und Outlook stürzt ab.

Der zuletzt genannte Fehler gab mir den Hinweis, dass etwas mit dem DLL-Suchpfad nicht stimmt, denn die OUTEX.DLL ist vorhanden. Ich habe daraufhin, wie im Technet-Artikel An update on the DLL-preloading remote attack vector empfohlen, im Registrierungsschlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ den neuen Schlüssel OUTLOOK.EXE angelegt sowie darin den Registrierungseintrag CWDIllegalInDllSearch angelegt und auf 0x00000002 gesetzt. Damit arbeitet Outlook wieder einwandfrei. Die Einstellung verhindert noch immer das Laden von DLLs aus Netzlaufwerken oder WebDAV-Verzeichnissen, wenn das Programm, welches die DLL sucht,nicht selbst auf einem Netzlaufwerk oder WebDAV-Verzeichnis liegt. Sinnvolle Tipps gibt auch der Artikel Binary Planting: Microsoft veröffentlicht neues Hilfe-Werkzeug auf golem.de.

Zum besseren Verständnis gibt es noch zwei Screenshots der Registrierungseinträge in Regedit. Nummer eins zeigt den globalen Registrierungseintrag CWDIllegalInDllSearch, Nummer zwei den Registrierungseintrag CWDIllegalInDllSearch für Outlook.

Kommentare nehme ich gern per E-Mail entgegen.

Navigation: Zurück zu Tipps & Tricks

©2010 Michael Berthold, letzte Änderung am 10.09.2010