PHP 4.4.6, 4.4.7, 4.4.8, …

Nach den Problemen mit PHP 4.4.5 wurde gestern die Version 4.4.6 freigegeben. Gleichzeitig startete aber auch der “Month of PHP Bugs” - ein Projekt einiger frustrierter Sicherheitsspezialisten. Die ersten Einträge existieren schon - mal schauen wie lange es dann bis zur Version 4.4.7, 4.4.8, 4.4.9, … braucht. ;-)

A propos… habe ich eigentlich schon erwähnt, daß ich (persönlich) PHP als Platform für “redistributable Applications” nicht zuletzt aus diesem Grunde für völlig ungeeignet halte? Als Hersteller einer PHP-Anwendung hätte ich Angst um die Lauffähigkeit meiner Anwendungen bei jedem einzelnen PHP-Update.

Klar, die C-Laufzeitumgebung ist auch nicht wirklich fehlerfrei, aber definitiv mit einer höheren Stabilität gesegnet als PHP.

14 Bemerkungen zu “PHP 4.4.6, 4.4.7, 4.4.8, …”

  1. Jürgen Jaritsch

    Alles eine Frage der Qualität ;) . Wer vernünftigen Source schreibt, der brauch sich nicht die geringsten Gedanken machen.

  2. Klaus Keppler

    100% ACK.
    Das Problem sehe ich nur darin, daß PHP seine Programmierer nicht richtig “erzieht”, sondern jeden noch so grottigen Code ausführt. Die meisten PHP-Programmierer schauen sich nicht einmal die PHP-Warnings an, sondern sind froh wenn’s läuft. Und SO einen Code sollte man wirklich nicht vertreiben. Da sind C/C++/Java/… einfach strenger. Noch schöner ist Python - da ist der Code auch überall halbwegs lesbar. :-)

  3. Jürgen Jaritsch

    “… sondern jeden noch so grottigen Code ausführt.”

    register_globals = Off
    register_long_arrays = Off
    error_reporting = E_ALL

    Zum einen wirst du viele vergraulen und zum anderen werden einige mit Entsetzen feststellen, welchen Quark sie da produziert haben - sehe ich immer wieder bei den Leuten die bei mir OSS verwenden (wollen). Aktuelles Beispiel: Drupal (die Baustelle) 5.

  4. Klaus Keppler

    Bei uns kann jeder Kunde diese Einstellungen individuell setzen; wer Wert auf ordentlichen Code legt wird nicht daran gehindert. Aber wie Du schon sagst - man muss nur mal schauen wie viele Programme ohne “register_globals=on” keinen Zuck mehr machen… :-(

  5. Jürgen Jaritsch

    “Bei uns kann jeder Kunde diese Einstellungen individuell setzen”

    Jup, bei mir auch. Sieht im Webadmin so aus: http://files.uttx.net/stuff_download/phpsettings.png

  6. Klaus Keppler

    Bei uns kann man übrigens PHP4 und PHP5 parallel nutzen; bei Dir sieht das so aus als ob man das über’s Webadmin auswählen muss…?

  7. Jürgen Jaritsch

    Korrekt. Simultanen Betrieb beider Versionen unter einem User-/Kunden-Host halte ich für wenig sinnvoll (für Tests mag das brauchbar sein, ja). Grundsätzlich muss sich der User entscheiden, welche Version er will - dafür setze ich auf mod_php.

  8. Klaus Keppler

    Bei uns ist das eher eine Nebenwirkung, weil ich bewusst nicht mod_php einsetze (primär aus Sicherheitsgründen). Für anspruchsvolle Kunden kommt mod_fastcgi mit PHP (CGI) zum Einsatz. Durch das ganze Caching im Server merkt man bei den meisten Sites ohnehin keinen Unterschied zwischen mod_php und CGI-PHP.

  9. Jürgen Jaritsch

    “(primär aus Sicherheitsgründen)”

    Irgendein konkretes Beispiel?

  10. Klaus Keppler

    Es gab in der Vergangenheit immer wieder gravierende Lücken, meist im Zusammenhang mit safe_mode/open_basedir usw. In meinen Bookmarks hatte ich spontan noch diese Meldung von Heise: http://www.heise.de/newsticker/meldung/71862 - ‘ne kleine Suche mit Google dürfte da sicher noch mehr bringen.

    Das Problem ist ja, daß bei mod_php User-Code unter den Rechten des Webservers ausgeführt wird. Wenn man beispielsweise nicht komplett exec() verbieten will, ist spätestens hier auf jedem zweiten Linux-System über noch ganz andere Fehler (libc, Kernel, …) ein Einstieg möglich.

    Wenn PHP als CGI unter den jeweiligen Userrechten läuft, kann ich die User schon auf Betriebssystemebene (über Datei-/Verzeichnisrechte) schön sauber voneinander trennen und brauche nie Angst vor dem nächsten safe_mode/…-Bug haben. Beispielsweise könnte kein Kunde mit SSH-Zugriff in irgendwelche anderen Verzeichnisse gucken, auch ohne für jeden eine einzelne chroot-Jail bereitzustellen.

  11. Klaus Keppler

    Ach ja… nicht zuletzt braucht es in diesem Setup nie wieder irgendwelche “world writable”-Dateien oder Verzeichnisse; Mode 0700/0600 reicht für alle Fälle :)

  12. Jürgen Jaritsch

    >> http://www.heise.de/newsticker/meldung/71862

    Die von dir erwähnten Lücken sind nicht von der Hand zuweisen - mit einem vernünftigen Setup jedoch keine Gefährdung.

    >> Das Problem ist ja, daß bei mod_php User-Code unter den Rechten des Webservers ausgeführt wird.

    mod_suid

    >> Wenn man beispielsweise nicht komplett exec() verbieten will, ist spätestens hier auf jedem zweiten Linux-System über noch ganz andere Fehler (libc, Kernel, …) ein Einstieg möglich.

    Reißleine jail/chroot/vm

    >> Wenn PHP als CGI unter den jeweiligen Userrechten läuft, kann ich die User schon auf Betriebssystemebene (über Datei-/Verzeichnisrechte) schön sauber voneinander trennen und brauche nie Angst vor dem nächsten safe_mode/…-Bug haben.

    Darüber mach ich mir auch wenig Gedanken - alles eine Frage der Recht, wie du bereits geschrieben hast.

    >> Beispielsweise könnte kein Kunde mit SSH-Zugriff in irgendwelche anderen Verzeichnisse gucken, auch ohne für jeden eine einzelne chroot-Jail bereitzustellen.

    Auch wenn ich kein SSH bei uttx.net anbiete: jeder User ist in seinem dir eingesperrt.

    >> Ach ja… nicht zuletzt braucht es in diesem Setup nie wieder irgendwelche “world writable”-Dateien oder Verzeichnisse; Mode 0700/0600 reicht für alle Fälle

    Darüber macht man sich bei keinen vernünftigem Setup Gedanken (sofern nicht unbedingt CGI/Perl im Einsatz ist). Bei meinem FTP-Setup ist FTP-UId = UserId = PHP-UId. Ergo: Geschichten wie 0777 und Co sind für die Tonne *hust* ;) .

  13. Klaus Keppler

    Klingt doch auch nach einem durchdachten Setup. :-)

    Ich hatte mod_suid nur mal kurz angeschaut, im Vergleich zu unserer Eigenentwicklung sah ich aber nicht wirklich einen Vorteil darin (im Gegenteil… bei uns kann ich auch noch pro vhost die Systemressourcen (Filehandles, CPU-Time, Speicher, …) festlegen).

    Fazit ist doch aber, daß es (auf welche Art auch immer) auf eine gut überlegte Lösung ankommt, bei der User-Scripte immer unter der ID des tatsächlichen Betriebssystem-Nutzers ausgeführt werden. :-)

  14. Jürgen Jaritsch

    Viel mehr als “FULL ACK” lässt sich da nicht mehr sagen ;) .

Einen Kommentar schreiben