Haltet eure PHP-Software aktuell!

[Christian Kruse]

你好 Andreas,

?? Andreas,

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

Installiere dir entsprechende Schriften :)

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.

Und es wäre schwerer, wenn man eine eigene Funktionsgruppe dazu einführt?
Ne, sorry, aber das will mir nicht einleuchten, das halte ich für groben
Unfug.

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.

Richtig. Wie ich bereits sagte: Risiko-Faktoren minimieren.

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.

Aber vorhanden.

Ich finde den Gedanken gut dass User nicht Daten anderer User
manipulieren können,

Das geht bei uns auch nicht :) open_basedir ist pro vhost gesetzt.

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.

“Und das ist auch gut so”[tm] ;-)

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!

Nein, das ist auf einem Multi-User-Server so ohne weiteres nicht vermeidbar.
Nicht wgen der Technik, sondern wegen der User. “Geht nicht? Access
denied? Arg! *chmod 777*”.

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.

Naja, nicht wirklich. Wenn man mit suexec arbeitet, kann man das Problem
schon weitestgehend umgehen.

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?

Jop. Siehe suexec ;-)

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?

Auf Passwort-Dateien braucht der Apache bei suexec keinen Zugriff. Warum
auch? Man greift ja mit Benutzer-Rechten zu.

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.

Jo, grsec ist nicht verkehrt.

再见,
克里斯蒂安