Sicherheitsupdate für PHP bei CGI-Verwendung
Gestern wurden neue Versionen für PHP 5.4 und 5.3 released, namendlich: 5.4.2 und 5.3.12. Grund für diese neuen Versionen ist eine gravierende Sicherheitslücke bei der Verwendung von PHP im CGI-Modus.
Aber erstmal Entwarnung: Wahrscheinlich nutzt ihr kein CGI mehr sondern FastCGI oder mod_php, dann seid ihr nicht gefährdet. Wer aber noch auf die alte CGI-Schnittstelle setzt sollte sich schleunigst informieren und updaten um schlimmeres zu vermeiden, denn dank dieser leicht auszunutzenden Lücke ist es jedermann möglich, die Quelltexte euer PHP-Dateien im Document-Root anzuschauen oder auch beliebigen eingeschleusten PHP-Code auszuführen.
Wer seine alte Installation nicht anfassen darf oder kann, für den gibt es Hilfe in Form einer Rewrite-Regel:
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]
Weitere Informationen befinden sich auf der Seite des US-CERT, viele Details bei den Findern der Lücke, im Bugtracker oder natürlich bei Heise im Forum 😉
Achso, interessanterweise hat Stefan Esser folgendes getweetet:
@i0n1c: The security emergency release to fix the PHP CGI RCE (that was tested for days…) does not fix anything at all.
Wir dürfen also gespannt sein ob er Recht behält. Man mag ihn mögen oder hassen, aber von Sicherheit im PHP-Bereich versteht er einiges. Wir werden es erleben…
Edit: Auf der Seite der Hacker befinden sich folgende Sätze:
The new PHP release is buggy. You can use their mitigation mod_rewrite rule, but the patch and new released versions do not fix the problem. At the bottom we have added a version of the PHP patch that fixes the obvious problem with the patch merged in the recently released security update.
Vielleicht wäre es hilfreich wenn sich die 3 Parteien zusammensetzen und einen funktionierenden Patch entwickeln und veröffentlich? So ist’s etwas peinlich…
Mein Eindruck ist immer, dass viel Show darum gemacht wird, bloß um zu „beweisen“, wie unterentwickelt der PHP-Code ist. Gefühlt werden Korrekturen von Sicherheitsbugs bewusst verzögert, nur um im Recht zu bleiben.
Speziell Herr Esser wirkt oft genug so, als ob er sich mehr ein Spaß aus solchen Vorfällen macht, als wirklich an eine Fehlerbehebung interessiert zu sein…
KingCrunch
4 Mai 12 at 10:31
Nachtrag: ok, DAS find ich dann auch ein ganz klein wenig witzig 😀 Ausgerechnet Facebook, von denen immer nachgesagt wird mit deren HipHop-Compiler seien sie vor den üblichen PHP-Firlefanz absolut sicher.
https://www.facebook.com/?-s
KingCrunch
4 Mai 12 at 10:49
KingCrunch: Hab auch erst gedacht, dass das peinlich für Facebook ist. Aber wenn man mal die URL öffnet die per include drin steht, landet man auf einer Job-Seite. Dort kann man sich dann als „Security Engineer“ bewerben.
Ich denke sie haben aus dem „Bug“ das beste rausgeholt 😛
Florian
4 Mai 12 at 13:00
Ich seh’s da ähnlich wie KingCrunch. Viel Wirbel um „nichts“. Hab bei mir selbst und bei vielen bekannten mal den Bug ausprobiert. Nichts… ich denke bei den wenigsten läuft php im CGI modus.
Ich denke das ist so ähnlich wie mit Atomkraftwerken. Wenn was passiert, dann aber richtig.
T-Rex
7 Mai 12 at 14:53
@T-Rex
Aber nicht, dass die Bundesregierung dann auch noch den Aussstieg aus PHP bis 2022 beschließt ^^ :-p
Quetschi
7 Mai 12 at 15:40
@T-Rex: Facebook verwendet kompiliertes PHP, das nennt sich dann HipHop.
@all: Da der Patch ja durch den Zeitdruck auch wieder nur halbherzig war, wird Morgen nachgelegt und die (hoffentlich) vollständige Korrektur released.
Die oben genannte Rewrite-Rule wurde mittlerweile auch korrigiert, da nicht alle Fälle abgedeckt wurden.
Quelle: http://www.php.net/archive/2012.php#id2012-05-06-1
Guido
7 Mai 12 at 19:57