.The-Wildcat.de

Gerade von der Arbeit nachhause gekommen, wollte ich jetzt eigentlich meine einzige stunde Freizeit etwas anders gestalten, aber nun gut . So viele fehlerhafte oder halbwahre Aussagen, da muss man etwas korrigieren.

Die Lücke besteht, wie bereits berichtet, in phpMyAdmin Versionen <= 2.11.9.0 und in den Versionen von phpMyAdmin 3. Da diese allerdings noch im RC status sind, sollten diese nirgends in Produktivumgebungen Verwendung finden.

Wo ist also das Problem?

Die Lücke findet sich in der Vorbereitung des Funktionsstrings für create_function, welche eine “on the fly” erzeugte Sortierfunktion bereitstellen soll.
In phpMyAdmin2 betrifft das Problem nur Umgebungen die MySql < 5 einsetzen oder die Option NaturalOrder gesetzt ist
/**
* apply limit and order manually now
* (caused by older MySQL < 5 or $GLOBALS['cfg']['NaturalOrder'])
*/

Wenn MySql5 im Einsatz ist, müsste in `information_schema`.`SCHEMATA`
eine Spalte vorhanden sein, die den gleichen Namen wie der Angriffsvektor hat.
Daher sollte der Angriff in diesem Fall auch fehlschlagen.

phpMyAdmin3

In phpMyAdmin3 wurde in Zeile 433 der database_interface.php, die Stelle an der entschieden wird ob information_schema genutzt wird oder nicht, nur die Option “DisableIS” geprüft. Das Problem an dieser Stelle ist, das die Option standardmäßig auf True gesetzt ist.
if (! $GLOBALS['cfg']['Server']['DisableIS']) {
Was in der Standardkonfiguration zu einem “falsch” ausgewertet wird und dazu führt das weiter unten im Code (Zeile 571) die NaturalOrder genutzt wird.

Man benötigt einen gültigen Account?

Dies ist wohl der interessanteste Teil für die meisten Nutzer. Ja es wird ein Account dafür benötigt oder der valide Sitzungstoken um es mittels CSRF ausnutzen zu können. Daher betrifft dieses Problem eher Shared-Hosting Anbieter und ähnliche und weniger Einzelumgebungen.

Hier und da kamen fragen auf, wenn man denn sowieso Zugang zu phpMyAdmin hat, warum ist das dann noch so schlimm?
Nun, die meisten Anbieter von Shared-Hosting u.ä. nutzen eine Instanz von phpMyAdmin für viele User und diese liegt auf einem extra Host/Virtual Host und die Nutzer dürfen dort i.d.R. keinen PHP-Code o.ä. ausführen.

Wie also schützen?

Wie unter anderem Heise berichtet, soll man die Funktion exec deaktivieren, damit man (sofern dies überhaupt erlaubt war) keine Shellbefehle absetzen kann. Nun, ehrlich gesagt ist das absolut sinnlos, da wären unter anderem noch backticks, shell_exec, system, fopen und php funktionen die nützliche Infos über das System liefern, Dateisystembefehle von php usw.

Ein einfaches print phpinfo() würde auch die phpinfo anzeigen. copy() um Dateien auf die der Webserver Zugriff hat zu kopieren und vieles mehr.

Wenn man disable_functions von php bemüht, sollte dies schon ca so aussehen:
disable_functions = symlink,pfsockopen,proc_open,proc_nice,proc_terminate,
proc_close,proc_get_status,shell_exec,exec,passthru,system,popen,highlight_file,diskfreespace,
disk_free_space,disk_total_space,show_source,php_uname,ini_alter,ini_restore,getrusage,get_current_user,
set_time_limit,getmyuid,getmypid,dl,leak,posix_getpwuid,posix_getgrgid

Zusammenfassend:

• Magic_Quotes muss deaktiviert sein
• < MySql5
• Betrifft eigentlich nur Massenhosting oder ähnliches
• Thanks to Marc Delisle for the nice conversation