Page 2 of 2

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 17:00
by aldee
Das (De)Aktivieren ließe sich auch direkt über eine RewriteMap regeln (am einfachsten bei Anbindung an ein SQL-Backend). Gehe ich recht in der Annahme, dass PHP als Apache-Modul läuft? Wenn ja: darauf würde ich persönlich mich bspw. bei dem hier behandelten Szenario nie einlassen wollen ;-). Individuelle PHP-Konfigurationen ließen sich somit konzeptbedingt nur über lokale php.ini-Dateien auf Verzeichnisebene realisieren (oder indem man jedem VHost einen eigenen fcgi-starter spendiert; das halte ich aber für Overkill; eher würde ich den suexec so patchen, dass genau das nicht erforderlich ist). Aber ein Umschalten zwischen verschiedenen PHP-Binaries wäre natürlich auch über mod_rewrite möglich (und sonstige Feinheiten etwa mit Hilfe von Umgebungsvariablen).

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 17:26
by djcrackman
Gehe ich recht in der Annahme, dass PHP als Apache-Modul läuft? Wenn ja: darauf würde ich persönlich mich bspw. bei dem hier behandelten Szenario nie einlassen wollen ;-).
Jedem das seine und mir das Beste. Fahre damit weit über 10.000 User ohne Probleme - alles eine Frage der Skalierung.

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 17:29
by aldee
djcrackman wrote:alles eine Frage der Skalierung.
Das sehe ich anders ... aber das macht nichts ;-).

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 17:42
by djcrackman
aldee wrote:
djcrackman wrote:alles eine Frage der Skalierung.
Das sehe ich anders ... aber das macht nichts ;-).
Na dann spezifier doch deine Sicht - nenn mir eine exakte Situation, in der mein Setup einen gravierenden Sicherheitsnachteil hat - ich bitte darum, man lernt ja nie aus.

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 21:33
by aldee
Jetzt? Schwer. Vor bzw. in ein paar Tagen / Wochen: Bleistiftsweise http://www.php-security.org/

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 21:41
by djcrackman
Naja Moment - du bist ja nicht der einzige, der (scheinbar) ohne gute Argumente behauptet, dass das Setup alleine vom Gedanken her zum scheitern verurteilt ist. Ergo: nennt doch mal wirklich explizite Beispiele, hm?

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 21:47
by aldee
djcrackman wrote:Naja Moment - du bist ja nicht der einzige, der (scheinbar) ohne gute Argumente behauptet, dass das Setup alleine vom Gedanken her zum scheitern verurteilt ist. Ergo: nennt doch mal wirklich explizite Beispiele, hm?
Soll ich jetzt anfangen, Bugs aufzuzählen? Das Problem mit PHP oder sonstigen Skriptsprachen als Apache-Modul ist ein grundsätzliches (und nicht zwingenderweise PHP-spezifisch). Alle modular eingebundenen Skripte haben zwingenderweise Zugriff auf die Dateien sämtlicher VHosts. Alles, was Sauereien verhindert, sind (im Fall von PHP) PHP-eigene Mechanismen wie etwa der "Safe mode". Es werden regelmäßig PHP-Sicherheitslücken gefunden, die genau diese "Sicherheitsvorkehrungen" ad absurdum führen. Konkret: Dass ein Skript auf irgendeinem VHost gehackt wird, führt dazu, dass sämtliche VHosts kompromittiert werden können (so der böse Bube es denn wünscht).

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 21:59
by djcrackman
Alle PHP-Skripte haben per se Zugriff auf die Dateien sämtlicher VHosts.
Du solltest dir open_basedir, mod_userid usw usf genauer ansehen. Dinge wie safe_mode sind für die Tonne - es wäre wohl schwer hirnverbrannt von mir, meinen Usern ein Webinterface zur Verfügung zu stellen, mit der sie genau diese Dinge (safe_mode) selbst verwalten können, wenn ich damit Sicherheitslücken dieser Art (Fremdzugriff) aufreißen würde.
Dass ein Skript auf irgendeinem VHost gehackt wird, führt dazu, dass sämtliche VHosts kompromittiert werden können.
Wie gesagt: ein Beispiel wäre perfekt (ob mit aktuellem oder veralten Bug/Leak ist mir egal). Setup des Vhosts sieht so aus:

Code: Select all

