full-disclosure - securing php

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20030820104806.GA16208@p15104972.pureserver.info>
From: kris at koehntopp.de (Kristian Koehntopp)
Subject: securing php

On Wed, Aug 20, 2003 at 10:12:30AM +0200, vogt@...senet.com wrote:
> You an enable PHP's "Safe Mode", which goes a long way to
> closing these holes, but it's not a 100% solution.

Since you can read german:

The following article is older, but still true:

http://www.dclp-faq.de/q/q-konfiguration-safe-mode.html
12.2. Was genau bewirkt safe_mode und ist das sicher?

...

safe_mode ist nicht sicher: Ein Fehler in der popen() -Funktion
ist erst mit 3.0.14 korrigiert worden, ein weiterer Fehler in
der mail() -Funktion erst in 3.0.15. Sp?tere Versionen von PHP
hatten weitere L?cken. Man sollte stattdessen die CGI-Version in
einem chroot-Environment verwenden und mit setrlimit noch
weitergehende Einschr?nkungen definieren.

In English:

safe_mode is not secure. An exploit using popen() has been fixed
in 3.0.14, another exploit using mail() was fixed i 3.0.15.
Later versions of PHP had additional exploits. You should be
using the CGI version of PHP in a chrooted environment instead,
and use setrlimit to configure additional restrictions.

You could also use the module version of PHP and relegate the
enitire apache instance (one per customer) into a chrooted jail.
If you were using Apache 2.0 you could try to use the
mpm_perchild_module
(http://httpd.apache.org/docs-2.0/mod/perchild.html) and try to
make it useable with a perchild chroot restriction.

Kristian