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.
Am 2. März 2007 um 12:58 Uhr
Alles eine Frage der Qualität
. Wer vernünftigen Source schreibt, der brauch sich nicht die geringsten Gedanken machen.
Am 2. März 2007 um 13:10 Uhr
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.
Am 2. März 2007 um 17:58 Uhr
“… 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.
Am 2. März 2007 um 18:06 Uhr
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…
Am 2. März 2007 um 20:28 Uhr
“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
Am 2. März 2007 um 22:59 Uhr
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…?
Am 3. März 2007 um 00:40 Uhr
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.
Am 3. März 2007 um 11:36 Uhr
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.
Am 3. März 2007 um 12:58 Uhr
“(primär aus Sicherheitsgründen)”
Irgendein konkretes Beispiel?
Am 3. März 2007 um 18:52 Uhr
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.
Am 3. März 2007 um 18:54 Uhr
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
Am 3. März 2007 um 21:41 Uhr
>> 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*
.
Am 4. März 2007 um 11:27 Uhr
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.
Am 4. März 2007 um 13:05 Uhr
Viel mehr als “FULL ACK” lässt sich da nicht mehr sagen
.