<VirtualHost *:80>
  ServerAdmin rcpt@mail.net
  ServerName xyz.host.net
  DocumentRoot /www/usersites/x-x/xyz/pub/
  php_admin_flag engine On
  php_admin_flag safe_mode On
  php_admin_flag session.use_trans_sid Off
  php_admin_flag magic_quotes_gpc On
  php_admin_flag magic_quotes_runtime On
  php_admin_flag register_globals On
  php_admin_value error_reporting 2047
  php_admin_value upload_max_filesize 8M
  php_admin_value open_basedir /www/usersites/x-x/xyz/:/www/sys/php_scripts/
  php_admin_value user_dir /www/usersites/x-x/xyz/
  php_admin_value upload_tmp_dir /www/usersites/x-x/xyz/tmp/
  php_admin_value sendmail_path '/usr/sbin/sendmail_php -t -i -f usersite.xyz@host.net'
  php_admin_value session.save_path /www/usersites/x-x/xyz/tmp/
  php_admin_value safe_mode_include_dir /www/usersites/x-x/xyz/:/www/sys/php_scripts/
  php_admin_value safe_mode_exec_dir /www/usersites/x-x/xyz/
  php_admin_value extension_dir /www/usersites/x-x/xyz/
  php_admin_value soap.wsdl_cache_dir /www/usersites/x-x/xyz/tmp/
  <Directory "/www/usersites/x-x/xyz/pub">
    Options +Indexes +FollowSymLinks +SymLinksIfOwnerMatch
  </Directory>
  Include /www/sys/apache_log_usersites_gl.conf
  Include /www/sys/apache_downloadfilter.conf
  #Include /www/sys/apache_redirector.conf
</VirtualHost>
PHP-Setup:

Code: Select all

disable_functions
shell_exec, passthru, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, exec, system, suexec, popen, pclose, dl, ini_set, virtual, set_time_limit, ini_restore, symlink

magic_quotes_gpc	Off
magic_quotes_runtime	Off
magic_quotes_sybase	Off
max_execution_time	45
max_input_nesting_level	64
max_input_time	60
memory_limit	12M
register_globals	Off
register_long_arrays	Off
safe_mode	Off
safe_mode_exec_dir	/www/usersites/x-x/xyz/
Also, mit diesen Angaben sollte es dir doch möglich sein, ein exaktes Beispiel zu konstruieren. Und bitte kein "ich kenne gerade keinen Leak ...", falls doch, dann schenkt euch doch den dauernden flame gegen PHP als Modul, ja?

Re: PHP als Modul - Sicherheit

Posted: 2007-05-08 22:18
by aldee
djcrackman wrote:
Alle PHP-Skripte haben per se Zugriff auf die Dateien sämtlicher VHosts.
Du solltest dir open_basedir, mod_userid usw usf genauer ansehen.
Den safe mode habe ich nur exemplarisch herausgegriffen.
djcrackman wrote:Dinge wie safe_mode sind für die Tonne - es wäre wohl schwer hirnverbrannt von mir, meinen Usern ein Webinterface zur Verfügung zu stellen, mit der sie genau diese Dinge (safe_mode) selbst verwalten können, wenn ich damit Sicherheitslücken dieser Art (Fremdzugriff) aufreißen würde.
Auch open_basedir und Konsorten lassen sich bisweilen vollautomatisch verwalten (auch ganz ohne expliziten "Aufriss" ;-).
djcrackman wrote:Also, mit diesen Angaben sollte es dir doch möglich sein, ein exaktes Beispiel zu konstruieren. Und bitte kein "ich kenne gerade keinen Leak ...", falls doch, dann schenkt euch doch den dauernden flame gegen PHP als Modul, ja?
Tut mir leid, "Security Audits" führe ich nicht durch (aber verweise trotzdem gerne noch einmal auf http://www.php-security.org).

Das Konzept, sämtlichen Skripten zunächst einmal vollständige Permissions einzuräumen und diese dann durch mehr oder weniger halbgare Ansätze wieder zu beschneiden, ist einfach kaputt.

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 07:16
by djcrackman
zunächst einmal vollständige Permissions
Na welches Script hat denn vollständige Rechte bei dem oben angeführten Setup, das möchte ich gerne wissen.

Übrigens: mit dem lächerlichen Verweis auf MOPB habe ich gerechnet. Mehr als ein flame ist es also nicht?!

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 12:03
by aldee
djcrackman wrote:
zunächst einmal vollständige Permissions
Na welches Script hat denn vollständige Rechte bei dem oben angeführten Setup, das möchte ich gerne wissen.

Übrigens: mit dem lächerlichen Verweis auf MOPB habe ich gerechnet. Mehr als ein flame ist es also nicht?!
Wer hier flamet, sei einmal dahingestellt ;-). Wie hätten's Ihr open_basedir denn gerne umgangen?

