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:
- Das Verzeichnis, in dem auch die Applikation (EXE-Datei) installiert ist.
- Das Windows-System-Verzeichnis (meist C:WindowsSystem32).
- Das 16-Bit-System-Verzeichnis (C:WindowsSystem).
- Das Windows-Verzeichnis (C:Windows).
- Das aktuelle Verzeichnis
- 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.
Neueste Kommentare
11 Kommentare zu Remote Binary Planting: Die unpatchbare Lücke in Windows
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
‚Eigentlich handelt es sich nicht um ein Microsoft-Problem‘ ???
„Microsoft hat das DLL-Suchverhalten 1993 in Windows NT 3.1 implementiert und mit nur wenigen Veränderungen in die aktuellen Windows-Versionen übernommen. Würde Microsoft heute ein Betriebssystem neu entwickeln, gäbe es dieses Verhalten nicht. Bei Windows wurde es von Version zu Version aus Kompatibilitätsgründen beibehalten“
Das ist doch ein Widerspruch in sich selbst oder?
AW: ‚Eigentlich handelt es sich nicht um ein Microsoft-Problem‘ ???
…selbstverständlich liegt das Problem bei MS.
Ohne wäre Fremdanbieter-Software anders entwickelt
worden.
Ich liebe mein Ubuntu…
AW: AW: ‚Eigentlich handelt es sich nicht um ein Microsoft-Problem‘ ???
Jeder der auch nur etwas Verstand hat sollte Wissen das es endglütige Sicherheit niemals geben wird und Verbrecher – also die Bösen unter den Hackern – werden immer nur System bevorzugen welche für diese auch interesant sind. Also auch genügend Opfer zur Verfügung stellen.
So sicher wäre wäre ich mir bei Linux oder Ubuntu auch nicht. Habe ich übrigens auch hier, nur taugt es immer noch nicht vollends für die tägliche Arbeit und ohne Bateln geht da auch nichts wirklich – was unter MS auch nicht anders ist.
Für einen Witz halte ich je doch dass MS am „Windows Home Server Vail“ entwickelt, wo doch sie selbst wissen müssten dass der Fehler im Kernel liegt und damit auch nicht behoben wird. Leider steht darüber auch nichts im Test, was aber wirklich mal nötig wäre.
Übrigens… ich würde auf Linux Mint umsteigen. Auch eine Distr welche auf Ubuntu basiert. Aber halt Geschmacksache ;)
LOL
I don’t worry, ich bin auf der guten Seite der Macht;-)))
Über den Hauptknackpunkt habe ich nichts gelesen
Was mir nach Durchlesen des Artikels noch nicht klar geworden ist: wie kommt die „böse“ DLL auf meine Festplatte?
Wenn der Anwender so blöd ist, auf jeden Link „klick mich, es wird gut für dich sein“ klickt, dann kann man dafür nicht Microsoft die Schuld geben.
AW: Über den Hauptknackpunkt habe ich nichts gelesen
Von diesem Problem sind hauptsächlich Firmen betroffen, bei denen zahlreiche Nutzer Zugang zu einem Netzwerklaufwerk haben. Ein Mitarbeiter kopiert eine DLL in ein Verzeichnis, in dem normalerweise Dokumente liegen. Andere Mitarbeiter, die mit einer angreifbaren Applikation (Powerpoint 2007/2010, Word 2007) ein unverseuchtes Dokument öffnen, holen sich den Schadcode über die DLL.
Das Anklicken eines Links ist in diesem Fall eher harmlos, jedenfalls, wenn es sich um einen HTTP- oder FTP-Link handelt. Ein Netzwerklink wie smb://… ist jedoch gefährlich.
Dennoch ist es möglich, eine DLL per HTTP oder FTP ins Downloadverzeichnis zu laden. Wenn dort noch Word- oder Powerpoint-Dateien liegen, und der Nutzer diese von dort öffnet, führt er auch die DLL aus. Die Gefahr ist aber eher gering, da viele Anwender inzwischen wissen, dass man sich keine DLLs oder ähnlichs in Download-Verzeichnis holt.
AW: AW: Über den Hauptknackpunkt habe ich nichts gelesen
Seit wann öffnet Word oder Powerpoint DLL’s im gleichen Pfad wie das Dokument? Vorallem, welche DLL’s sollten dabei geladen werden? Das ein Dokument eine Funktion aus einer DLL implementieren kann, ist für mich relativ „neu“??
AW: AW: AW: Über den Hauptknackpunkt habe ich nichts gelesen
„Seit wann öffnet Word oder Powerpoint DLL’s im gleichen Pfad wie das Dokument?“
Das ist ja gerade der Bug, dass Word und Powerpoint (sowie zahlreiche andere Applikationen) genau das machen.
Eine Liste der betroffenen Apps und die DLLs, die aus dem Dokumentverzeichnis geladen werden gibts unter http://www.exploit-db.com/dll-hijacking-vulnerable-applications/
AW: AW: AW: AW: AUA
Opera… Thunderbird…
Ansonsten habe ich ja nicht viele Apps welche dort aufgelistet sind oder nicht die dortigen Versionen. Aber Opera und Thunderbird, das ist mies.
Wie schaut es eigentlich mit WINE unter Linux aus?
Können dieses DLL’s dort ebenso genutzt/missbraucht werden?
So gravierend ist das nicht.
Wer sich das alles mal durchliest, kommt zum Schluss, dass das Problem an sich nicht besonders gravierend ist.
Schafft es ein Angreifer nämlich, eine entsprechende DLL an einer Stelle zu platzieren, wo es gefährlich werden kann, dann liegt mit der IT-Sicherheit des Betroffenen (bzw. der betroffenen Firma) sowieso bereits einiges im Argen.
Tatsächlich gravierend hingegen ist die Tatsache, dass für dieses Problem kein praktikabler Patch entwickelt werden kann.
Im Grossen und Ganzen ist es aber hauptsächlich Futter für die ganzen Haterboys, die jetzt hier wieder gegen M$ stänkern können ;-)
(Und das sage ich als langjähriger Linux-User)
AW: Nicht gravierend ?
In welchen Unternehmen sind die Leute auch mit Notebooks im Firmennetz? Wer nimmt diese mit nach Hause und was tut diese damit dort?
So sicher kann man bei Close-Source als Admin überhaupt nicht agieren, wenn die innere Struktur im Unternehmen dies nicht zulässt. In den meisten Unternehmen verlassen sich Management und Mitarbeiter darauf dass alles so funktioniert wie diese es sich vorstellen. Dann bleibt dir als Admin nur der Wunschgedanke dass sich alle daran halten was du vorgibst.
Und das dies der Fall ist kann man nur kontrollieren wenn man einen kleinen Sicherheitsstaat innerhalb des Unternehmens aufbau. Beliebt macht man sich damit aber nicht. Das ist dann der Gegensatz dazu.