Der Suchpfad ins Unglück
Suchpfade sind eine nützliche Erfindung, gäbe es sie nicht, wüssten die Programme nicht, wo sie ihre Bibliotheken und Daten finden und müssten das gesamte Dateisystem durchsuchen. Stimmt der Suchpfad nicht, kann das unangenehm werden, weil die gesuchte Dateien nicht gefunden werden. Oder weil Dateien gefunden werden, die besser nicht gefunden worden wären: Bibliotheken mit Schadcode zum Beispiel. Falls Sie bei diesen vielen Fundstellen den Überblick verloren haben - kein Problem, auch vielen Programmen ergeht es so. Also werfen wir doch mal einen genaueren Blick auf das Problem mit den unsicheren Suchpfaden. Aber zuerst noch ein wichtiger Rat: "Don't Panic!" - weder gibt es 40 oder mehr 0-Day-Schwachstellen in eben so vielen Programmen noch eine einzige in Windows. Jedenfalls keine, die mit dem Suchpfad zusammen hängen.
Der Klassiker: Unsichere Suchpfade unter Unix/Linux
Unsichere Suchpfade sind unter Unix/Linux eine altbekannte Schwachstelle, die i.A. aber nur lokal ausgenutzt werden kann, um einem bereits authentifizierten Benutzer höhere Benutzerrechte zu verschaffen. Natürlich gilt das genauso für einen entfernten Angreifer, der z.B. über eine Schwachstelle im Webserver in das System eindringen konnte und dabei dessen Rechte erlangt hat, aber dieser Sonderfall ist für das allgemeine Problem uninteressant.
Ganz allgemein enthält ein unsicherer Suchpfad ein Verzeichnis (i.A. handelt es sich dabei um das aktuelle Arbeitsverzeichnis), in dem ein Benutzer eine eigene Version einer vom betroffenen Programm verwendeten Datei, meist einer Bibliothek oder Konfigurationsdatei, speichern kann. Das ist an sich noch kein Problem, solange dieses unsichere Verzeichnis sich hinter dem Verzeichnis befindet, in dem die entsprechende zum System gehörende Datei gespeichert ist. Das Programm findet dann die richtige Datei und verwendet diese. Anders sieht es aus, wenn zuerst die vom Benutzer manipulierte Datei gefunden und daher geladen wird. Die zweite Voraussetzung dafür, dass ein Suchpfad unsicher ist, lautet also "Das vom Benutzer beschreibbare Verzeichnis befindet sich vor dem Verzeichnis mit den entsprechenden Systemeigenen Dateien".
Aber auch das ist noch kein Problem, sofern das Programm nicht mit höheren Benutzerrechten läuft, als sie der angreifende Benutzer selbst hat. Ganz im Gegenteil ist es oft sogar hilfreich, wenn ein Programm zuerst die von einem Benutzer individuell angepassten Dateien lädt und nur wenn es die nicht gibt die Systemweit einheitlichen. Anders sieht es wiederum aus, wenn das Programm mit höheren Benutzerrechten läuft, z.B. weil es während der Ausführung root-Rechte benötigt. Dann kann ein böswilliger Benutzer dem Programm z.B. eine präparierte Bibliothek unterschieben und darüber eigenen Code mit diesen höheren Benutzerrechten ausführen.
Man muss also darauf achten, dass im Suchpfad nur die Verzeichnisse stehen,
in denen sich die gesuchten Dateien auch befinden können und sollen.
Das ist allgemein bekannt, trotzdem gibt es immer mal wieder entsprechende
Schwachstellen, meist weil das aktuelle Verzeichnis "." durch
Unachtsamkeit in den Suchpfad gelangt ist.
Der Internet Explorer und die "Carpet Bomb" von Safari
Auch Windows hatte bereits mit unsicheren Suchpfaden zu kämpfen. Ein sehr bekanntes Beispiel für einen von externen Angreifern ausnutzbaren unsicheren Suchpfad ist eine entsprechende Schwachstelle im Internet Explorer, die 2008 entdeckt wurde: Der IE suchte u.a. auf dem Schreibtisch nach Bibliotheken, was in Verbindung mit einer Schwachstelle in Safari, durch die alle Downloads auf dem Schreibtisch abgelegt wurden, von entfernten Angreifern zur Ausführung beliebigen Codes ausgenutzt werden konnte. Anfangs wollte Microsoft diese Schwachstelle gar nicht beheben, sondern hielt allein Apple für den Schuldigen. Apple wiederum sah das genau anders herum, aber letztendlich wurden beide Schwachstellen behoben: Noch im gleichen Monat in Safari und knapp ein Jahr später in Internet Explorer und SearchPath.
Die Anwendungsentwickler von Microsoft sollten also spätestens seit 2008 wissen, dass man bei der Konstruktion von Suchpfaden vorsichtig sein muss. Um so verwunderlicher, dass es nun, 2 Jahre später, erneut Probleme mit unsicheren Suchpfaden in Microsoft-Programmen gibt.
Der aktuelle Fall: Unsicheres Laden von DLLs durch Windows(programme)
Die aktuelle Schwachstelle beim Laden von Bibliotheken wurde vom Sicherheitsunternehmen ACROS ans Licht gebracht, als eine entsprechende Schwachstelle in iTunes veröffentlicht wurde:
"As a result of an incorrect dynamic link library loading in Apple iTunes for Windows, an attacker can cause her malicious DLL to be loaded and executed from local drives, remote Windows shares, and even shares located on Internet.
All a remote attacker has to do is plant a malicious DLL with a specific name on a network share and get the user to open a media file from this network location in iTunes - which should require minimal social engineering. Since Windows systems by default have the Web Client service running - which makes remote network shares accessible via WebDAV -, the malicious DLL can also be deployed from an Internet-based network share as long as the intermediate firewalls allow outbound HTTP traffic to the Internet."
Metasploit-Entwickler HD Moore hat die Schwachstelle unabhängig davon während der Untersuchung der Shortcut-Schwachstelle entdeckt und festgestellt, dass rund 40 Programme betroffen sind. Seine Untersuchungsergebnisse hat er in zwei Einträgen in den Blogs von Rapid7 und dem Metasploit Projekt veröffentlicht, vom parallel veröffentlichten Tool zur Suche nach betroffenen Programmen gibt es inzwischen eine verbesserte Version.
Die Anzahl betroffener Programme wächst laufend, wie man bei der Suche nach "DLL Hijacking Exploit" in der Exploit-DB feststellen kann. Listen betroffener Programme werden auch von Peter Van Eeckhoutte und VUPEN bereit gestellt. Laut Internet Storm Center gibt es bereits die ersten Angriffe über die Schwachstelle, namentlich auf uTorrent, Microsoft Office und Windows Mail.
Was ist los?
Im Grunde handelt es sich um eine seit langem bekannte Art von Schwachstellen, wie Thierry Zoller festgestellt hat: Die ersten Berichte gab es bereits im Jahr 2000. Ursache der Schwachstelle ist die Art, wie die betroffenen Programme bestimmte Bibliotheken laden: Wird eine mit dem Programm verknüpfte Datei geladen, wird auch versucht, bestimmte Bibliotheken aus dem gleichen Verzeichnis zu laden. Neu ist, dass das auch passiert, wenn die verknüpfte Datei von einem entfernten Laufwerk geladen wird. Beim Laden z.B. einer harmlosen MP3-Datei durch einen betroffenen Mediaplayer wird dann auch eine im gleichen Verzeichnis gespeicherte präparierte Codec-Bibliothek geladen, über die dann Schadcode eingeschleust wird.
Microsoft hat ein Security Advisory zur Schwachstelle veröffentlicht und weist ebenfalls darauf hin, dass es sich um einen neuen Angriffsvektor für die seit langen bekannte Klasse der "DLL Preloading Attacks" handelt und nicht um eine neue Schwachstelle. Weitere Informationen liefert ein Artikel im Security Research & Defense Blog.
Microsoft hat ein Tool bereit gestellt, mit dem das Laden von Bibliotheken von WebDAV- und Netzwerklaufwerken unterbunden werden kann.
Problem erkannt, Problem (bald) gebannt?
Die Frage ist, wer für diese Schwachstellen verantwortlich ist: Microsoft, weil Windows überhaupt Bibliotheken von entfernten Laufwerken lädt und/oder sich das aktuelle Arbeitsverzeichnis im Suchpfad befindet, oder die Entwickler der Programme, weil sie den Suchpfad nicht anpassen? Carsten Eiram von Secunia ist der Meinung
"The vulnerability is not in the Windows OS itself, but is caused by bad (insecure) programming practises in applications when loading libraries combined with how the library search order works in Windows."
und dem kann man eigentlich nur zustimmen. Was ein Programm nachlädt und wie es das tut, ist eindeutig die Angelegenheit der jeweiligen Entwickler. Microsoft hat bereits vor einiger Zeit ausführlich erklärt, wie Bibliotheken richtig geladen werden.
Würde Microsoft diese Schwachstelle jetzt generell beheben, egal ob durch das Nicht-Laden der Bibliotheken von entfernten Laufwerken oder durch das Entfernen des aktuellen Verzeichnisses aus dem Suchpfad, wäre das Geschrei vermutlich gross, da dadurch ein dokumentiertes Verhalten geändert würde und bestimmte Funktionen nicht mehr wie zuvor funktionieren würden. Denn es wären auch alle Programme betroffen, die mit Absicht auf entfernte Bibliotheken zugreifen, was ja auch über einen sicheren Pfad erfolgen kann, oder Bibliotheken aus dem aktuellen Verzeichnis nachladen. Zwar stellt Microsoft jetzt ein Tool bereit, das das Laden von entfernten Laufwerken verhindert, aber dabei handelt es sich um einen Workaround, der ggf. rückgängig gemacht werden kann, wenn ein benötigtes Programm mit dem geänderten Verhalten nicht klar kommt.
Geoffroy Couprie, ein Entwickler des VLC Media Player (Ups!), hält es dagegen für eine Schwachstelle im Betriebssystem:
"So, now, let’s take a look at the fix. This is an OS flaw. You can’t fix all your applications yourself."
Auf dem ersten Blick mag es so aussehen, aber: Wenn ein Programmierer eine bestimmte Bibliothek laden will, warum gibt er dann nicht den passenden Pfad als Suchpfad an sondern verwendet den von Windows vorgegebenen, der jede Menge für diese Bibliothek garantiert falsche Pfade enthält? Faulheit? Bequemlichkeit? Keine Lust, nachzudenken? Das Problem nicht erkannt? Eine meines Erachtens plausible Erklärung liefert ein Eintrag im Blog von F-Secure:
"The documentation for LoadLibrary has about 1100 words, the page describing it in more detail has 1000 words, and the page that tells you how to really get it right has 900 more. That's around 3000 words, or ten times the length of this post. You just gotta love LoadLibrary!"
Und das ist ja nicht die einzige Dokumentation, die gelesen und verstanden werden will. Gut möglich, dass viele Entwickler an dem Punkt mit dem Lesen aufgehört haben, an dem sie ihre Bibliothek laden konnten. Die Feinheiten dürften vielen ziemlich egal gewesen sein, frei nach dem Motto "Lädt, fertig!". Wozu sich weiter Gedanken über ein augenscheinlich behobenes Problem machen?
Eine Möglichkeit, die Schwachstelle in den eigenen Programmen zu
verhindern,
nennt
David LeBlanc: Für das Laden der Bibliotheken wird das aktuelle
Arbeitsverzeichnis durch ein bekannt sicheres Verzeichnis, z.B.
c:\windows\system32 ersetzt, nach dem Laden wird das vorherige
Arbeitsverzeichnis wieder hergestellt. Der Vorteil dieses Ansatzes:
Lädt die geladene Bibliothek ihrerseits weitere Bibliotheken nach, tut
sie das mit einem sicheren aktuellen Verzeichnis, unabhängig davon, ob
sie selbst eine Schutzfunktion enthält oder nicht.
Übrigens stellt Geoffroy Couprie in seinem Text eine sehr gute Frage:
"(if someone can tell me why [das aktuelle Verzeichnis im Suchpfad ist], I would be delighted to know that)"
Das wüsste ich auch gerne. Es gibt sicher gute Gründe, in bestimmten Fällen im aktuellen Verzeichnis nach einer Bibliothek zu suchen, aber warum lässt Microsoft den Pfad dann nicht in diesen Fällen explizit vom jeweiligen Entwickler entsprechend ändern statt ihn generell so vorzugeben? Zumal ja durch Unix seit langem bekannt ist, dass das aktuelle Verzeichnis im Suchpfad des öfteren für Probleme sorgt?
Keine Panik, kein Grund zur Aufregung
Auf den ersten Blick mag die Meldung, dass über 40 verschiedene Programm über eine neue Schwachstelle (korrekter: Einen neuen Angriffsvektor) aus der Ferne zum Ausführen von Schadcode missbraucht werden können, sehr gefährlich erscheinen. Aber: Für einen erfolgreichen Angriff muss ein Benutzer dazu gebracht werden, eine mit einem betroffenen Programm verknüpfte Datei auf einem entfernten Laufwerk zu öffnen. Nun sind auf der Liste betroffener Programme viele weit verbreitete Anwendungen und auch etliche Windows-Komponenten enthalten, und eine Webseite oder eine E-Mail mit passenden Link und schönen Social-Engineering-Text ist schnell geschrieben, aber: Warum sollten sich die Cyberkriminellen diese Mühe machen, solange es genug Schwachstellen gibt, die ganz ohne Interaktion des Benutzers im Rahmen von Drive-by-Infektionen ausgenutzt werden können? Die gemeldeten Angriffe halte ich zumindest zum jetzigen Zeitpunkt mehr oder weniger für Tests, da wollen ein paar Cyberkriminelle mal gucken, wie groß ihre Erfolgsaussichten sind.
Nicht unterschätzen sollte man dagegen die interne Gefahr: Alle diese Schwachstellen lassen sich natürlich auch von internen Angreifern ausnutzen. Wenn es die denn gibt.
Ähnliche Schwachstelle in Linux?
In bestimmten Fällen können Linux-Distributionen eine vergleichbare Schwachstelle enthalten: Wird der Suchpfad in einem Skript durch
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib
erzeugt und ist $LD_LIBRARY_PATH vorher leer, ist der
exportierte Pfad
:/path/to/app/libwas vom Dynamic Linker als
$PWD:/path/to/app/lib
interpretiert wird: Der Suchpfad enthält nun das aktuelle
Arbeitsverzeichnis, das z.B. von sudo nicht geändert wird, so
dass es u.U. zur Ausführung eingeschleusten Codes mit root-Rechten kommen
kann. Diese Schwachstelle kann aber nicht aus der Ferne ausgenutzt werden,
sondern erlaubt lediglich eine lokale Privilegieneskalation. Sie zeigt
aber, dass man beim Erzeugen von Suchpfaden sehr vorsichtig vorgehen muss.
In dem Sinne: Falls Sie Suchpfade in Ihren Programmen verwenden - sind Sie
sicher, dass die sicher sind? Immer, unter allen Umständen und
Voraussetzungen?
Trackbacks
Dipl.-Inform. Carsten Eilers am : 2010 - Ein Rückblick auf ein ereignisreiches Jahr
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Microsofts erster Patchday 2015 bringt den ersten 0-Day-Exploit
Vorschau anzeigen