http://www.php-security.org/MOPB/MOPB-36-2007.html
http://www.php-security.org/MOPB/MOPB-21-2007.html
http://www.php-security.org/MOPB/MOPB-20-2007.html

Oder von mir aus auch außerhalb des MOPB:

http://www.hardened-php.net/advisory_082006.132.html

Zudem kommen sämtliche PHP-Sicherheitslücken, die die Ausführung beliebigen (Maschinen-)Codes (durch Buffer-Overflows etc.) erlauben (nein, ich werde keine weitere Aufzählung starten), erst wirklich zum Tragen, wenn der PHP-Interpreter mit den Rechten des Webservers läuft. Dass bei entsprechenden Exploits keine PHP-eigenen "Restrictions" (open_basedir eingeschlossen, da auch das eine rein proprietäre PHP-Lösung ist und kein chroot o. ä. durchführt) mehr greifen können, sollte eigentlich selbstredend sein.

Da du offensichtlich keine konstruktive Kritik vertragen kannst und dich zwischenzeitlich auf Anfeindungen eingeschossen hast, ist die "Diskussion" an dieser Stelle für mich beendet.

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 13:53
by djcrackman
Da du offensichtlich keine konstruktive Kritik vertragen kannst und dich zwischenzeitlich auf Anfeindungen eingeschossen hast, ist die "Diskussion" an dieser Stelle für mich beendet.
Moooment, da kam wohl was falsch rüber :roll:. Was mir seit langem auf den Keks geht, ist die Tatsache, dass jeder dahergelaufene (soll nicht heißen, dass du so einer bist ;)) gleich rumschmeisst mit Dingen wie "als Modul? Pah, du hast ja keine Ahnung" ... "Modul? Ist doch unsicher!" ... aber wenn man mal genauer nachfragt, dann geht den Leuten zu 90% die Luft aus und du hörst Dinge wie "uah, ist halt so!". Und exakt DAS ist das, was mir seit langem sauer aufstößt.
Spielts nicht: ini_set() ist deaktiviert (putenv() mittlerweile übrigens auch).
mod_verify, mod_diffprivs ... such dir bitte eis aus.
Siehe eine Antwort weiter oben.
symlink() ist deaktiviert. Wer Symlinks braucht, kann diese per FTP erstellen.
wenn der PHP-Interpreter mit den Rechten des Webservers läuft
Tut er - jeder VHost hat eine eigene UID/GID. Er kann also innerhalb seines Verzeichnis veranstalten was er will. Außerhalb darf er gar nichts.
open_basedir eingeschlossen, da auch das eine rein proprietäre PHP-Lösung ist und kein chroot o. ä. durchführt
Die Paranoiden unter uns können mod_chroot oder ein tatsächliches CHROOT einsetzen - falls jemals ein Angreifer soweit kommen sollte, dann hat man bereits viel früher versagt.

