Skip to content

Binary Planting frei Haus und mehr

Es gibt neue Entwicklungen beim Binary Planting, und eine Schwachstelle im GNU-C-Loader ermöglicht das Erlangen von root-Rechten.

Binary Planting - Visual Studio machts möglich

ACROS Security hat herausgefunden, dass Visual Studio u.U. damit entwickelte Anwendungen für Binary Planting anfällig macht, ohne dass der Entwickler irgend etwas dazu beitragen muss. Als Beweis und Beispiel dient ein auf der Konferenz "Hack In The Box" vorgestelltes Video, in dem in 34 Sekunden ein für Binary Planting anfälliges Programm geschrieben wird, das keine einzige Zeile eigenen Code enthält (Präsentation als PDF):

Es wird eine leere Default-MFC-Anwendung angelegt, die mit der Extension ".bp" für "Binary Planting" verknüpft wird. Ein Doppelklick auf die Datei test.bp startet diese Anwendung, die dabei die präparierte Bibliothek dwmapi.dll aus dem gleichen Verzeichnis lädt.

MFC-Anwendungen mit automatisch eingebauter Schwachstelle

Laut ACROS Security lädt jede mit Visual Studio 2010 erzeugte MFC-Anwendung beim Starten die Bibliothek dwmapi.dll aus dem aktuellen Arbeitsverzeichnis und ist damit unter Windows XP (und älteren Systemen) für Binary Planting anfällig. Als Entwickler können Sie nichts daran ändern, da es keine Möglichkeit gibt, das Verhalten von MFC-Anwendungen zu konfigurieren. In Anwendungen, die nicht mit einer Extension verknüpft sind und/oder die nicht von der Kommandozeile gestartet werden können, ist das Ausnutzen der Schwachstelle schwierig, wenn sie auch zumindest theoretisch möglich ist.

Kern des Problems: Microsofts MFC-Library

Die Schwachstelle befindet sich in Microsofts MFC-Library, die als Bestandteil des Visual C++ Redistributable Package verteilt wird. Sobald Microsoft die Schwachstelle darin behebt, sind alle Programme, die dynamisch gelinkt wurden, ebenfalls geschützt. Programme, in denen die MFC-Library statisch gelinkt wurde, bleiben angreifbar, da die Bibliothek dann Teil der Anwendung ist und die aktualisierte Version des Systems ignoriert wird. In diesen Anwendungen kann die Schwachstelle nur behoben werden, indem sie nach der Veröffentlichung eines Patches für Visual Studio neu übersetzt werden, so dass die neue Version der Bibliothek eingebunden wird.

Außer den mit Visual Studio erzeugten MFC-Anwendungen sind sehr wahrscheinlich auch alle mit anderen Tools erzeugten von dieser Schwachstelle betroffen, wenn sie betroffene Versionen der MFC-Library verwenden. Einige ältere Versionen davon sind nicht betroffen, ACROS Security hat jedoch keine Versionsinformationen veröffentlicht.

ACROS Security hat für Entwickler "Binary Planting Protection Guidelines" veröffentlicht, die Microsofts eigene Anleitungen, insbesondere den Text "Secure loading of libraries to prevent DLL preloading attacks", um zur Zeit 15 weitere Regeln ergänzen. Hinweise für Administratoren und Benutzer sind in Vorbereitung.

And now for something completely different...

Eine von Tavis Ormandy gefundene Schwachstelle im GNU-C-Loader erlaubt das Erlangen von root-Rechten, wenn ein präpariertes SUID-Programm aufgerufen wird. Auslöser ist ein Fehler beim expandieren der vom Programm übergebenen Variable $ORIGINS. Die dient dazu, Pfade zu Bibliotheken relativ zum Installationsort eines Programms anzugeben. Dadurch können nur von einem einzigen Programm verwendete Bibliotheken z.B. in einem Unterverzeichnis des Programmverzeichnis gespeichert werden und müssen nicht im Standardpfad für Bibliotheken liegen.

Laut ELF-Spezifikation soll der Loader $ORIGINS zwar bei SUID- oder SGID-Binaries ignorieren, die glibc-Entwickler haben das aber nicht entsprechend implementiert. Tavis Ormandy konnte die Schwachstelle ausnutzen, um eine Shell mit root-Rechten zu öffnen, musste dazu aber auf einige Tricks wie die Verwendung von Hardlinks, das Umleiten von Dateideskriptoren und das Setzen von Umgebungsvariablen zurückgreifen. Der Aufwand ist nötig, weil $ORIGINS keine Environment-Variable ist, auch wenn es auf den ersten Blick so aussieht. Stattdessen wird sie im Programm definiert. Je nach System variiert der Weg zur Ausnutzung der Schwachstelle, so dass es keinen allgemein gültigen Exploit gibt.

Betroffen ist mindestens glibc Version 2.12.1 unter Fedora 13 und Version 2.5 unter Red Hat Enterprise Linux 5 und CentOS 5. Updates werden bereits vorbereitet.

Die Moral von der Geschicht'

Warum ist diese Schwachstelle hier interessant? Immerhin schreibt Tavis Ormandy selbst

"Please note, this is a low impact vulnerability that is only of interest to security professionals and system administrators. End users do not need to be concerned."

Der Grund liegt im Zusammentreffen mehrerer Faktoren. Es handelt sich um einen Suchpfad, der ungeprüft übernommen wird und über den ein Angreifer eigenen Code einschleusen kann - in soweit handelt es sich um genau das gleiche Problem wie beim Binary Planting. Das diese Schwachstelle nur lokal ausgenutzt werden kann, ist dabei vernachlässigbar. Interessant ist die Schwachstelle und noch mehr der Exploit aus einem anderen Grund: Sie kann als Beweis dafür dienen, dass man wirklich keinen von außen kommenden Daten vertrauen darf. Selbst dann nicht, wenn sie von vermeintlich vertrauenswürdigen Programmen geliefert werden und eine Manipulation durch Dritte ausgeschlossen zu sein scheint. Wenn Sie also Programme haben, die für Binary Planting anfällig sind, sollten Sie beim Beheben dieser Schwachstelle auch gleich nach möglichen weiteren suchen. Nur im eigenen Programm geprüften Eingaben darf vertraut werden!

Soviel (zumindest vorerst) zu unsicheren Suchpfaden und dem Binary Planting. In der nächsten Folge beginnt eine kleine Reise durch die Welt der Schadsoftware. Los geht es mit Scareware - Schadsoftware, die viel bellt, aber meist nicht beißt.

Carsten Eilers


Übersicht über alle Artikel zum Thema

Standpunkt: Der Suchpfad ins Unglück
"Binary Planting" - Unsichere Suchpfade führen ins Verderben
"Binary Planting" - Welche Angriffe sind möglich und wie verhindert man sie?
Binary Planting frei Haus und mehr

Trackbacks

Dipl.-Inform. Carsten Eilers am : 2010 - Ein Rückblick auf ein ereignisreiches Jahr

Vorschau anzeigen
2010 war ein gerade aus Sicht der IT-Sicherheit ereignisreiches Jahr. 2011 kann es gerne ruhiger zugehen, aber vermutlich gilt wie immer die Regel von Bernd dem Brot: "Alles ist wie immer, nur schlimmer! Einige Beispiele: So hat z.B. das Bund