Haltet eure PHP-Software aktuell!

[Andreas Korthaus]

Hallo Christian!

?? Andreas,

so langsam würde ich ja schon gerne mal sehen was da an Stelle der Fragezeichen stehen müsste ;-)

Hauptverursacher ist eine konzeptionelle Schwäche in PHP.

Die da wäre?

Das transparente Verwischen von Datei- und Netzwerk-Zugriffen.

So schlecht finde ich die Idee nicht. Es bietet die Möglichkeit sehr einfach Dateien von einem auf den anderen Server zu übertragen. Sicher sind auf der Transport-Schicht dazwischen keine "Dateien" bekannt, aber an den beiden Endpunkten der Kommunikation normalerweise schon.

Das Problem ist dass man es IMHO zu unvorsichtig aktiviert hat, die DAUs waren begeistert, und heute benutzen das so viele Scripte, dass man es kaum noch abschalten kann - obwohl die Argumente dafür immer zwingender werden.

IMHO war es der größte Fehler, dass auf die zusätzliche Gefahr der diese Funktionen aufgrund von allow_url_fopen ausgesetzt sind, nicht wikrlich eindringlich hingewiesen wurde. Leider sagen viele PHP-Devs, "sollen die Admins/Programmier sich doch bitte drum kümmern, die müssen das selber einschätzen können, die müssen selber wissen was sie machen, wir können nicht verhindern dass sich die Leute reihenweise in die Füße schießen...".

Einmal nicht aufgepasst und schon machts krach-bumm.

Eigentlich ist das Problem dasselbe wie lokal (ohne allow_url_fopen), mit dem kleinen aber feinen Unterschied, dass die Auswirkungen erheblich verheerender sind.

IMHO sollten User nur Prozesse unter eigener UID laufen lassen können
(suexec/suphp für CGI),

Das sagst du so. Das führt dazu, dass PHP einige Unterschiede zur
(normalerweise installierten) Modul-Version aufweist.

Die Unterschiede sind doch wohl marginal. Eigentlich betrifft es ja nur HTTP-Header Geschichten. Der wichtigste (Location) funktioniert ganz normal, das einzige was halt wirklich fehlt ist HTTP-Auth. Aber das wird so häufig auch nicht verwendet. Abgesehen davon setzen alle großen Provider die ich kenne php-cgi ein (domainfactory, 1&1, Schlund, AFAIR auch hosteurope und strato), also scheint das auch irgendwie zu gehen. Ich habe normalen Webspace bisher noch nie mit mod_php gehabt, und das finde ich aus heutiger Sicht auch sehr sinnvoll.

Ich finde den Gedanken gut dass User nicht Daten anderer User manipulieren können, so bleiben solche Fehltritte wie in deinem Fall wenigstens auf den einen User beschränkt, das heißt, der Angreifer kann mit dem Account machen was er will, aber er kann nicht auf Daten anderer User zugreifen.

Besonders wild wirds doch bei mod_php wenn der Webserver in ein Verzeichnis schreiben soll (upload -> chmod(0777) usw.).

entsprechend sollen User nur die Programme auf der Kommandozeile
ausführen können, die sie evtl. benötigen, alles andere nach Möglichkeit
entfernen, oder wenigstens chmod (0700).

Das hätte in diesem Fall auch nichts geholfen.

Ich dachte er hätte den Kram mit wget runtergeladen?

Aber OK, er hätte den Kram vermutlich auch Zeile für Zeile mit echo in eine lokale Datei schreiben können...

Perl zu verbieten ist...
naja, leicht lächerlich ;-)

klar.

Da hilft nur eine vernünftige Administration,
der Angreifer konnte ja nichts ausrichten, er hatte “nur” Apache-Rechte.

Er hat es immerhin geschafft dass der Webserver offline war. Wenn auch nicht absichtlich. Er hätte auf die Daten aller Kunden Zugriff, könnte alle DB-Zugangsdaten auslesen und wer weiß was noch alles. IMHO sollte eine gute Konfiguration sowas vermeiden! Das System muss komplett auf aktuellem Stand sein, denn es reicht ein kleine Lücke im Kernel oder einem Programm was unter root läuft, und schon hat er selber root und kann machen was er will.

Was ich bisher aber nicht wüßte wie ich es vermeide, ist es z.B. DB-Zugangsdaten in Scripten (anderer Kunden) vor so einem Angreifer zu schützen. Solange der Webserver diese Zugangsdaten lesen kann, kann der Angreifer das auch. Man kann zwar ein Directory-Listing verhindern, dass er nicht sofort sieht wo die anderen Kundendaten liegen, aber darauf würde ich mich jetzt eher nicht verlassen wollen. Man kann auch verhindern dass er in der Shell auf andere Kunden-Verzeichnisse zugreift - aber kann man auch verhindern dass er mit dem Apachen zugreift? Ich meine - angenommen ich kenne das Verzeichnis anderer Kunden, was hält mich davon ab per .htaccess und z.B. Alias mal ein bisschen in den Verzeichnissen zu stöbern, und mit Dateien dort als text/plain ausliefern zu lassen?

Und der darf nicht sonderlich viel... wenn man mit ACLs arbeitet, kann
man da sehr viel recht schön einschränken.

OK, ACLs, sicher nicht verkehrt. Ich verwende noch das grsec-patch (proaktive Sicherheit gegen gewissen Angriffe, PAX...), gibts bei Gentoo als grsec-sources. Hat den Vortei, dass einige Exploits (nicht alle) auf so einem System nicht funktionieren.

Allerdings betreue ich keine Server mit fremden Usern und habe da
möglicherweise gut Reden ;-)

Ja ;-)

Also ich hätte jetzt gedacht mod_php auf Hosting-Servern sei inzwischen mehr oder weniger ausgestorben ;-)

Grüße
Andreas