Sys-Admins und Forensiker aufgepasst bei ldd
Das System-Tool ldd ist ein wenig fahrlässig geschrieben - was ein trickreicher Angreifer ausnutzen könnte, um bei der Analyse eigenen Code auszuführen.
Normalerweise sind Fehler in System-Utilities aus Sicherheitssicht nicht sonderlich spannend. Wenn das Tool jedoch regelmäßig genutzt wird, um Informationen über verdächtige Programme zu erhalten, sieht die Sache schon etwas anders aus.
Genau das ist der Fall bei dem System-Tool ldd, das die Abhängigkeiten von dynamischen Bibliotheken auflöst und einen Einblick in den Innereien eines unbekannten Programms gibt. Es gehört damit zum Standard-Repertoire von Sys-Admins und Forensikern. Peteris Krumin erklärt in seinem Blog, wie ldd unter Linux arbeitet – und wie man das ausnutzen kann, damit das untersuchte Programm beliebigen Code ausführen kann.
Der Clou dabei ist, dass ldd eigentlich nur ein Shell-Script ist und das zu analysierende Programm tatsächlich aufruft. Dabei setzt es die Umgebungsvariable LD_TRACE_LOADED_OBJECTS, die dem Loader signalisiert, dass er das Programm nicht starten sondern lediglich die Abhängigkeiten anzeigen soll. Krumins Trick: Er sorgt dafür, dass nicht der systemweite Loader aufgerufen wird, sondern sein eigener. Das kann er durch passende Optionen beim Kompilieren des Programms festlegen. Da der Loader bereits aufgerufen wird, wenn jemand das Binary mit ldd untersucht, kann er dort beliebigen Code ausführen.
In seinem Blog-Posting beschreibt Krumins ein Szenario, wie er einen System-Administrator mit diesem Trick hereinlegen könnte, indem er sich über eine Fehlermeldung zu fehlenden Bibliotheken beschwert. Es ist durchaus wahrscheinlich, dass der Admin dann ldd aufruft, um dem Problem auf die Spur zu kommen.
Nachtrag: Dieses Problem wurde anscheinend bereits früher aufgedeckt. (ju)
