Debian/Plesk/PHP4/PHP5 Security
Debian/Plesk/PHP4/PHP5 Security
Hallöchen,
Ich habe es endlich geschafft PHP5 paralell zu PHP4 auf einem Debian Sarge (auf dem Plesk 8.0.1) Server als CGI (mit suexec) laufen zu lassen.
Nun habe ich habe ein Problem festgestellt: Per Include ist es problemlos möglich die /etc/passwd ausgeben zu lassen. Da ich ein paar Domains auf diesem Server hoste, finde ich das nicht nur unschön sondern gefährlich.
Kann mir jemand sagen wie ich dies in dieser Umgebung unterbinden kann?
Ich habe PHP5 versucht so ähndlich wie möglich wie PHP4 kompiliert wurde zu kompilieren. Die beiden PHP Versionen haben das gleiche php.ini (nicht am gleichen Ort natürlich).
Da ich aber in dieser Umgebung keine "richtiges" open_basedir verwenden kann scheint die Security für PHP5 einfach nicht richtig zu greifen.
PHP4 gibt die passwd nicht aus (das open_basedir greift) jedeoch PHP5 schon. Kann mir jemand einen Tipp geben wie ich das verhindern könnte? Kann ich helfen in dem ich irgendwelche Konfigurationen/Logs poste?
Gruss und besten Dank schonmal im Vorraus,
Dawn
Ich habe es endlich geschafft PHP5 paralell zu PHP4 auf einem Debian Sarge (auf dem Plesk 8.0.1) Server als CGI (mit suexec) laufen zu lassen.
Nun habe ich habe ein Problem festgestellt: Per Include ist es problemlos möglich die /etc/passwd ausgeben zu lassen. Da ich ein paar Domains auf diesem Server hoste, finde ich das nicht nur unschön sondern gefährlich.
Kann mir jemand sagen wie ich dies in dieser Umgebung unterbinden kann?
Ich habe PHP5 versucht so ähndlich wie möglich wie PHP4 kompiliert wurde zu kompilieren. Die beiden PHP Versionen haben das gleiche php.ini (nicht am gleichen Ort natürlich).
Da ich aber in dieser Umgebung keine "richtiges" open_basedir verwenden kann scheint die Security für PHP5 einfach nicht richtig zu greifen.
PHP4 gibt die passwd nicht aus (das open_basedir greift) jedeoch PHP5 schon. Kann mir jemand einen Tipp geben wie ich das verhindern könnte? Kann ich helfen in dem ich irgendwelche Konfigurationen/Logs poste?
Gruss und besten Dank schonmal im Vorraus,
Dawn
-
Roger Wilco
- Posts: 5923
- Joined: 2004-05-23 12:53
Re: Debian/Plesk/PHP4/PHP5 Security
Wieso? In /etc/passwd stehen keine kritischen Informationen.Dawn wrote:Nun habe ich habe ein Problem festgestellt: Per Include ist es problemlos möglich die /etc/passwd ausgeben zu lassen. Da ich ein paar Domains auf diesem Server hoste, finde ich das nicht nur unschön sondern gefährlich.
http://php.net/manual/en/features.safe- ... en-basedirDawn wrote:Kann mir jemand sagen wie ich dies in dieser Umgebung unterbinden kann?
PHP holt sich die Konfiguration von vielen verschiedenen Quellen. Welche hast du denn schon ausprobiert?Dawn wrote:Ich habe PHP5 versucht so ähndlich wie möglich wie PHP4 kompiliert wurde zu kompilieren. Die beiden PHP Versionen haben das gleiche php.ini (nicht am gleichen Ort natürlich).
Wieso?Dawn wrote:Da ich aber in dieser Umgebung keine "richtiges" open_basedir verwenden kann
PHP-Teil der Apache-Konfiguration, relevante php.ini ohne Kommentare, "Configuration File (php.ini) Path", "Scan this dir for additional .ini files" und "additional .ini files parsed" aus der Ausgabe von phpinfo().Dawn wrote:Kann ich helfen in dem ich irgendwelche Konfigurationen/Logs poste?
Re: Debian/Plesk/PHP4/PHP5 Security
Weil mir der Gedanke nicht gefällt das PHP resp. ein "Angreifer" welcher unsicheren PHP code nutzt (ich hoste einige Freunde) auf meine Passwd-Datei zugreifen können. Ich weiss dass das Passwort verschlüsselt ist, per Brute-Force wäre es aber theoretisch möglich diese zu hacken. Nenn es Paranoia...Wieso? In /etc/passwd stehen keine kritischen Informationen.
Ich kenne open_basdir, nur scheint das mit PHP5 als CGI nicht zu funktionieren. Wiso kann ich auch nicht sagen. Aber ich habe es auf jeden Fall getestet und es hat nichts genützt in der php.ini das open_basedir zu setzen.
Vielleicht um meine Ausgangslage genauer zu definieren: Ich habe auf meinem Debian Sarge (stable) Server im Zusammenhang mit Plesk 8.0.1 das folgende HowTo verwendet um PHP5 nebst PHP4 ebenfalls nutzen zu können:
http://www.serversupportforum.de/forum/ ... howto.html
Antwort siehe oben.Wieso?
Apache2 Teil:PHP-Teil der Apache-Konfiguration, relevante php.ini ohne Kommentare, "Configuration File (php.ini) Path", "Scan this dir for additional .ini files" und "additional .ini files parsed" aus der Ausgabe von phpinfo().
Code: Select all
<Directory "/usr/bin/php5">
AllowOverride None
Options +ExecCGI +FollowSymLinks
Order allow,deny
Allow from all
</Directory>
ScriptAlias /php5-cgi /usr/bin/php5
Action application/php5-cgi /php5-cgi/php
AddType application/php5-cgi .php5"Configuration File (php.ini) Path" wäre "/etc/php5/php.ini" was so auch stimmt und funktioniert (so habe ich versucht ein open_basedir zu setzen, hat geklappt aber hat nichts bewirkt).
php.ini:
Code: Select all
[PHP]
engine = On
short_open_tag = On
asp_tags = Off
precision = 12
y2k_compliance = On
output_buffering = Off
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func=
serialize_precision = 100
allow_call_time_pass_reference = On
safe_mode = On
safe_mode_gid = Off
safe_mode_include_dir =
safe_mode_exec_dir =
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
open_basedir = /tmp
disable_functions =
disable_classes =
expose_php = On
max_execution_time = 60 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
memory_limit = 64M
error_reporting = E_ALL & ~E_NOTICE
display_errors = On
display_startup_errors = Off
log_errors = Off
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
variables_order = "EGPCS"
register_globals = Off
register_argc_argv = On
post_max_size = 10M
gpc_order = "GPC"
magic_quotes_gpc = On
magic_quotes_runtime = Off
magic_quotes_sybase = Off
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
include_path = ".:"
doc_root =
user_dir =
enable_dl = On
file_uploads = On
upload_max_filesize = 10M
allow_url_fopen = On
default_socket_timeout = 60
define_syslog_variables = Off
SMTP = localhost
smtp_port = 25
sql.safe_mode = Off
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
mysql.allow_persistent = On
mysql.max_persistent = -1
mysql.max_links = -1
mysql.default_port =
mysql.default_socket =
mysql.default_host =
mysql.default_user =
mysql.default_password =
mysql.connect_timeout = 60
mysql.trace_mode = Off
msql.allow_persistent = On
msql.max_persistent = -1
msql.max_links = -1
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
sybase.allow_persistent = On
sybase.max_persistent = -1
sybase.max_links = -1
sybase.min_error_severity = 10
sybase.min_message_severity = 10
sybase.compatability_mode = Off
sybct.allow_persistent = On
sybct.max_persistent = -1
sybct.max_links = -1
sybct.min_server_severity = 10
sybct.min_client_severity = 10
dbx.colnames_case = "unchanged"
bcmath.scale = 0
ifx.default_host =
ifx.default_user =
ifx.default_password =
ifx.allow_persistent = On
ifx.max_persistent = -1
ifx.max_links = -1
ifx.textasvarchar = 0
ifx.byteasvarchar = 0
ifx.charasvarchar = 0
ifx.blobinfile = 0
ifx.nullformat = 0
session.save_handler = files
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_divisor = 100
session.gc_maxlifetime = 1440
session.bug_compat_42 = 1
session.bug_compat_warn = 1
session.referer_check =
session.entropy_length = 0
session.entropy_file =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="
mssql.allow_persistent = On
mssql.max_persistent = -1
mssql.max_links = -1
mssql.min_error_severity = 10
mssql.min_message_severity = 10
mssql.compatability_mode = Off
mssql.secure_connection = Off
ingres.allow_persistent = On
ingres.max_persistent = -1
ingres.max_links = -1
ingres.default_database =
ingres.default_user =
ingres.default_password =
pfpro.defaulthost = "test-payflow.verisign.com"
pfpro.defaultport = 443
pfpro.defaulttimeout = 30
extension=domxml.so
extension=mysql.so
extension=imap.so
extension=gd.soCode: Select all
./configure --prefix=/usr/share/php5 --datadir=/usr/share/php5 --bindir=/usr/bin/php5 --with-config-file-path=/etc/php5 --with-exec-dir=/usr/lib/php5/bin --enable-memory-limit --enable-force-cgi-redirect --disable-debug --with-regex=php --disable-rpath --disable-static --with-pic --with-layout=GNU --with-pear=/usr/share/php --enable-calendar --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-track-vars --without-mysql --enable-trans-sid --enable-bcmath --with-bz2 --enable-ctype --with-iconv --enable-exif --enable-filepro --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex --enable-shmop --enable-sockets --enable-wddx --disable-xml --with-expat-dir=/usr --with-xmlrpc --enable-yp --with-zlib --without-pgsql --with-kerberos=/usr --with-openssl=/usr --with-zip=/usr --enable-dbx --with-mime-magic=/usr/share/misc/file/magic.mime --without-mm --without-mysql --without-sybase-ctRe: Debian/Plesk/PHP4/PHP5 Security
Ich hoffe Du hast ausreichend C-Kenntnisse, um zu verstehen, welche Sicherheitslücken der "Patch" öffnet und wie er für aktuellere PHP-Versionen angepasst werden muss. Desweiteren ist Deine php.ini sicherheitstechnisch unzumutbar, siehe PHP-Manual und http://www.rootforum.org/wiki/howto/gen ... figurieren
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
-
Roger Wilco
- Posts: 5923
- Joined: 2004-05-23 12:53
Re: Debian/Plesk/PHP4/PHP5 Security
Seit wann stehen die Passworthashes unter GNU/Linux denn wieder in der /etc/passwd?Dawn wrote:Weil mir der Gedanke nicht gefällt das PHP resp. ein "Angreifer" welcher unsicheren PHP code nutzt (ich hoste einige Freunde) auf meine Passwd-Datei zugreifen können. Ich weiss dass das Passwort verschlüsselt ist, per Brute-Force wäre es aber theoretisch möglich diese zu hacken. Nenn es Paranoia...
Benutze bitte eine ungepatchte PHP-Version. Gerade der Patch aus dem von dir geposteten Beitrag fummelt an den open_basedir Einstellungen herum und unterwandert diese bei unsachgemäßer Nutzung (Stichwort Racecondition bei strlcat). Du kannst dem CGI-Binary von PHP mit der Umgebungsvariable PHPRC oder dem Parameter -c eine eigene Konfigurationsdatei übergeben. Das Herumgefrickel am Quellcode ist unnötig und in deinem Fall gefährlich.Dawn wrote:"Configuration File (php.ini) Path" wäre "/etc/php5/php.ini" was so auch stimmt und funktioniert (so habe ich versucht ein open_basedir zu setzen, hat geklappt aber hat nichts bewirkt).
Schlechte Idee[tm].Dawn wrote:Wenn ihr euch wegen meiner PHP-Optionen resp. dem Configure fragt, ich habe möglichst versucht die Einstellungen von PHP4 zu übernehmen.
Re: Debian/Plesk/PHP4/PHP5 Security
@ Joe User & Roger Wilco: Erstmal ein riesen Dankeschön das ihr euch die Zeit genommen habt, und meine Konfiguration so genau unter die Lupe genommen habt. Ich denke ich bin zwar kein blutiger Anfänger, aber bei der Vielzahl der Möglichkeiten und den doch sehr unterschiedlichen HowTo's/Anleitung, ist es brutal schwer den richtigen Weg zu wählen.
Ich habe echt gedacht das ich den Source-Code von PHP ohne Gefahr so patchen kann und es schockiert mich das ihr als erfahrene Admins doch so klar und deutlich auf riesige Sicherheitslücken hinweist. Ich bin kein C-Guru, aber ich dacht echt das das nötig sei, damit PHP5 überhaupt erst nutzbar ist. Ich finde es natürlich sehr hässlich den Souce-Code einer so lang entwickelten Software zu verändern (kompatibilität), aber wie gesagt ich dachte das sei absolut nötig und ich könnte mich auf die Informationen verlassen, welche ich diesem How-To entnommen habe. Trotzdem bin ich natürlich sehr froh das ihr mir so klar und deutlich davon abgeraten habt.
Besten Dank auch für den Link einer zu empfehlenden php.ini, das bringt mich sehr viel weiter. Doch gerade dazu auch eine Frage: PHP 4 ist ja von Plesk standardmässig so konfiguriert, ist das in dem Fall so ein grosses Risiko? Für PHP 5 werde ich sicher die von euch angegebene INI verwenden. Gibt es eigentlich auch eine Empfehlung für die Configure-Optionen welche ich verwenden sollte um PHP 5 zu kompilieren? Es gibt so viele Möglichkeiten, das ich mir echt nicht zutrauen würde das genügend gut zu beurteilen..
Stichwort PHPRC: was genau muss ich denn in der Umgebungsvariable setzen, damit ich auf eine saubere Art die bei mir im Code gepachten Einstellungen für den Doc-Root (dafür war de gehacke am Code ja wie ich dem HowTo entnommen habe) automatisch setzen kann?
Was ich auch noch fragen wollte: Ich musst ja auch suexec2 verändern. Ist dies auch so riskannt und unverantwortlich? (sie Post von Freelancer auf http://www.serversupportforum.de/forum/ ... wto-5.html). Damit ich suexec2 überhaupt verwenden konnte musst ich die bestehende "/usr/lib/apache2/suexec2" umbennenen und die neu kompilierte dort hin kopieren. Ist auch sehr unschön meiner Meinung nach, aber ich weiss wirklich nicht wie ich dies besser lösen könnte?
Du hast absolut recht, dort stehen keine Hasches drin. Das ist absolut mein Fehler.
Im Übrigen: Wirklich nochmal besten Dank für eure Hilfe. Ich finde das absolut nicht selbstverständlich und ich versuche natürlich auch anderen Benutzern hier zu helfen wenn ich kann und ich mir sicher bin. Falls ich mal was für euch tun kann (z.B. einen Download-Mirror oder sowas) lasst es mich wissen, würde ich gerne machen.
Gruss aus der Schweiz und ein erholsames langes schönes Wochenende,
Dawn
Ich habe echt gedacht das ich den Source-Code von PHP ohne Gefahr so patchen kann und es schockiert mich das ihr als erfahrene Admins doch so klar und deutlich auf riesige Sicherheitslücken hinweist. Ich bin kein C-Guru, aber ich dacht echt das das nötig sei, damit PHP5 überhaupt erst nutzbar ist. Ich finde es natürlich sehr hässlich den Souce-Code einer so lang entwickelten Software zu verändern (kompatibilität), aber wie gesagt ich dachte das sei absolut nötig und ich könnte mich auf die Informationen verlassen, welche ich diesem How-To entnommen habe. Trotzdem bin ich natürlich sehr froh das ihr mir so klar und deutlich davon abgeraten habt.
Besten Dank auch für den Link einer zu empfehlenden php.ini, das bringt mich sehr viel weiter. Doch gerade dazu auch eine Frage: PHP 4 ist ja von Plesk standardmässig so konfiguriert, ist das in dem Fall so ein grosses Risiko? Für PHP 5 werde ich sicher die von euch angegebene INI verwenden. Gibt es eigentlich auch eine Empfehlung für die Configure-Optionen welche ich verwenden sollte um PHP 5 zu kompilieren? Es gibt so viele Möglichkeiten, das ich mir echt nicht zutrauen würde das genügend gut zu beurteilen..
Stichwort PHPRC: was genau muss ich denn in der Umgebungsvariable setzen, damit ich auf eine saubere Art die bei mir im Code gepachten Einstellungen für den Doc-Root (dafür war de gehacke am Code ja wie ich dem HowTo entnommen habe) automatisch setzen kann?
Was ich auch noch fragen wollte: Ich musst ja auch suexec2 verändern. Ist dies auch so riskannt und unverantwortlich? (sie Post von Freelancer auf http://www.serversupportforum.de/forum/ ... wto-5.html). Damit ich suexec2 überhaupt verwenden konnte musst ich die bestehende "/usr/lib/apache2/suexec2" umbennenen und die neu kompilierte dort hin kopieren. Ist auch sehr unschön meiner Meinung nach, aber ich weiss wirklich nicht wie ich dies besser lösen könnte?
Code: Select all
Seit wann stehen die Passworthashes unter GNU/Linux denn wieder in der /etc/passwd? Im Übrigen: Wirklich nochmal besten Dank für eure Hilfe. Ich finde das absolut nicht selbstverständlich und ich versuche natürlich auch anderen Benutzern hier zu helfen wenn ich kann und ich mir sicher bin. Falls ich mal was für euch tun kann (z.B. einen Download-Mirror oder sowas) lasst es mich wissen, würde ich gerne machen.
Gruss aus der Schweiz und ein erholsames langes schönes Wochenende,
Dawn
-
Roger Wilco
- Posts: 5923
- Joined: 2004-05-23 12:53
Re: Debian/Plesk/PHP4/PHP5 Security
Das kommt auf die eingesetzten Skripte an. Mit einigen der Einstellungen ist es einfacher, kaputte und gefährliche Skripte zu schreiben. Wenn die Skripte gut sind, machen die "unoptimalen" Einstellungen nicht so viel aus.Dawn wrote:Doch gerade dazu auch eine Frage: PHP 4 ist ja von Plesk standardmässig so konfiguriert, ist das in dem Fall so ein grosses Risiko?
Sowenig wie möglich. Erstelle nur das, was du wirklich brauchst. Wenn du die Erweiterungen als Shared Extensions baust, kannst du fehlende Erweiterungen später einfacher nachrüsten.Dawn wrote:Gibt es eigentlich auch eine Empfehlung für die Configure-Optionen welche ich verwenden sollte um PHP 5 zu kompilieren?
In die Variable PHPRC kommt der komplette Pfad zu der VHost-spezifischen php.ini. Die kannst du z. B. durch ein Skript erstellen und darin die erlaubten Verzeichnisse (open_basedir) setzen.Dawn wrote:Stichwort PHPRC: was genau muss ich denn in der Umgebungsvariable setzen, damit ich auf eine saubere Art die bei mir im Code gepachten Einstellungen für den Doc-Root (dafür war de gehacke am Code ja wie ich dem HowTo entnommen habe) automatisch setzen kann?
Jein. Das SuExec Binary bzw. der Quellcode muss sogar unbedingt an deine Anforderungen angepasst werden, wenn dir nicht gerade der per Default eingestellte Pfad (/var/www) reicht. Allerdings hebelt der Gute in dem Beitrag auch wieder einige der Sicherheitsvorkehrungen aus. Wenn er damit Leben kann...Dawn wrote:Was ich auch noch fragen wollte: Ich musst ja auch suexec2 verändern. Ist dies auch so riskannt und unverantwortlich?
Re: Debian/Plesk/PHP4/PHP5 Security
Ich komme einfach mit dem PHPRC resp. -c Parameter nicht wirklich klar. Wahrscheindlich ist die Lösung relativ einfach, jedoch finde ich sie nicht :(
Ich habe die vorgeschlagene php.ini im verzeichnis /var/www/vhosts/[domainname]/conf/php5.ini erstellt (Rechte: -rw-r--r-- root:root).
Danach habe ich die Apache2-Konfiguration für diesen vhost angepasst (kann ja beim Action Parameter nicht den -c Parameter anhängen):
Unter /usr/bin/php5 habe ich die Datei php-cgi-exec.sh erstellt und mit den folgenden Rechten versehen: -rwxr-xr-x root:root
Darin befindet sich folgendes script:
Wenn ich nun phpinfo() aufrufe, werden zwar die Infos angezeigt, jedoch verweisst "Configuration File (php.ini) Path" nicht auf die angegebene Ini.
Wie soll ich das lösen, bzw. was mache ich falsch?
Suexec2 habe ich momentan so gelassen wie es in der "suboptimalen" Anleitung von Freelancer stand. Wie genau müsste ich denn suexec(2) nutzen, damit ich den Code-Patch welchen du als unschön empfindest nicht benötige? Gibt es zudem noch eine andere Möglichkeit als die bestehende suexec(2) zu ersetzen?
Ich habe die vorgeschlagene php.ini im verzeichnis /var/www/vhosts/[domainname]/conf/php5.ini erstellt (Rechte: -rw-r--r-- root:root).
Danach habe ich die Apache2-Konfiguration für diesen vhost angepasst (kann ja beim Action Parameter nicht den -c Parameter anhängen):
Code: Select all
<Directory "/usr/bin/php5">
AllowOverride None
Options +ExecCGI +FollowSymLinks
Order allow,deny
Allow from all
</Directory>
ScriptAlias /php5-cgi /usr/bin/php5
Action application/php5-cgi /php5-cgi/php-cgi-exec.sh
AddType application/php5-cgi .php5Darin befindet sich folgendes script:
Code: Select all
#!/bin/sh
exec /usr/bin/php5/php -c /var/www/vhosts/[Domainname]/conf/php5.iniWie soll ich das lösen, bzw. was mache ich falsch?
Suexec2 habe ich momentan so gelassen wie es in der "suboptimalen" Anleitung von Freelancer stand. Wie genau müsste ich denn suexec(2) nutzen, damit ich den Code-Patch welchen du als unschön empfindest nicht benötige? Gibt es zudem noch eine andere Möglichkeit als die bestehende suexec(2) zu ersetzen?
