suPHP - Probleme mit Wrapper Script

M

mark.b

New Member
Hallo Leute,
heute mal auf deutsch, geht schneller ;-)

Habe nach den vorhandenen Anleitungen ein Ubuntu 6.06.2 erfolgreich mit ISPConfig 2.2.21 zum Laufen gebracht. Nach der neuen Anleitung http://www.howtoforge.com/install-suphp-on-various-linux-distributions-for-use-with-ispconfig-2.2.20-and-above habe ich dann suPHP installiert und mir die Hinweise unter http://www.howtoforge.de/forum/showthread.php?t=91 angesehen.

suPHP scheint grundsätzlich zu laufen, da die entsprechenden vhosts angelegt werden.
<VirtualHost xx.xx.xx.xx:80>
ServerName xyz.domain.de:80
ServerAdmin webmaster@domain.de
DocumentRoot /var/www/web1/web
ServerAlias domain.de
DirectoryIndex index.html index.htm index.php index.php5 index.php4 index.php3 index.shtml index.cgi index.pl index.jsp Default.htm default.htm
ErrorLog /var/www/web1/log/error.log
AddType application/x-httpd-php .php .php3 .php4 .php5
<Directory /var/www/web1/web>
suPHP_Engine on
suPHP_UserGroup web1_mustermann web1
AddHandler x-httpd-php .php .php3 .php4 .php5
suPHP_AddHandler x-httpd-php
SetEnv php_safe_mode Off
</Directory>
...
Mein Problem ist jedoch, das die beschriebenen Features "open_basedir" oder "upload_temp_dir" laut phpinfo.php scheinbar nicht gesetzt werden, obwohl diese im "Wrapper Script" der Version 2.2.21 doch eigentlich enthalten sind. Momentan habe ich den Verdacht, das der Wert für BASEDIR=`/usr/bin/dirname ${DOCUMENT_ROOT}` nicht richtig gesetzt wird. Wenn das BASEDIR im "Wrapper Script" also schon in den ordner /web1/web zeigt könnte z.B. der Wert für "upload_temp_dir" nicht gesetzt werden, da dieser Ordner unter /web1/web ja nicht existiert.

Kann mir jemand einen Hinweis darauf geben was hier eventuell falsch läuft ? Oder habe ich nur einen Denkfehler und die Werte werden unter phpinfo.php nicht mit angezeigt ?

Danke
Mark
 
M

mark.b

New Member
Hallo nochmal,

da ja leider niemand eine Idee zum besagten Problem hat ;-) habe ich nun auf Ubuntu 7.10 Server umgeschwenkt. Nach der Anleitung http://www.howtoforge.com/perfect_server_ubuntu7.10 sowie der suPHP Anleitung http://www.howtoforge.com/install-s...tions-for-use-with-ispconfig-2.2.20-and-above und den schon gewonnen Erfahrungen der alten Distri habe ich sofort ein laufendes ISPConfig System mit suPHP an den Start gebracht. Also vergesst Ubuntu 6.06.2 Server LTS. Die dort verwendete PHP Version hat leider auch den "cURL library" Bug und ist damit leider nicht mehr sicher.:eek:

Drei Fragen bleiben aber noch offen, wobei ich denke, das die PHP Cracks unter Euch hier sicher helfen können :D

Frage 1:

Auf meinem alten System hatte ich zur Sicherheit die php.ini mit folgenden Werten angepasst:

disable_functions = show_source, system, shell_exec, passthru, exec, popen, proc_open

Gehe ich richtig in der Annahme das die entsprechende php.ini jetzt die Version unter /etc/php5/cgi ist ? Und kann ich sicherstellen, dass die Werte die ISPConfig Funktionalität nicht behindern, da ISPConfig ja offensichtlich seine eigene php.ini verwendet ?

Frage 2:

Das Tool PHPSecInfo von http://phpsec.org/projects/phpsecinfo/ meldet mir noch zwei kritische Sicherheitslücken:

"allow_url_fopen" war per default "enabled".

