Heute schon gehasht ?

Ok, ok, Ihr habt mich, das ist Clickbait, oder? Muß es sein, denn es hat nichts mit Hashfunktionen, Hash-was-auch-immer-isch oder irgendwas, was Ihr schonmal gesehen habt zu tun und lang ist der Beitrag auch nicht. Clickbait, geht gar nicht anders !!!

Ha! von wegen!  Gehts doch 🙂 In dem Beitrag von vorgestern Manpages und die Hilfe gings u.a. um die Konsole und cowsay. In dem Zuge habe ich einen anderen Bashbefehl entdeckt: hash .

hash ist eine kleine Spionagefunktion der Bash, die eine Statistik darüber liefert, wie oft man welchen Befehl benutzt hat. Da gibt es natürlich einen Grund für, die Bash Shell analysiert die Pfade der verwendeten Programme, legt sie in einem Cache ab und benutzt das Cache um schneller Befehle zu finden. Ob das im 21. Jahrhundert mit Threadripper und 1 PB SSD Clustern wirklich noch nötig ist, mag dahingestellt sein.

Aber, nichts ist völlig umsonst …. muh har har!

Frage: Kann man das Cache manipulieren ?
Antwort: Ja, man kann.

Muß man ja, da alle Eingaben ausgewertet werden, könnte man die Statistiken schönen, in dem man gezielt Sachen eingibt, aber das ist hier natürlich nicht gemeint. hash kann nämlich noch mehr, es ist in der Lage, einzelne Programme in den Pfad aufzunehmen und auch zu entfernen :

[marius@eve ~]$ hash -p /opt/whoami whoami
[marius@eve ~]$ whoami
Vertraut nie dem Namen und der Path Variablen!
[marius@eve ~]$ which whoami
/usr/bin/whoami
[marius@eve ~]$ /usr/bin/whoami
marius
[marius@eve ~]$ hash -d whoami 
[marius@eve ~]$ whoami
marius

Damit das so funktioniert muß es selbstverständlich ein Programm/Skript namens whoami unter /opt/ geben:

[marius@eve ~]$ cat /opt/whoami 
#!/bin/bash

echo "Vertraut nie dem Namen und der Path Variablen!"

[marius@eve ~]$

Was kann man jetzt damit anstellen ?

Wenn man Scripte schreibt für die Bash, kann das sehr nervig sein, wenn man ständig den Pfad eines Programms mit angeben muß. Normalerweise würde man der $PATH Variablen den Ort zuweisen, der zum Finden und Ausführen von Programmen benutzt werden soll. Wenn man jetzt wie oben aber eine spezielle Version eines Befehls benutzen will, warum auch immer, dann wäre das der Weg genau das eine Programm und ebend nur das eine in die Skriptausführung mit einzubinden.

Sicherstellen kann man damit aber auch, daß ein Script in einer Minimal-Umgebung funktioniert, z.b. wenn es per Cron aufgerufen wird und/oder wenn so viel Speicher/Leistung wie nötig gespart werden muß, z.B. in einem Embeddedsystem. Wenn Bash gesagt bekommt, was es wo findet, muß es nie suchen, ergo keine unnötige IO.

Die eigentliche Frage muß lauten: Können wir das evtl für was böses ausnutzen ?

ein paar Gedanken zu „Was kann da schon schief gehen?“

  • – es ist eine uralte Funktion, übernommen aus der Steinzeit von der Bourneshell
  • – kaum einer kennt sie
  • – wurde sie je sicherheitsgeprüft ?
    – was passiert eigentlich, wenn man es verschachtelt aufruft ..

a) nie ein gutes Zeichen, siehe WinXP Kern in Win 7++
b) kein gutes Omen
c) keine Ahnung.

Also fast perfekte Aussichten auf Erfolg, weil sowas ist ja noch nie gut gegangen in der IT 😀

Einen kleinen, schnellen Test auf Vererbungsprobleme habe ich gemacht, aber den hat es bestanden:

[marius@eve ~]$ ./test1.sh 
Test1:
marius
Ändere Hash
Vertraut nie dem Namen und der Path Variablen!
Rufe zweite Bash auf
TEST in Test2
marius
Treffer Befehl
 1 /usr/bin/whoami
Test beendet .. entferne Hash
marius
[marius@eve ~]$ cat test1.sh 
#!/bin/bash
echo "Test1":
whoami
echo "Ändere Hash"
hash -p /opt/whoami whoami
whoami
echo "Rufe zweite Bash auf"
./test2.sh
echo "Test beendet .. entferne Hash"
hash -d whoami
whoami
[marius@eve ~]$ cat test2.sh 
#!/bin/bash
echo "TEST in Test2"
whoami
hash
[marius@eve ~]$

Bash handelt also Bashskripte immer separat , was gut ist. So sollte das auch sein.

Meine Googlesuche nach Bash-Hash Securityproblemen hat „leider“ keine Treffer ergeben, so daß entweder, noch niemand nachgesehen hat, ob das safe ist, oder sie safe ist. Vielleicht findet ja jemand von Euch was dazu raus.

Denkbar wäre ein Injectionangriff auf hash, der müßte ja nur ein im Opferskript benutztes Kommando durch eine Schadversion ersetzen. Wenn ich allerdings so eine Lücke hätte, könnte ich das Schadprogramm vielleicht auch direkt ausführen. Aber immerhin, ein Ansatz… vielleicht wird ja was daraus.

Schreibe einen Kommentar