www.Au-Ja.de - http://www.au-ja.de/guide-windows-dll-preloading-workaround-print.phtml

Guide: Workaround für den DLL-Preloading-Bug in Windows - Druckansicht - Seite 1 von 5

UPDATES:




Bereits am Dienstag hatten wir gemeldet, dass Microsoft erste Schritte gegen den DLL-Preloading-Bug, welcher sämtliche Versionen von Windows betrifft, eingeleitet hat. Die aktuelle Lösung richtet sich allerdings in erster Linie an Administratoren und wurde leider alles andere als komfortabel umgesetzt. Aufgrund zahlreicher Nachfragen haben wir uns entschlossen, den Workaround Schritt für Schritt zu beschreiben.


Fotostrecke mit weiteren und größeren Fotos...

Wo liegt das Problem?
Unter Windows ist es möglich, Teile eines Programms in Bibliotheken, die sogenannten Dynamic Link Libraries (DLLs), auszulagern. Diese muss lediglich in den Speicher geladen werden, wenn die darin befindlichen Funktionen benötigt werden. Zudem können sich mehrere Programme die selben DLLs teilen und das spart Platz auf der Festplatte. Programmierer sollten den Pfad zu einer solchen DLL-Datei möglichst präzise definieren, doch oftmals wird hierauf verzichtet, da Windows selbstständig nach benötigten Bibliotheken sucht. Hierbei steuert das Betriebssystem über die Funktionen LoadLibrary und LoadLibraryEx, welche zum dynamischen Laden der Bibliotheken genutzt werden, die folgenden Ordner an:

  1. Das Verzeichnis, aus dem die Anwendung geladen wurde
  2. Das 32-Bit-Systemverzeichnis
  3. Das 16-Bit-Systemverzeichnis
  4. Das Windows-Verzeichnis
  5. Das aktuelle Arbeitsverzeichnis
  6. Die in der Umgebungsvariable PATH aufgeführten Verzeichnisse

Der Knackpunkt ist hierbei das aktuelle Arbeitsverzeichnis, denn dieses muss sich keinesfalls auf dem lokalen Computer befinden. Wurde beispielsweise eine Datei eines bekannten Typs aus dem Netz geöffnet, betrachtet Windows diese externe Quelle als aktuelles Arbeitsverzeichnis. Wenn der Programmierer des verwendeten Programms nun keine vollständigen Pfade für die benötigten DLLs definiert hat, sucht Windows auch in diesem Ordner nach diesen Bibliotheken. Angreifer können dem lokalen System auf diese Weise eigene DLLs unterschieben und deren Inhalt ist genauso gefährlich wie ein Programm. Selbst wenn die aus dem Netz geöffnete Datei vollkommen harmlos ist und den Virenschutz unbehelligt passieren kann, können Angreifer mit Hilfe der nachgeladenen Bibliotheken vollständigen Zugriff auf das lokale System erhalten.


Fotostrecke mit weiteren und größeren Fotos...

Dieses Problem wurde vor einiger Zeit von der slowenischen Sicherheitsfirma Acros in Apples iTunes 9.2 entdeckt und von Apple mit dem Update auf die Version 9.2.1 behoben. Im Anschluss stellten Acros und Rapid7 weitere Untersuchungen an und entdeckten dabei unzählige weitere Anwendungen, welche mit dem selben Problem zu kämpfen haben. Man könnte sagen, beim DLL-Preloading-Bug handelt es sich um einen gängigen Konstruktionsfehler in Windows-Programmen. Natürlich könnten (und sollten) alle Entwickler ihre Software auf dieses Problem hin untersuchen und die DLL-Pfade komplettieren, doch damit sich der Windows-Anwender wirklich sicher fühlen kann, muss Microsoft tätig werden. Und die Redmonder haben nun reagiert.

Die Lösung
Die meisten Anwender hätten sich wahrscheinlich einen simplen Patch gewünscht, welcher das Laden von DLLs aus unsicheren Quellen unterbindet. Dummerweise kann Windows nicht mit Sicherheit entscheiden, welche Quelle unsicher ist. Wenn Microsoft beispielsweise den DLL-Suchpfad auf das lokale System beschränkt, lassen sich in Unternehmensnetzen, bei denen die meisten Anwendungen aus dem Netz gestartet werden, zahlreiche Programme nicht mehr ausführen. Darum hat sich Microsoft entschlossen, diese Entscheidung an die Administratoren bzw. den Benutzer abzutreten. Mit Hilfe eines neuen Wertes in der Registrierung kann der Administrator definieren, welche Quellen er zulassen möchte. Es besteht sogar die Möglichkeit, die Einschränkungen für bestimmte Anwendungen zu definieren. Im Grunde ist diese Lösung angemessen, aber ihre Umsetzung erfordert mehr Wissen über Windows, als es viele Benutzer haben.