So long, hoffe nicht mehr falsch verstanden worden zu sein ;).

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 14:19
by aldee
djcrackman wrote:
Da du offensichtlich keine konstruktive Kritik vertragen kannst und dich zwischenzeitlich auf Anfeindungen eingeschossen hast, ist die "Diskussion" an dieser Stelle für mich beendet.
Spielts nicht: ini_set() ist deaktiviert (putenv() mittlerweile übrigens auch).
War es das schon immer oder erst nach Bekanntwerden des Problems (gleiches gilt auch für die weiteren Beispiele)? Das Problem ist ja nicht, dass man PHP nicht "hinterherpatchen" könnte (sei es durch neue PHP-Binaries oder Anpassung der Konfiguration). Sinn der Übung ist, den "Schaden", der bis zu diesem Zeitpunkt verursacht werden kann, von vorneherin möglichst weitgehend zu begrenzen.
djcrackman wrote:
wenn der PHP-Interpreter mit den Rechten des Webservers läuft
Tut er - jeder VHost hat eine eigene UID/GID. Er kann also innerhalb seines Verzeichnis veranstalten was er will. Außerhalb darf er gar nichts.
Du hast für jeden VHost eine eigene Webserver-Instanz laufen? Dann habe ich dich wohl missverstanden. Oder meinst du das von dir zuvor erwähnte "mod_userid"? Dieses Apache-Modul ist mir leider nicht bekannt (Google leider auch nicht). Das scheint aber ein interessantes Konzept zu sein; laufen damit dann sämtliche Apache-Instanzen als "root" um Privileges droppen zu können, oder wie funktioniert das?

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 14:37
by djcrackman
War es das schon immer oder erst nach Bekanntwerden des Problems (gleiches gilt auch für die weiteren Beispiele)?
Da mit ini_set haufenweiße Schindluder getrieben wird (Manipulation der Scriptlaufzeit, Speicherbegrenzung, etc) ist ini_set seit jeher in meinem Setup deaktiviert. Als freehoster stehst du ja so oder so schon auf der Abschussliste von zig Scriptkidies :(.
Sinn der Übung ist, den "Schaden", der bis zu diesem Zeitpunkt verursacht werden kann, von vorneherin möglichst weitgehend zu begrenzen.
Kann ich beinahe so unterschreiben - wie gesagt: da nützt dann auch der CHROOT nicht mehr viel, wenn der Angreifer schon soweit gekommen ist, dass er darin rumklopfen kann.
Du hast für jeden VHost eine eigene Webserver-Instanz laufen?
Nein. Mit mod_diffprivs kannst du pro VHOST mit den Direktiven PrivsGroups und PrivsUser eigene GID und UID definieren. Das bedeutet: VHOST http://www.host.net kann als 99:99 laufen; http://www.host2.net kann als 100:100 oder 100:99 laufen, etc ... das gruppieren der Hosts ist dadurch natürlich um einiges Leichter und somit steht (meiner Meinung nach) einem Modul-Betrieb definitiv nichts mehr im Weg.

mod_userid gibt es scheinbar nicht mehr (habe noch alten Sourcen davon, mal schaun wo die rumliegen, dann uppe ich sie dir). Alternativ ist mod_become sehr interessant, der Author hat leider auch diese Projekt-Seite offline genommen: http://www.snert.com/Software/apache.html
Ebenfalls (als Alternative) sehr interessant ist mod_suid.

All diese Konzepte verfolgen das Grundlegende Rechtesystem von *nix, welche auf den CHMOD's und Owner-Permissions aufbaut.

Falls du mit einem simplen Modul den 1.3er in ein CHROOT verfrachten willst, dann gibt es da noch mod_chroot ... einfacher gehts dann nicht mehr ;).

