Remote Binary Planting: Die unpatchbare Lücke in Windows

Ein Programmierer, der beispielsweise die Codezeile HMODULE MyDLL = LoadLibraryA("C:\Program Files\My Company\My App\MyDLL.DLL"); verwendet, kann sicher sein, dass er entweder die Datei MyDLL.DLL aus dem Verzeichnis C:Program FilesMy CompanyMy App in seine Applikation lädt oder einen Fehler auslöst, weil die gewünschte Datei nicht existiert.

Die Fehlerbedingung wird recht häufig auftreten, weil die Datei MyDLL.DLL aus den verschiedensten Gründen in einem anderen Verzeichnis liegen kann. Die bekanntesten davon sind:

• Windows ist nicht auf dem Laufwerk C: installiert.
• Es handelt sich um 64-Bit-Windows, dann heißt das Standard-Verzeichnis für 32-Applikationen meist C:Program Files (x86).
• Es handelt sich um Windows XP, dann ist das Verzeichnis je nach Sprachversion unterschiedlich.
• Der Benutzer hat bei Installation ein anderes Verzeichnis gewählt.
• Der Anwender hat die Applikation auf eine andere Platte verschoben, beispielsweise aus Platzgründen.

Daher geben Entwickler oft gar keinen Pfad an und nutzen etwa Code wie HMODULE MyDLL = LoadLibraryA("MyDLL.DLL");. Dann verwendet Windows die Default-Suche für DLL-Dateien. Ab Windows XP SP2 wird standardmäßig folgende Reihenfolge verwendet:

1. Das Verzeichnis, in dem auch die Applikation (EXE-Datei) installiert ist.
2. Das Windows-System-Verzeichnis (meist C:WindowsSystem32).
3. Das 16-Bit-System-Verzeichnis (C:WindowsSystem).
4. Das Windows-Verzeichnis (C:Windows).
5. Das aktuelle Verzeichnis
6. Alle Verzeichnisse, die in der Umgebungsvariable PATH aufgelistet sind.

Eine Applikation, die ihre DLLs grundsätzlich im selben Verzeichnis ablegt wie ihre eigene EXE-Datei, ist nicht betroffen. Entwickler, die sich in ihrem Prozess eine PATH-Variable zusammensetzen, um DLLs zu finden, berücksichtigen oft nicht, dass der Pfad erst nach dem aktuellen Verzeichnis durchsucht wird.

Damit eine Anwendung verwundbar ist, müssen natürlich noch ein paar Nebenbedingungen erfüllt sein. Erforderlich ist unter anderem, dass die Applikation tatsächlich das aktuelle Verzeichnis wechselt, wenn der Benutzer eine Funktion wie "Datei – öffnen" aufruft. Außerdem sollte sie möglichst unmittelbar danach eine DLL nachladen.

Wenn die Applikation alle Bedingungen erfüllt, hat der Angreifer ein leichtes Spiel. In manchen Fällen muss er wissen, welche Funktionsnamen oder Ordinal die Anwendung aus der DLL aufruft und die entsprechenden Funktionen in seiner DLL ebenfalls implementieren – allerdings mit Schadcode.

Wenn die Applikation nicht überprüft, ob alle nötigen Funktionen in der DLL vorhanden sind, hilft dem Angreifer die Funktion DllMain, die in jeder DLL implementiert ist. Sie wird aufgerufen, wenn ein Prozess oder Thread eine DLL lädt beziehungsweise aus dem Speicher entfernt. In dieser Funktion kann der Hacker seinen Schadcode implementieren.