Zunächst den Patch einspielen
Während der von Microsoft ersonnene Workaround alles andere als komfortabel ist, bietet er zumindest kaum Möglichkeiten, etwas kaputt zu machen. Damit Windows auf den neuen Registrierungswert reagieren kann, muss es erst einmal über dessen Existenz und Bedeutung informiert werden. Hierfür hat Microsoft ein Update veröffentlicht:

Dieses Update erfordert einen Gültigkeitsprüfung der Windows-Lizenz. Nachdem diese bestanden wurde, installiert man den Patch und startet das System im Anschluss neu. Die Installation legt den neuen Registrierungswert nicht an, dies muss der Administrator in Handarbeit erledigen.




Guide: Workaround für den DLL-Preloading-Bug in Windows - Druckansicht - Seite 2 von 5

Und dann den DLL-Suchpfad einschränken
In den meisten Fällen empfiehlt es sich, den DLL-Suchpfad für alle Anwendungen zu beschränken, schließlich weiß der Anwender im Normalfall nicht, welche Programme betroffen sind. Hierzu öffnen wir zunächst den Registrierungseditor, indem wir auf "Start" klicken, "Ausführen" auswählen und dort "regedit" eintippen.


Fotostrecke mit weiteren und größeren Fotos...

Nachdem wir unsere Auswahl mit "OK" bestätigt haben, startet der Registrierungseditor. In diesem öffnen wir folgenden Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Der neue Wert hat den Namen "CWDIllegalInDllSearch" und muss im Unterschlüssel "Session Manager" angelegt werden. Ist "Session Manager" geöffnet, klicken wir mit der rechten Maustaste in einen leeren Bereich der rechten Fensterhälfte. Es öffnet sich ein Menü, in dem wir "Neu" und dann "DWORD-Wert" auswählen.


Fotostrecke mit weiteren und größeren Fotos...

Den neuen Wert taufen wir auf den Namen "CWDIllegalInDllSearch", er erhält zunächst den Wert "0".


Fotostrecke mit weiteren und größeren Fotos...

Solange "CWDIllegalInDllSearch" der Wert "0" zugeordnet ist, verhält sich Windows wie bisher. Es stehen jedoch auch drei andere Werte zur Auswahl:


Fotostrecke mit weiteren und größeren Fotos...

Wer auf Nummer sicher gehen will, entscheidet sich für "FFFFFFFF". Sollte die eine oder andere Anwendung Probleme machen, kann man den Wert ja immer noch in "1" oder "2" abändern.




Guide: Workaround für den DLL-Preloading-Bug in Windows - Druckansicht - Seite 3 von 5

Finetuning für Experten
Falls bekannt sein sollte, welche Programme unvollständige Pfadangaben für benötigte DLLs enthalten, kann man diese auch gezielt blockieren. Weiterhin kann man auf diese Weise auch Ausnahmen von der systemweit gesetzten Sperre definieren, um Anwendungen, die mit dem beschränkten Suchpfad Probleme haben, auszuklammern. Hierzu wird für jede Anwendung ein neuer Registrierungsschlüssel sowie der passende Wert hinterlegt. Der neue Schlüssel trägt schlicht und einfach den Dateinamen der betroffenen Anwendung und wird in folgendem Unterschlüssel angelegt:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options


Fotostrecke mit weiteren und größeren Fotos...

Nun öffnet man den frisch erstellten Programmschlüssel und hinterlegt den DWORD-Wert "CWDIllegalInDllSearch" wie zuvor beschrieben. Abermals stehen die Werte "FFFFFFFF", "1" und "2" zur Auswahl und haben die selbe Bedeutung wie bei der allgemeinen Beschränkung, wirken sich diesmal aber nur auf die durch den Schlüsselnamen definierte Anwendung aus.


Fotostrecke mit weiteren und größeren Fotos...

Bekannte Probleme mit bestimmten Anwendungen
Einige Programme haben Probleme nach dem Ausschluss des aktuellen Arbeitsverzeichnisses aus dem DLL-Suchpfad. Hier eine Übersicht der uns bekannten Anwendungen sowie die dazugehörigen Lösungsvorschläge:

