mod php5
- Thread starter Kato
- Start date
Lord Gurke
Nur echt mit 32 Zähnen
PHP3 ist so schweinealt, dass einige damals verwendete Befehle heute garnicht mehr existent sind oder sich anders verhalten.
Und das Wichtigste: Die damalige Auffassung von Objektorientierung war eine deutlich andere als die, die mit PHP4 eingeführt wurde.
Ohne diese Abwärtskompatibilität könntest du tatsächlich reine .php3-Scripte nicht mehr ausführen.
Zusätzlich kommt noch hinzu, dass es wohl damals schick war, die Erweiterung .php3 zu verwenden.
Und das Wichtigste: Die damalige Auffassung von Objektorientierung war eine deutlich andere als die, die mit PHP4 eingeführt wurde.
Ohne diese Abwärtskompatibilität könntest du tatsächlich reine .php3-Scripte nicht mehr ausführen.
Zusätzlich kommt noch hinzu, dass es wohl damals schick war, die Erweiterung .php3 zu verwenden.
Wenn php3 so alt ist, dass es nur noch ausnahmsweise benötigt wird, dann sollte es auch nur ausnahmsweise ausgeführt werden. Wenn ich auf einem Server php5 installiere und eigentlich nur die Ausführung von php5 erlauben will, dann ist es etwas überraschend, dass php3 bei der Installation von php5 einfach so als ausführbar konfiguriert wird. Das finde ich sicherheitstechnisch etwas zuviel an Abwärtskompatibilität.
Lord Gurke
Nur echt mit 32 Zähnen
Es ist ja keine Sicherheitslücke - auch wenn es so alt ist!
Du glaubst garnicht, wie viele Unternehmen noch PHP3-Scripte einsetzen. Einfach nur, weil es einfach viel zu aufwändig (=teuer) ist, die Scripte PHP5-Kompatibel zu machen.
Ganz abgesehen davon, ist das vor allem abhängig von der eingesetzten Distribution. Wenn du dir PHP als Source herunterlädst und selbst kompilierst und einrichtest, entscheidest du das ja selbst
Du glaubst garnicht, wie viele Unternehmen noch PHP3-Scripte einsetzen. Einfach nur, weil es einfach viel zu aufwändig (=teuer) ist, die Scripte PHP5-Kompatibel zu machen.
Ganz abgesehen davon, ist das vor allem abhängig von der eingesetzten Distribution. Wenn du dir PHP als Source herunterlädst und selbst kompilierst und einrichtest, entscheidest du das ja selbst
Wenn ich mir meine php5.conf ansehe bin ich trotzdem noch überrascht:
AddType application/x-httpd-php .php .phtml .php3
Da steht z.B. nichts von .php4 oder .php5. Das verstehe ich auch irgendwie nicht. php3 Skripte werden an den den PHP Interpreter geschickt. php4 und php5 Skripte nicht.
Das kann dann schon sicherheitskritisch werden, wie z.B. in einem solchen Fall: http://blog.benny-baumann.de/?p=415
Wenn man z.B. über eine solche Schnittstelle verbietet php und php5 Dateien hochzuladen. Nun lädt jemand eine php3 Datei hoch und der Apache führt sie aus, dann gute Nacht.
Deswegen finde ich das eben überraschend. Wenn .php5 und .php4 Dateien in der conf ebenfalls stehen würden, dann könnte man ja annehmen, dass einfach alle alten und aktuellen PHP-Versionen an den Interpreter geschickt werden. So werden aber seltsamerweise nur php3 explizit an den Interpreter geschickt. Und dass obwohl php5 installiert ist. Das hätte ich eben so nicht erwartet.
Ich wette es finden sich eine Menge Webseiten, die irgendwie einen Upload anbieten, wo man genau dies ausnutzen könnte um Schadcode auszuführen. (Ohne dass ich hier nun eine Anleitung geben will, ich will ein mögliches Problem aufzeigen)
AddType application/x-httpd-php .php .phtml .php3
Da steht z.B. nichts von .php4 oder .php5. Das verstehe ich auch irgendwie nicht. php3 Skripte werden an den den PHP Interpreter geschickt. php4 und php5 Skripte nicht.
Das kann dann schon sicherheitskritisch werden, wie z.B. in einem solchen Fall: http://blog.benny-baumann.de/?p=415
Wenn man z.B. über eine solche Schnittstelle verbietet php und php5 Dateien hochzuladen. Nun lädt jemand eine php3 Datei hoch und der Apache führt sie aus, dann gute Nacht.
Deswegen finde ich das eben überraschend. Wenn .php5 und .php4 Dateien in der conf ebenfalls stehen würden, dann könnte man ja annehmen, dass einfach alle alten und aktuellen PHP-Versionen an den Interpreter geschickt werden. So werden aber seltsamerweise nur php3 explizit an den Interpreter geschickt. Und dass obwohl php5 installiert ist. Das hätte ich eben so nicht erwartet.
Ich wette es finden sich eine Menge Webseiten, die irgendwie einen Upload anbieten, wo man genau dies ausnutzen könnte um Schadcode auszuführen. (Ohne dass ich hier nun eine Anleitung geben will, ich will ein mögliches Problem aufzeigen)
Lord Gurke
Nur echt mit 32 Zähnen
Wie gesagt, es scheint damals schick gewesen zu sein, die Dateien mit der Erweiterung .php3 zu versehen.
Ich habe auch schon aus unserem SVN Projekte ausgecheckt, die seit bestimmt 8-9 Jahren nicht mehr angefasst wurden und die Dateien haben alle die Erweiterung .php3.
Die Erweiterung .php4 und .php5 kannst du genauso hinzufügen - einige Massenhoster haben das damals auch gemacht, weil viele Scripte unter PHP4 zwar liefen, unter PHP5 aber nicht, weil ein paar Befehle entfernt wurden. Wenn man das entsprechend konfiguriert, kann man also PHP3, PHP4 und PHP5 gleichzeitig auch einem System laufen lassen. Und das ist dabei kein erhöhtes Sicherheitsrisiko!
Wie der Blogger schon schrieb, reicht es aber generell tatsächlich aus, die PHP-Engine über die Konfiguration abzuschalten.
Das Entfernen der Handler ist dabei dann eigentlich optional und hat bloß den Effekt, dass die Datei nicht mehr als Text direkt im Browser angezeigt, sondern zum Download angeboten wird.
Naja, ich weiß nicht so recht....
Wie ich das sehe, verhindert die vorgestellte Konfiguration, dass generell garkeine PHP-Dateien in einem bestimmten Verzeichnis mehr interpretiert werden - weil man sie zum Download anbieten will.
Die Datei einfach mit .txt oder .phps-Erweiterung zu versehen, scheint da wohl zu kompliziert zu sein...
Ja, .phps ist auch in den meisten Fällen standardmäßig konfiguriert und gibt den Quelltext der Datei mit farblich markiertem Code aus.
Hochgeladene Dateien mit dem Webserver direkt ausliefern zu lassen klingt für mich ohnehin schon ein bisschen nach "Broken By Design"
Außerdem musste er dafür ohnehin eine Sicherheitsfunktion seiner Blogsoftware außer Kraft setzen...
Sorry, da liegt der Bug ganz klar in der Schnittstelle zum Upload.Wenn man z.B. über eine solche Schnittstelle verbietet php und php5 Dateien hochzuladen. Nun lädt jemand eine php3 Datei hoch und der Apache führt sie aus, dann gute Nacht.
Ich bestimme z.B. nicht anhand der Erweiterung, sondern anhand des MIME-Types, was mir auf die Platte kommt und was nicht.
Und wenn ich sage, der Typ "text/x-php" wird nicht akzeptiert, dann wird der nicht akzeptiert - auch wenn die Datei trallala.jpg heißt
Außerdem sollte man generell eigentlich keine Daten, die fremde Benutzer hochladen können, direkt über den Webserver sondern über ein Script ausliefern, welches die Datei einliest und dem Besucher dann durchreicht.
Mag etwas an Performance verlieren, aber wenn ich so viele Besucher habe, dass es dadurch spürbar langsam wird, kann ich ja immer noch einen nackten lighttpd nur für diese Dateien einsetzen, der nicht für die Ausführung irgendwelcher Scripte konfiguriert ist.
Es gab damals auch einen großartigen Bug in fast allen Browsern, die JavaScript aus manipulierten GIF-Dateien ausgeführt haben.
Wenn man diese GIF-Datei z.B. in einem Forum als Avatar hochlud, konnte man damit prima alle Cookies für die Domain des Forums auslesen und sich damit zumindest teilweise Admin-Rechte verschaffen.
Last edited by a moderator:
Sorry, da liegt der Bug ganz klar in der Schnittstelle zum Upload.
Ich bestimme z.B. nicht anhand der Erweiterung, sondern anhand des MIME-Types, was mir auf die Platte kommt und was nicht.
Und wenn ich sage, der Typ "text/x-php" wird nicht akzeptiert, dann wird der nicht akzeptiert - auch wenn die Datei trallala.jpg heißt
Außerdem sollte man generell eigentlich keine Daten, die fremde Benutzer hochladen können, direkt über den Webserver sondern über ein Script ausliefern, welches die Datei einliest und dem Besucher dann durchreicht.
Full ack.
