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
| ||
|
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
Powered by blists - more mailing lists