Abschließende Worte
Seit langer Zeit weist Microsoft alle Programmierer darauf hin, dass man bei der Verwendung von Dynamic Link Libraries vollständige Quellpfade verwenden sollte. Der schwarze Peter wird somit den Programmierern zugeschoben und das durchaus zu Recht. Dennoch muss die Frage erlaubt sein, warum ein Betriebssystem fehlende Bibliotheken überhaupt in Arbeitsverzeichnissen sucht. Dass das jeweilige Programmverzeichnis sowie die Ordner des Betriebssystems berücksichtigt werden, können wir nachvollziehen, doch nur weil ein Ordner eine zu öffnende Datei enthält, muss er noch lange nicht so sicher sein, dass man aus diesem auch Programme ausführen würde. In Zeiten, wo sich ein Arbeitsverzeichnis quasi überall befinden kann, steckt in Microsofts Ansatz ein konzeptioneller Fehler, der die Schlampigkeit vieler Entwickler erst zum Sicherheitsrisiko werden lässt. Weitere Informationen zu diesem Problem finden sich im Knowledge-Base-Artikel KB2264107 von Microsoft.




Guide: Workaround für den DLL-Preloading-Bug in Windows - Druckansicht - Seite 4 von 5

Microsofts Fix-it-Tool
Microsoft hat ein Fix-it-Tool veröffentlicht, welches den systemweiten Registry-Wert "CWDIllegalInDllSearch" auf "2" setzt. Dies bedeutet, dass DLLs nicht aus Arbeitsverzeichnissen geladen werden, bei denen es sich um Remote-Ordner oder WebDAV-Freigaben handelt, es sei denn das Programm wurde aus dem jeweiligen Arbeitsverzeichnis aufgerufen. Vor dem Aufruf des Fix-it-Tools muss man zunächst den Patch installieren, welcher das Betriebssystem über die neuen Regeln in Kenntnis setzt. Weitere Informationen hierzu finden sich bei Microsoft.

Betroffene Programme
Betrachtet man die Liste der betroffenen Programme, fällt sofort auf, dass sich darunter viele Titel von Microsoft selbst finden und einige davon sogar zum Lieferumfang von Windows gehören. Wenn Microsoft nun wieder und wieder betont, dass es sich nicht um einen Fehler in Windows, sondern vielmehr um die schlampige Programmierung von Dritten handelt, können wir dies nicht mehr so akzeptieren. Schließlich liefert Microsoft selbst etliche Beispiele dieses schlechten Programmierstils ab und versieht Windows auf diese Weise mit etlichen Hintertüren.

Folgende Programme wurden untersucht und als potentiell angreifbar bestätigt:

Folgende Anwendungen sind zwar angreifbar, doch es ist bereits ein Update verfügbar:

Hinweis: Wir weisen ausdrücklich darauf hin, dass obige Listen weder vollständig noch aktuell sind!




Guide: Workaround für den DLL-Preloading-Bug in Windows - Druckansicht - Seite 5 von 5

Ausweitung des Problems auf ausführbare Dateien (.EXE)
Der DLL-Preloading-Bug hat sich zum generellen "Binary Planting"-Problem ausgeweitet. ACROS Security hatte weitere Suchpfade von Windows-Betriebssystemen untersucht und dabei herausgefunden, dass die DLLs nur die Spitze des Eisbergs sind. Das Erstellen einer bösartigen Dynamic Link Library erfordert zumindest ein wenig Wissen und Aufwand, zudem sucht Windows zunächst im Programmverzeichnis, in den Systemverzeichnissen und im Windows-Ordner nach DLLs, deren Pfade nicht vollständig definiert wurden. Erst wenn die gesuchte DLL nicht an den üblichen Orten zu finden ist, greift Windows auf das aktuelle Arbeitsverzeichnis zu. Im Falle von ausführbare Dateien (.EXE) sucht das Betriebssystem mitunter zuerst im Arbeitsverzeichnis und ignoriert alle anderen Programme gleichen Namens.

ACROS Security hatte das Problem anhand von Safari 5.0.1 und 4.0.1 analysiert. Sollte Apples Webbrowser das Verzeichnis öffnen, in denen der Benutzer zuvor seine Downloads abgelegt hatte, geschah dies mit dem Aufruf von "explorer.exe" ohne weitere Pfadangabe. Mit der Suche nach "explorer.exe" begann Windows aber nicht im Systemverzeichnis, sondern im aktuellen Arbeitsverzeichnis. Dabei war es dem Betriebssystem völlig egal, ob es sich hierbei um einen lokalen Ordner, ein Remote-Verzeichnis oder eine WebDAV-Freigabe handelte. Microsofts Hotfix konnte hierbei nicht greifen, da dieser auf DLLs beschränkt ist.

Übersicht der Suchpfade für ausführbare Dateien
Windows bietet zahlreiche Möglichkeiten, um ein Programm zu starten. Welcher Suchpfad zur Anwendung kommt, hängt von der verwendeten Methode ab. Hier eine Übersicht:

