mod_php considered harmful
Dass das Akronym PHP ab und zu auch für "Pretty Hard to Protect" stehen kann, ist sicherlich nichts Neues. Eine Sprache die leicht zu erlernen ist und deren Laufzeitumgebung bei jedem Feld, Wald und Wiesenprovider installiert ist, zieht nun einmal auch Leute an, die normalerweise nicht programmieren würden (oder sollten) und sich über Sicherheit nicht den Kopf zerbrechen. Es gibt also jede Menge schlechter PHP-Skripte. Das ist sicherlich nicht die Schuld der PHP-Macher.
Aber manchmal frage ich mich ernsthaft, ob ein Abschied von PHP vielleicht sinnvoll wäre. Die letzten Tage ist mal wieder ein schon etwas älterer Bug von PHP an die Oberfläche des Interwebs gespült worden.
Beim Einsatz als Apache-Modul werden vor dem Aufruf des PHP-Interpreters nicht alle Dateideskriptoren aufgeräumt, die der Apache httpd geöffnet hat. Dadurch kann über ein normales PHP-Skript sowie ein unterstützendes Binary (oder ggf. Skript, wenn der Interpreter die entsprechenden Systemaufrufe unterstützt) der Apache-Prozess verdrängt bzw. ersetzt werden.
Ein bösartiges Skript kann dadurch an Stelle des Apache httpd Daten an Besucher ausliefern und so bspw. Malware verbreiten, Passwörter abgreifen usw.
Man erhält dadurch zwar keine Rootrechte (zumindest nicht trivial), aber die Möglichkeit den Webserver abzuschießen und durch einen eigenen Prozess zu ersetzen ist schlimm genug. Betroffen sind scheinbar alle Versionen von PHP.
Was das ganz noch viel schlimmer macht, ist die Tatsache, dass alle Wohnzimmerhoster (no offense ;), die Plesk und vergleichbare Pakete benutzen, die auf mod_php setzen, von der Problematik betroffen sind, es aber vermutlich nicht wissen und niemals erfahren werden. Irgendwann sind die Server einfach einmal gekapert und liefern munter Malware aus. Zumindest bei Plesk ist die Nutzung von PHP als Apache-Modul obligatorisch. Andere Modi werden nicht unterstützt.
Um das Problem zu umgehen, bieten sich neben den offensichtlichen Vorschlägen PHP zu deinstallieren oder den Apache httpd durch eine Alternative wie lighttpd oder nignx zu ersetzen, folgende Möglichkeiten an, die möglichst kombiniert werden sollten:
1) PHP über die CGI-Schnittstelle, SuPHP oder FastCGI mit SuExec einbinden.
2) Funktionen wie system, passthru usw. mit disable_functions verbieten.
3) open_basedir Restrictions korrekt setzen.
4) Die Partition mit den PHP-Skripten mit dem Parameter noexec mounten.
Verweise:
Bug #20302 Leaked Descriptors
Bug #38915 Apache: system() (and similar) don't cleanup opened handles of Apache
http://hackerdom.ru/~dimmo/phpexpl.c
Hijacking Apache https by mod_php
Apache mit mod_php übernehmen
via Fefe
Aber manchmal frage ich mich ernsthaft, ob ein Abschied von PHP vielleicht sinnvoll wäre. Die letzten Tage ist mal wieder ein schon etwas älterer Bug von PHP an die Oberfläche des Interwebs gespült worden.
Beim Einsatz als Apache-Modul werden vor dem Aufruf des PHP-Interpreters nicht alle Dateideskriptoren aufgeräumt, die der Apache httpd geöffnet hat. Dadurch kann über ein normales PHP-Skript sowie ein unterstützendes Binary (oder ggf. Skript, wenn der Interpreter die entsprechenden Systemaufrufe unterstützt) der Apache-Prozess verdrängt bzw. ersetzt werden.
Ein bösartiges Skript kann dadurch an Stelle des Apache httpd Daten an Besucher ausliefern und so bspw. Malware verbreiten, Passwörter abgreifen usw.
Man erhält dadurch zwar keine Rootrechte (zumindest nicht trivial), aber die Möglichkeit den Webserver abzuschießen und durch einen eigenen Prozess zu ersetzen ist schlimm genug. Betroffen sind scheinbar alle Versionen von PHP.
Was das ganz noch viel schlimmer macht, ist die Tatsache, dass alle Wohnzimmerhoster (no offense ;), die Plesk und vergleichbare Pakete benutzen, die auf mod_php setzen, von der Problematik betroffen sind, es aber vermutlich nicht wissen und niemals erfahren werden. Irgendwann sind die Server einfach einmal gekapert und liefern munter Malware aus. Zumindest bei Plesk ist die Nutzung von PHP als Apache-Modul obligatorisch. Andere Modi werden nicht unterstützt.
Um das Problem zu umgehen, bieten sich neben den offensichtlichen Vorschlägen PHP zu deinstallieren oder den Apache httpd durch eine Alternative wie lighttpd oder nignx zu ersetzen, folgende Möglichkeiten an, die möglichst kombiniert werden sollten:
1) PHP über die CGI-Schnittstelle, SuPHP oder FastCGI mit SuExec einbinden.
2) Funktionen wie system, passthru usw. mit disable_functions verbieten.
3) open_basedir Restrictions korrekt setzen.
4) Die Partition mit den PHP-Skripten mit dem Parameter noexec mounten.
Verweise:
Bug #20302 Leaked Descriptors
Bug #38915 Apache: system() (and similar) don't cleanup opened handles of Apache
http://hackerdom.ru/~dimmo/phpexpl.c
Hijacking Apache https by mod_php
Apache mit mod_php übernehmen
via Fefe
