Hallo Leute,
ich habe hier ein Programm, dass noch tmpnam benutzt, obwohl man das eigentlich nicht tun soll. Ich würde nun gern wissen, ob diese Lücke tatsächlich in bösartiger Weise ausgenutzt werden kann.
Das Programm generiert einen Dateinamen mittels tmpnam, testet auf eine existierende Datei mittels stat, fragt bei Bedarf beim Anwender nochmal nach und öffnen dann die Datei zum schreiben. Ein Angreifer müsste nun das Zeitfenster zwischen tmpnam und stat ausnutzen, um die Nachfrage zu verhindern und mittels symlink eine andere Datei zu überschreiben. Nun frage ich mich, ob es ein realistisches Angriffsszenario dafür gibt. Falls ja, würde das eine Menge Arbeit bedeuten...
Weiss jemand einigermassen sicher, ob tmpnam in der hier beschriebenen Art und Weise sicher oder unsicher benutzt wird? Oder vielleicht hat jemand einen Link auf eine tiefergehende Behandlung des Themas tmpnam und Co.?
Torsten
On Tue, Mar 19, 2002 at 08:23:18PM +0100, Torsten Werner wrote: Hallo Torsten,
ich habe hier ein Programm, dass noch tmpnam benutzt, obwohl man das eigentlich nicht tun soll. Ich würde nun gern wissen, ob diese Lücke tatsächlich in bösartiger Weise ausgenutzt werden kann.
Ja. Wie einfach das ist hängt natürlich davon ab, wie vorhersagbar die generierten Dateinamen auf dem jeweiligen System sind.
Das Programm generiert einen Dateinamen mittels tmpnam, testet auf eine existierende Datei mittels stat,
Wozu stat? tmpnam sagt dir, das es das gelieferte File irgendwann mal nicht gab. stat sagt dir nochmal das gleiche für einen etwas späteren aber auch lange vergangenen Zeitpunkt. Wenn stat kein File sieht, hast du keinen neuen Infos.
fragt bei Bedarf beim Anwender nochmal
meinst du mit "Bedarf": falls stat ein File entdeckt hat?
nach und öffnen dann die Datei zum schreiben. Ein Angreifer müsste nun das Zeitfenster zwischen tmpnam und stat ausnutzen, um die Nachfrage zu verhindern und mittels symlink eine andere Datei zu überschreiben.
Wenn ER schon vor dem stat den Link anlegt, merkst du es per stat - aber eben nur dann. Legt ER den Link erst nach dem stat an, hast du Pech gehabt. Das stat ist also letzlich sinnlos. Ohne stat hast als "Problemzeit" die Zeit zwischen tmpnam und open. Das ist der Standardfall.
Wichtig is dabei noch, daß der Angreifer gezielt in dem tmp-file lesen und schreiben kann.
Nun frage ich mich, ob es ein realistisches Angriffsszenario dafür gibt. Falls ja, würde das eine Menge Arbeit bedeuten...
Gibt es. Ein Beispiel: http://online.securityfocus.com/archive/1/197269 Dort wird zwar kein mktmp sondern sprintf(gname,"/tmp/ml85g%d",time(0)) als Filename genutzt, das Prinzip bleibt das gleiche: Die Namen sind vorhersagbar. Notfalls muß man raten. Irgendwann wird man einen Treffer haben.
ein Beipiel gehen mktemp-erzeugte Namen: http://www.cotse.com/texts/pop.txt
Schau mal bei google nach "tempfile exploit" usw. oder gleich auf Seiten mit Exploitsammlung (roostehhl.com,insecure.org?) Zeugs, was temporäre Files angreift gibts viel. Ein exploit speziell für von tmpnam erzeugte Filenamen habe ich nicht gefunden. Das wäre dann auf jeden fall plattformspezifisch. Sowas gibts aber bestimmt. Das mktemp-Bsp ist aber schon sehr nah an tmpnam dran. Wenn jemand die in deinem Programm verwendete Kombination entdeckt, bringt er jedenfalls einen Security-Patch raus. http://www.linuxsecurity.com/advisories/redhat_advisory-717.html
In http://www.tac.eu.org/cgi-bin/man-cgi?tmpnam+3 (netbsd-manpage) steht, daß frühere Systeme mit tmpnam gar nur 26 verschiedene Namen erzeugten. Bei Linux und Solaris sind es 6 Zeichen aus [A-Za-z0-0] variabel. Das sind ca. 56 Mrd. Varianten. Klingt viel, ist aber wahrscheilich nicht so superzufällig. Einfach oft genug versuchen :-)
Weiss jemand einigermassen sicher, ob tmpnam in der hier beschriebenen Art und Weise sicher oder unsicher benutzt wird?
Unsicher. Sich darauf zu verlassen, daß ein alter Zustand noch aktuell gültig ist, ist immer gefährlich. Die zwei Operationen Filetest und Fileerzeugung müssen zwingend atomar sein, also auch aus Programmierersicht in einem Aufruf erfolgen. Ein "Zwischendurchtest" wie in deinem Beispiel per stat macht es nicht sicher. mkstemp und tmpfile machen deshalb test und open in einem Abwasch.
Du schreibst, daß eine Änderung ein Menge Arbeit bedeuten würde. Warum eigentlich?
Reinhard
Am Donnerstag, dem 21. März 2002 um 13:35:27, schrieb Reinhard Foerster:
Ja. Wie einfach das ist hängt natürlich davon ab, wie vorhersagbar die generierten Dateinamen auf dem jeweiligen System sind.
Die glibc versucht das angeblich zu erschweren, aber unvorhersagbar werden sie sicher nicht:
$ cat tmpnam.cc; ./tmpnam #include <iostream> #include <cstdio> int main() { for(int i = 0; i < 20; i++) std::cout << tmpnam(0) << '\n'; return 0; }
/tmp/filerTUToi /tmp/fileqz2hTs /tmp/fileNn28nD /tmp/file8MteUN /tmp/filedYXErY /tmp/fileAieoS8 /tmp/filejOepkj /tmp/fileCORsNt /tmp/filebDyl7D /tmp/fileCfDGiO /tmp/filer6IjvY /tmp/fileqQUcJ8 /tmp/fileX3upYi /tmp/fileidgZ6s /tmp/file9K5AgD /tmp/filewJ2vrN /tmp/filen1dFuX /tmp/fileSVC8y7 /tmp/fileP8xDEh /tmp/fileCCCfKr
/dev/random wird definitiv nicht geöffnet.
Wozu stat? tmpnam sagt dir, das es das gelieferte File irgendwann mal nicht gab. stat sagt dir nochmal das gleiche für einen etwas späteren aber auch lange vergangenen Zeitpunkt. Wenn stat kein File sieht, hast du keinen neuen Infos.
Da hast du natürlich recht, stat dient wahrscheinlich nur dem Zweck, nicht temporäre Dateien nicht versehentlich zu überschreiben und wird nur 'aus Versehen' auch bei temporären Dateien aufgerufen.
Danke für die ganzen Links. Ich hatte nach tmpnam gesucht und wenig detaillierte Infos gefunden.
Du schreibst, daß eine Änderung ein Menge Arbeit bedeuten würde. Warum eigentlich?
Weil nicht nur das aktuelle Paket, sondern auch das potato-Paket gefixt und für alle Plattformen neu übersetzt werden muss. Naja, ich werde mich dem Schicksal fügen. ;-) Umstricken auf tmpfile sollte genügen.
Torsten
lug-dd@mailman.schlittermann.de
-
Reinhard Foerster -
Torsten Werner