phpBB.de

hat vielleicht jemand phpbb mit allow_url_fopen=off im einsatz? normalerweise sollte ja eigentlich nirgendwo im plain vanilla die funktionalität gebraucht werden, von daher könnte man durch deaktivierung innerhalb der php.ini (soweit man zugriff hat) das risiko einer remote-code-injektion damit wahrscheinlich deutlich verringern...

Stellt sich nur die Frage, wieviele vermeintlich tolle Mods plötzlich nicht mehr funktionieren, weil der Modder über file oder fopen externe Dateien abfragen. Wie Du schon sagtest, sollte es für das vanilla phpBB keine Probleme erzeugen.

Grüße,
Tekin

Stellt sich nur die Frage, wieviele vermeintlich tolle Mods plötzlich nicht mehr funktionieren, weil der Modder über file oder fopen externe Dateien abfragen.

ehrlich gesagt wäre es mir nur recht, wenn diese mods allesamt nicht mehr funktionieren würden - remote-code injektionen entwickeln sich - nicht zuletzt 'dank' der letzen kernel exploits zu einem schwerwiegenden sicherheitsproblem - oder wie bei zone-h so nett beschrieben

On the linux side we see the recent PRCTL vulnerability and the race condition 0day kernel exploits. As I eluded to in a past article , combining a local root exploit, considered a simple low impact vulnerability [ as classified by some vendors ] with a web application vulnerability, they now becomes a remote root kernel compromise, a form of privilege escalation. If the thought of php, perl and scripting based worms scares you [ remember SANTY.A ], think of it now as a super worm capable of breaking into whole hosting computers, hosting possibly 1000's of sites, instead of being confined to a single vhost on a server.

mir geht es mehr darum, ein möglichst sicheres enviroment zu schaffen...

larsneo hat geschrieben:mir geht es mehr darum, ein möglichst sicheres enviroment zu schaffen...

100% Agreed
Du siehst es so. Ich sehe es so. Manch ein anderer sieht es bestimmt auch so. Das Gros der Menschen wäre jedoch leider zu bequem um all die Mods, die über fopen und file auf externe Dateien zugreifen, um zu programmieren. Dem Modder ist es zuviel Arbeit, zumal er z.B. nicht mehr einfach mit file_get_contents arbeiten kann und all die, die solche Mods schon eingebaut haben, wären zum Großteil zu müßig um wieder ein Update zu installieren. (Leider traurige Realität. Man muss nur schauen, wieviele "uralte" phpBB's es noch auf der Welt gibt. "Mich wird es schon nicht treffen."-Mentalität)

Zudem stellt sich die Frage, welcher Teil der Nutzerschaft überhaupt die Möglichkeit besitzt, entweder über php.ini oder .htaccess das allow_url_fopen abzustellen. Nur wenige besitzen einen eigenen (Virtual-)Root-Server.

Zudem stellt sich die Frage, welcher Teil der Nutzerschaft überhaupt die Möglichkeit besitzt, entweder über php.ini oder .htaccess das allow_url_fopen abzustellen. Nur wenige besitzen einen eigenen (Virtual-)Root-Server.

naja - es gibt sicherlich ein paar (mich eingeschlossen), die das forum durchaus im kommerziellen umfeld einsetzen und von daher vielleicht etwas anders an die geschichte herangehen...
ich würde von daher eine zusammenstellung der 'optimalen' settings begrüssen - für mein eigentliches baby habe ich so etwas einmal *hier* zusammengestellt.
alleine schon die register_globals geschichte hat in der vergangenheit gezeigt, mit welch einfachen mitteln man die applikationssicherheit erhöhen kann - von modsecurity etc. einmal gar nicht zu reden...

larsneo hat geschrieben:hat vielleicht jemand phpbb mit allow_url_fopen=off im einsatz?

Nur ein internes an dem ich z.Z. arbeite.

nachtrag:
zwischenzeitlich habe ich das nuforum (inklusive galerie und ein paar weiteren zusatzmodulen) problemlos auf den allow_url_fopen=off betrieb umstellen können. zusätzlich verrichtet übrigens auch noch suhosin klaglos seine dienste, um php://input bzw. data:// injektionen zu unterbinden.
tschüss remote code injection

larsneo hat geschrieben:nachtrag:
zwischenzeitlich habe ich das nuforum (inklusive galerie und ein paar weiteren zusatzmodulen) problemlos auf den allow_url_fopen=off betrieb umstellen können. zusätzlich verrichtet übrigens auch noch suhosin klaglos seine dienste, um php://input bzw. data:// injektionen zu unterbinden.
tschüss remote code injection

Hallo larsneo,

was mußtest Du denn alles umstellen?

Gruß
kird1