Falls du es noch nicht kennst: http://modules.apache.org/search

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 14:57
by aldee
djcrackman wrote:
War es das schon immer oder erst nach Bekanntwerden des Problems (gleiches gilt auch für die weiteren Beispiele)?
Da mit ini_set haufenweiße Schindluder getrieben wird (Manipulation der Scriptlaufzeit, Speicherbegrenzung, etc) ist ini_set seit jeher in meinem Setup deaktiviert. Als freehoster stehst du ja so oder so schon auf der Abschussliste von zig Scriptkidies :(.
Das ist wohl wahr (ich persönlich würde mich aber auch da nicht auf PHP verlassen und direkt auf Systembenutzerebene Limits definieren). Hattest du bspw. Symlinks auch von vorneherein verboten?
djcrackman wrote:
Du hast für jeden VHost eine eigene Webserver-Instanz laufen?
Nein. Mit mod_diffprivs kannst du pro VHOST mit den Direktiven PrivsGroups und PrivsUser eigene GID und UID definieren. Das bedeutet: VHOST http://www.host.net kann als 99:99 laufen; http://www.host2.net kann als 100:100 oder 100:99 laufen, etc ... das gruppieren der Hosts ist dadurch natürlich um einiges Leichter und somit steht (meiner Meinung nach) einem Modul-Betrieb definitiv nichts mehr im Weg.
mod_diffprivs wird anscheinend nicht mehr weiterentwickelt, zumindest gibt es nur eine Version für Apache 1.3. mod_suid2 habe ich mir kurz angeschaut, Zitat von http://bluecoara.net/item24/cat5.html:
It means, all httpd process must run with "ROOT", you have to compile and configure Apache2 with -DBIG_SECURITY_HOLE option.
(wie ich bereits vermutete). Wer's mag ... Ich sehe das als keine ernsthafte Alternative (und nehme an, dass mod_diffprivs ähnlich funktioniert).

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 17:19
by djcrackman
MOD_DIFFPRIVS

A p a c h e S e c u r i t y M o d u l e

Make Apache configurable to work with diffrent uid/gid and chroot environment for each <VirtualServer>. Distributed under GNU General Public License.
Author: Lukasz Wojtow <lw@ftw.zamosc.pl>
Require: Apache httpd 1.3.x (it doesn't work for 2.0 yet)
Interesting ideas: Rafal Wijata <www.wijata.com>
Latest version available at: http://sourceforge.net/projects/moddiffprivs/ and
http://lw.ftw.zamosc.pl/mdp

This module provides three configuration directives:
- "Privs",
- "PrivsGroups",
- "PrivsUser"
- "PrivsAllowJumpVisits" - obsoleted, now always Off

All directives may be used in main server configuration or/and in
<VirtualServer> section.

[...]

2. PrivsGroups

When You use directive Privs for some server and want to change gid, then probably setgid() leaves groups[0] to old gid. This is bad for security reasons, beacuse when You want change only gid (as me), then changes are don't take effect. Normally processes have to call setgroups(0,NULL) to clear their groups table. This is done by this directive, it takes "Leave", "Clear" or "Init". If set to Leave - apache does nothing (leaves its groups[]). If set to Clear - apache clears any of supplementary groups. And finally if set to Init - apache will init user's groups to its groups, just as 'su' does. The default for now if Leave. Remember about some security consequences: sometimes You add some user to some group to _remove_ acces for this user (ie when file perms are:

rw----rw-, then group can't read this file). If user may call setgroups(0,NULL) then after that he/she is able to read such file.

3. PrivsUser

This directive is almost the same as Privs but it affects requests for ~user files. If you don't use it - then such requests will be disallowed for this server. This directive get 3 parameters: uid gid chrootdir. Uid and Gid can be #number or name (as in Privs directive) but can be also AsUserUid and AsUserGid. If AsUser* is used, bot gid and uid must me set to AsUser*. In this case, module will get username from ~user/file.html request and will do setgid() and setuid() for this user gid/uid (but still uid and gid cannot be less than MIN_GID and MIN_UID). Third parameter is dir (as in Privs) but can be also "AsUserHome", then module will get user (from ~user/file.html request) home dir, and call chroot for this dir. You can also do chroot for dir relative to user's home, ie AsUserHome.. or AsUserHome../../some_dir (and similar) In dir where chroot will be called, /etc/passwd have to exist, and there user's home dir have to be without chrootdir, ie:

in /etc/passwd is:
lw:x:1000:100:Lukasz W:/home/lw:/bin/bash

You want call chroot for /home for all user's requests, and setuid for user uid, setgid for user gid.

In httpd.conf:
PrivsUser AsUserUid AsUserGid AsUserHome..
You have to create file /home/etc/passwd and there:
lw:x:1000:100:Lukasz W:/lw:/bin/bash
^^^^
One more thing. If uid & gid is set to AsUser* and real dir is given (not AsUserHome), then module will try find user in /etc/passwd. But if it fails, it will try find user again after chroot is done.

If You have any problems, use DEBUG (define
ISDEBUG 1 in config.h) or use strace.

[...]

Mod_diffprivs has not defined 'merge' function, so directives from main server
are NOT inherited by virtual servers. This mean, if You set whatever directive in main server, it won't take effect in virtual servers. If You want it in virtual servers, You have to set it there explicit. Also, when You use this module, You have to change "MaxRequestPerChild" to 1. For ~User requests You have to set KeepAlive to Off. This may decrase Your Apache performance, so better increase "StartServers", "MinSpareServers" and "MaxSpareServers" something about 40% of current values. This module require from Apache some root's privileges. If You don't want run Apache as root and You are using Linux 2.2.x or 2.4.x, You can use tool "erup" by Rafal Wijata.
Erup allow You to set some users who can do setuid/setgid for other users,
and users who can call chroot for some dirs.

[...]
Sollte alle Fragen beantworten ...
Hattest du bspw. Symlinks auch von vorneherein verboten?
Hab das vor gut 14 Monaten deaktiviert, als die ersten Gerüchte kursierten, dass es da Probleme gibt - selbst verifizieren konnte ich die Probleme erst, als Beispiele zur Verfügung standen.
zumindest gibt es nur eine Version für Apache 1.3
Da ich alle meine System mit 1.3 (erfolgreich und absolut zufrieden) betreibe, tut mir das nicht weh ;). Einzig 4 Gateway Server muss ich naher Zukunft auf Apache 2.x oder lighty umrüsten, da ich Textfilter benötige.

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 17:36
by aldee
djcrackman wrote:Sollte alle Fragen beantworten ...
Das zwar nicht, aber die aufgeführten Nebenwirkungen bestärken mich in meiner Auffassung, dass dieses "Ding" (im gegenwärtigen Zustand) nicht für den produktiven Einsatz geeignet ist (und zwar auch nicht bei unterstellter Apache2-Kompatibilität ;-).

Re: PHP als Modul - Sicherheit

Posted: 2007-05-09 18:58
by djcrackman
aber die aufgeführten Nebenwirkungen bestärken mich in meiner Auffassung, dass dieses "Ding" (im gegenwärtigen Zustand) nicht für den produktiven Einsatz geeignet ist
Darüber lässt sich streiten ;). Fakt ist, dass es funktioniert.