[TuT] Sicherheitslücken von Umgebungsvariablen ($PATH)

[DMW007]

Kleiner Hinweis vorweg:
Da in diesem Tutorial C-Code compiliert wird, braucht ihr einen C-Compiler.
Falls ihr noch keinen habt, installiert über eure Paketverwaltung am besten gcc, den verwende ich auch hier im Tutorial.
Alternativ tut es natürlich jeder andere C-Compiler auch, wenn ihr damit umgehen könnt.

Als Beispiel nehmen wir mal ein ganz simples C-Programm:

#include <stdio.h>

int main() {
        printf("Irgendein langer Content\n");
        system("clear");
        printf("Neuer Content\n");
        return 0;
}

Wir haben irgendeine Ausgabe, die später durch eine neue ersetzt werden soll.
Das wird hier über einen Aufruf von system("clear") realisiert, der bekanntlich den gesamten Konsoleninhalt löscht.
Anschließend kommt die neue Bildschirmausgabe.
An sich ein ziemliches Hello-World Programm, von dem man zunächst kaum vermuten würde, dass in den 3 Zeilen eine Schwachstelle steckt.

Wenn wir aber mal gucken, wo clear liegt:

[daniel@linux ~]# which clear
/usr/bin/clear

stellen wir fest, dass hier mit Umgebungsvariablen gearbeitet wird, genauer genommen mit $PATH.
Wenn wir uns $PATH mal ausgeben lassen, wissen wir auch, wie Linux auf /usr/bin/clear kommt:

[daniel@linux ~]# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

Wenn clear aufgerufen wird, prüft Linux also diese Pfade (Mit : getrennt, statt wie \ unter Windows) durch, bis es den gewünschten Befehl findet (oder eben nicht, wenn er nicht existiert).
Oben wurde bereits festgestellt, dass clear in /usr/bin liegt, der in $PATH enthalten ist - folglich funktioniert das ganze.

$PATH ist eine lokale Variable auf unserem System, daher können wir diese nach Lust und Laune verändern.
Spätestens jetzt kann man sich eigentlich denken, worauf das ganze hinauslaufen wird.
Wir legen mal testweise im root einen Ordner exploit an. Wo spielt keine Rolle, solange der aktuelle Benutzer Schreibrechte darauf hat.
Ich machs jetzt mal direkt im root-Verzeichniss, da das Programm nachher zur De

mkdir exploit

und exportieren diesen anschließend in die Variable $PATH

export PATH=/exploit

Nun gucken wir mal, was Linux jetzt sagt wenn wir clear suchen:

[daniel@linux ~]# which clear
/usr/bin/which: no clear in (/exploit)

Er sucht nun nach clear in /exploit, also funktioniert soweit schonmal alles.
Jetzt muss in /exploit natürlich noch ein Programm namens clear erzeugt werden, damit dies aufgerufen und keine Fehlermeldung erzeugt wird.

[daniel@linux ~]# gcc -o /exploit/clear exploit.c

Wenn ihr das testet solltet ihr compilieren bevor ihr $PATH exportiert, da sonst die ganzen aufrufe wie zb vom gcc Compiler ebenfalls in $PATH, also /exploit landen und da logischerweise nicht gefunden werden können.

Nun starten wir das Hello-World Testprogramm vom Anfang

[daniel@linux ~]# ./test
Irgendein langer Content
exploit started!
Neuer Content

und es funktioniert, der Exploit wurde gestartet

In dem Fall nicht sehr dramatisch da hier nur ein einfaches printf aufgerufen wird.
Wenn man nun bedenkt, dass das Hauptprogramm evtl mit root-Rechten läuft, hat man natürlich ruck zuck eine Shell.

Verhinderbar wäre das ganze, indem man anstelle von Umgebungsvariablen eben absolute Pfade verwendet.
Mit

[daniel@linux ~]# which clear
/usr/bin/clear

wurde ja bereits ermittelt wo clear liegt, nämlich in /usr/bin.

Somit wäre unser Hello-World Programm mit

system("/usr/bin/clear");

statt

system("clear");

entschärft.