Suchpfad für ShellExecute*
Die Funktion ShellExecute* wird recht häufig verwendet und gilt als vergleichsweise sicher, denn vor dem Ausführen eines Programms aus der Internet-Zone wird ein Warnhinweis angezeigt. Allerdings achten viele Benutzer kaum noch auf die häufigen Warnungen und leider bedient sich ShellExecute* zuallererst im akuellen Arbeitsverzeichnis.

  1. Das aktuelle Arbeitsverzeichnis
  2. Das 32-Bit-Systemverzeichnis
  3. Das 16-Bit-Systemverzeichnis
  4. Das Windows-Verzeichnis
  5. Die in der Umgebungsvariable PATH aufgeführten Verzeichnisse
  6. Verzeichnisse aus dem Registrierungsschlüssel der Software

Suchpfad für CreateProcess*, WinExec und LoadModule
Der Suchpfad der Funktionen CreateProcess*, WinExec und LoadModule erinnert an den für DLLs, welcher von LoadLibrary und LoadLibraryEx verwendet wird. Allerdings findet sich das aktuelle Arbeitsverzeichnis in der Suchreihenfolge an zweiter Stelle und im Gegensatz zum Programmstart über ShellExecute* wird vor dem Start der Anwendung keine Warnmeldung angezeigt.

  1. Das Verzeichnis, aus dem die Anwendung geladen wurde
  2. Das aktuelle Arbeitsverzeichnis
  3. Das 32-Bit-Systemverzeichnis
  4. Das 16-Bit-Systemverzeichnis
  5. Das Windows-Verzeichnis
  6. Die in der Umgebungsvariable PATH aufgeführten Verzeichnisse

Suchpfad für _spawn*p* und _exec*p*
Die Funktionen _spawn*p* und _exec*p* werden seltener genutzt, sind jedoch geradezu perfekt zum Binary Planting geeignet. Anwendungen, für deren Aufruf kein vollständiger Pfad übergeben wurde, werden zunächst im Arbeitsverzeichnis gesucht und eine Warnung vor dem Programmstart gibt es auch nicht.

  1. Das aktuelle Arbeitsverzeichnis
  2. Das 32-Bit-Systemverzeichnis
  3. Das Windows-Verzeichnis
  4. Die in der Umgebungsvariable PATH aufgeführten Verzeichnisse

Gibt es einen Workaround?
Nein, eine wirklich sinnvolle Lösung für dieses Problem ist bisher nicht bekannt. Beendet man den Dienst "Web Client", ist man zumindest vor dem Aufruf von Programmen aus WebDAV-Ordnern sicher, kann solche Freigaben dann aber gar nicht mehr nutzen. Zudem hat das Beenden von "Web Client" keine Auswirkungen auf Verzeichnisse im lokalen Netzwerk. Es ist nun an Microsoft, die Suchpfade derart anzupassen, die diese Bedrohung auf ein erträgliches Minimum reduziert wird.




© copyright 1998-2020 by Dipl.-Ing. Michael Doering
www.Au-Ja.de / www.Au-Ja.org / www.Au-Ja.com / www.Au-Ja.net ist eine Veröffentlichung von Dipl.-Ing. Michael Doering.
Alle Marken oder Produktnamen sind Eigentum der jeweiligen Inhaber. Alle Inhalte spiegeln die subjektive Meinung der jeweiligen Autoren wieder und sind geistiges Eigentum dieser Autoren. Alle Angaben sind ohne Gewähr! Wir setzen bei Nutzung unserer Publikation ausdrücklich die Verwendung des gesunden Menschenverstandes voraus. Sollten Sie mit dieser Voraussetzung nicht einverstanden sein, verstoßen sie gegen unsere Nutzungsbedingungen! Die Verwendung jeglicher Inhalte - auch auszugsweise - ist nur mit ausdrücklicher, schriftlicher Genehmigung erlaubt. Die Nutzung kurzer Ausschnitte für Nachrichten-Ticker ist hiervon ausdrücklich ausgenommen! Die geheimdienstliche Erfassung und Verarbeitung dieser Internetseite ist strengstens untersagt!
Sollten Ihnen über Hyperlink verknüpfte externe Inhalte auffallen, welche mit der deutschen oder europäischen Rechtssprechung in Widerspruch stehen, bitten wir um eine kurze Meldung. Kommentare und Hinweise zu rechtswidrigen Inhalten unseres lokalen Angebotes sind natürlich ebenfalls erwünscht. Weitere Informationen finden Sie im Impressum!

www.Au-Ja.de - http://www.au-ja.de/guide-windows-dll-preloading-workaround-print.phtml