UPDATES:

• 13.09.2010 - Ein neues Kapitel beschäftigt sich mit der Ausweitung des Problems auf ausführbare Dateien (.EXE), zudem wurde die Liste der betroffenen Programme aktualisiert.
  
  
• 09.09.2010 - Die Liste der betroffenen Programme wurde aktualisiert, da einige Hersteller Updates veröffentlicht haben.
  
  
• 02.09.2010 - Drei neue Kapitel hinzugefügt:
  • Bekannte Probleme mit bestimmten Anwendungen
  • Microsofts Fix-it-Tool
  • Betroffene Programme

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:

• Update für Windows XP (32-bit)
• Update für Windows XP (64-bit)
• Update für Windows Vista (32-bit)
• Update für Windows Vista (64-bit)
• Update für Windows 7 (32-bit)
• Update für Windows 7 (64-bit)
• Update für Windows Server 2003 (32-bit)
• Update für Windows Server 2003 (64-bit)
• Update für Windows Server 2008 (32-bit)
• Update für Windows Server 2008 (64-bit)
• Update für Windows Server 2008 R2 (64-bit)

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.