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.