Diese Funktion habe ich ebenfalls unter /etc/php5/cgi/php.ini gesetzt, was scheinbar übernommen wurde. Kommt ISPConfig hiermit ebenfalls ohne Probleme klar (siehe oben)?

Frage 3:

Und schließlich meckert PHPSecInfo noch über

"cgi.force_redirect" is "disabled"

Leider habe ich es bis jetzt nicht geschafft diesen Wert zu aktivieren. Weder in der php.ini, noch im Wrapper Script. Der Wert scheint aber besonders bei PHP über CGI wichtig zu sein. Selbst wenn kein Wert gesetzt wird sollte dieser defaultmäßig aktiv sein. In einer mittels ISPConfig generierten Webseite ist dieser Wert aber leider immer aus.

Alle Hinweise sind absolut Willkommen, damit ich endlich reinen Gewissens meinen Server an den Start bringen kann.

Besten Dank schon im Vorraus.
greetz
mb
 
planet_fox

planet_fox

Super-Moderator
zu Frage 1.)

ISPConfig läuft unter eigenem Webserver und läuft auch mit eigenem PHP bzw eigener php.ini.
Gehe ich richtig in der Annahme das die entsprechende php.ini jetzt die Version unter /etc/php5/cgi ist
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Das kannst du ja test mit ner phpinfo, erstelle ne php datei mit folgendem code dann siehst ja welche er nimmt steht auch drin welche er nimmt.

Code: 
[COLOR=#000000][COLOR=#0000bb]<?PHP
phpinfo [/COLOR][COLOR=#007700]();
[/COLOR][COLOR=#0000bb]?>[/COLOR]
[/COLOR]

zu Frage 2

Ich kann das tool nicht sry

zu frage 3

Bin mir nicht sicher aber dürfe nicht sehr schlimm sein





Du kannst wenn suphp korekt läuft jedes web mit einer eigenen php config ausstatten.
 
M

mark.b

New Member
Danke für die schnelle Antwort.

Die phpinfo.php ist mir natürlich bekannt ;) Das ewige Suchen der entsprechenden Parameter in der phpinfo.php ging mir aber gehörig auf die Nerven und man übersieht da auch leichter etwas. Deshalb habe ich http://phpsec.org/projects/phpsecinfo/ ausprobiert. Bei der Ausgabe der Ergebinsse springen einen die falsch gesetzten Werte direkt an. Lohnt sich also das Teil mal auszuprobieren.

zu Frage 1. und Frage 2.
Ich habe jetzt in der /etc/php5/cgi/php.ini die folgenden Werte gesetzt.

disable_functions = show_source, system, shell_exec, passthru, exec, popen, proc_open

allow_url_fopen = off

Zu meinem Erstaunen kann ich den Parameter

disable_functions = exec

nicht verwenden, da mir dann angezeigt wird, das unter suPHP weder die user_id noch die group_id richtig gesetzt werden. Alle anderen Parameter wie open_basedir etc. laufen aber. Oder ist die Funktion exec nicht mehr als unsicher zu betrachten, wenn wegen suPHP die Seiten unter der jeweiligen ID des users laufen ?

Den grauen Text bitte nicht mehr beachten. Bleibt nur zur Info für andere User hier stehen.
Das Tool PHPSecInfo benutzt offensichtlich selbst "exec" um die user_id bzw. die group_id zu ermitteln und scheitert nur bei der Ausgabe der Werte. Damit relativiert sich natürlich auch die Aussage zu Frage 3 unten.

zu Frage 3:

Das Problem mit der Funktion "cgi.force_redirect" is "disabled" konnte ich bis dato immer noch nicht lösen, obwohl PHPSecInfo darauf besteht, das diese gerade bei Verwendung von suPHP wichtig wäre.

Wenn hier noch jemand einen Hinweis hätte wäre das echt super :D

Und auch hier scheint es sich zumindest laut einigen Einträgen in anderen Foren um eine Fehlinterpretation von PHPSecInfo zuhandeln. Es scheint sich somit heraus zu kristalisieren, dass das Tool zumindest zum Testen von suPHP nicht wirklich geeignet ist. Es lebe die phpinfo.php :)

Danke
mb
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top