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

Wie im letzten Beitrag versprochen, gibt es eine neue Version des Ruby on Rails Howtos für 1&1 Homepage-Server. Jetzt noch besser, größer und schneller.

Neu hinzugekommen ist u. a. die Installation von Thin sowie 2 Beispielanwendungen namens Tracks und Redmine.

Das aktualisierte Howto ist weiterhin unter der bekannten URL zu finden. Kommentare, Anregungen usw. wie immer in den Kommentaren zu diesem Blogeintrag.

Diesmal ist die nächste Version des Ruby on Rails Howtos schon 6 Monaten nach der letzten Aktualisierung fällig geworden. Die einzelnen Änderungen können im Changelog nachvollzogen werden. Die nächste Version wird voraussichtlich nach der Veröffentlichung von Rails 2.0 fällig werden.

Zu finden ist das aktualisierte Howto wie bisher unter http://schalanda.name/static/rails_on_rtr/rails_on_rtr.html.

Anmerkungen, Fehlermeldungen usw. können hier im Blog als Kommentare zu diesem Beitrag verfasst werden.