Heute war mal wieder so ein Tag wo ich mir dachte was das eigentlich soll.
Durch einen Zufall habe ich mitbekommen, dass
dstat - ein eigentlich überaus nützliches Tool, aus dem aktuellen Verzeichnis den Ordner Plugins lesen will.
Wie der Zufall es halt wollte, führte ich dstat in einem Verzeichnis aus, das ich in einer anderen SSH-Session schon gelöscht hatte und bekam eine Fehlermeldung..
Ein kurzer Blick in den Sourcecode brachte dann die Erklärung:
try:
import sys, signal, os, re, time
import types, signal, resource, getpass
inspath('/usr/local/share/dstat/')
inspath('/usr/share/dstat/')
inspath(os.path.abspath(os.path.dirname(sys.argv[0])) + '/plugins/') # binary path + /plugins/
inspath(os.getcwd() + '/plugins/') # current path + /plugins/
inspath(os.getcwd()) # current path
inspath(os.path.expanduser('~/.dstat/')) # home + /.dstat/
Weiter unten im Code stand dann endgültig fest, dass diese dstat-Version aus dem aktuellen Verzeichnis Code nachlädt und ausführt. Ein kleiner Check und der Demo-Exploit wurde einem Kollegen auf seinem System vorgeführt (so schnell bekommt man Root-Rechte auf einem Server...). Wie oft kommt es schon mal vor, dass man als root dstat in /tmp oder anderen Verzeichnissen ausführt
Dann began die Suche, ob nicht schon jemand diesen eklatanten Bug gefunden hat. In der Tat wurde schon Ende 2009 Debian über ein Advisory auf diese Lücke aufmerksam gemacht. Man liest
weiter und ich jedenfalls staune nicht schlecht, dass diese Lücke nur in unstable gefixt wurde, aber weder in stable noch in oldstable.
dstat (PTS)
etch 0.6.3-2 vulnerable
lenny 0.6.7-1 vulnerable
squeeze, sid 0.7.2-1 fixed
Also: warten auf das Update und solange dstat vorsichtig benutzen.. Natürlich ist es klar, dass man kein Versionssprung einbringen will, aber der Fix gegen die verwendete Version ist nun wirklich trivial. Ich befürchte eher, dass irgendwo im Patch-Prozess der Bug aufgrund der neuen Version in unstable zu schnell geschlossen wurde und dann nicht die Schritte für ein Fix in stable angegangen wurden