Parameter "chroot-en"

Post removed (X-No-Archive: yes)

Re: Parameter "chroot-en"

Steven Varco schrieb:
> Ich habe in einem Script von mir eben ne gravierende Sicherheitslücke
> entdeckt:
>
> Eine Datei wird über einen Parameter (z.B.
> script.php?file=/dokumente/irgendwas.txt eingebunden und ausgegeben:
>
> $FN = _REQUEST['file'];
> if ($FN != "" && file_exists($RootPathHtml.$FN))

if ($RootPathHtml.$FN == realpath($RootPathHtml.$FN))

[...]
> Was mich jetzt interessieren würde wäre eine elegante Lösung für dieses
> Problem; ein chroot für Parameter sozusagen... *g*

Die Konfigurationsvariable open_basedir bietet natürlich
auch noch einen grundlegenden Schutz.


Gruß
JPM

Re: Parameter "chroot-en"

"Jens Peter Moeller" schrieb:
>Die Konfigurationsvariable open_basedir bietet natürlich
>auch noch einen grundlegenden Schutz.

Die ist normalerweise auf den root des vhosts gesetzt und bietet so
natürlich nur schutz ausserhalb des vhostes.
Würde man den auf den DOCUMENT_ROOT setzen, könnte man auch intern z.B.
keine config-files mehr includen in dem z.B. passwörter der
mysql DB stehen... ;-)

Was mich verwundert hat ist, dass PHP ein Konstrukt wie:
/home/vhost/public_html/../conf.php überhaupt zulässt... Denke da könnte
man sicher interpreter-seitig einiges zur security beitragen...

Re: Parameter "chroot-en"

Steven Varco wrote:

> Was mich verwundert hat ist, dass PHP ein Konstrukt wie:
> /home/vhost/public_html/../conf.php überhaupt zulässt... Denke da könnte

Das hat nix mit PHP zu tun. Das ist ein Feature von Betriebsystemen!
PHP setzt nur um.

> man sicher interpreter-seitig einiges zur security beitragen...

sicher nicht! Das was Du da verlangst ist mehr als abstrus! Es sind PHP
Grundlagen sauberen und sicheren Code zu schreiben. Diese hast Du
scheinbar nicht gelernt. Aber PHP kannst Du nicht die Schuld an Deinem
Wissensnotstand geben in dem Du solche Forderungen hast.

Ich will Dir damit keinen Vorwurf für Dein Unwissen machen, fängt halt
jeder mal an. Aber wenn man eine Programmiersprache für den produktiven
Einsatz nutzen will isses halt nicht mit Allgemeinwissen zu PHP abgetan.
Da muss man sich halt mal ne Zeit lang sehr intensiv damit befassen ehe
man sich aufs Web losläßt. Das gilt für jede Programmier/Scriptsprache.

Es gibt halt leider viel zu viele Leute die der meinung sind PHP ist
leicht das geht alles fast von selbst. Das es so nicht ist siehst Du
leicht an dem was Du da so an Code verfast hast.

Schon die Tatsache, das Du einen Teilpfad zu einer Datei per URL an das
Script übergibst ist schlimm genug. Sowas macht man einfach nicht.
Das teilt man auf Parameter auf die (immer noch sinnvoll) aber halt
nicht direkt auf das verweisen was bisher als Pfad angegeben wurde.
z.B. ?dir=whatever&item=filename
Das erleichter auch die Prüfung der übergebenen Werte.

Dann muß ohne Ausnahme *jeder* Parameter geprüft werden, der von Aussen
an das Script übergeben wurde. (POST und GET) Eine direkte Verwendung
der ans Script übergebenen Parameter ist auszuschließen.

Sieh einfach zu das Du Deinen Code so aufbaust das derartiges bereits
ausgeschlossen ist. Manuals und Anleitungen zu sicherer
PHP-Programmierung gibts zu Genüge!

MfG, Ulf

Re: Parameter "chroot-en"

"Ulf Kadner" schrieb:
>Steven Varco wrote:
>
>>Was mich verwundert hat ist, dass PHP ein Konstrukt wie:
>>/home/vhost/public_html/../conf.php überhaupt zulässt... Denke da könnte
>
>Das hat nix mit PHP zu tun. Das ist ein Feature von Betriebsystemen!
>PHP setzt nur um.

Das ist mir schon klar, ich dachte auch eher an einen switch in der php
config, sowas ähnliches wie magic_quotes halt...


>>man sicher interpreter-seitig einiges zur security beitragen...
>
>sicher nicht! Das was Du da verlangst ist mehr als abstrus! Es sind PHP
>Grundlagen sauberen und sicheren Code zu schreiben. Diese hast Du
>scheinbar nicht gelernt. Aber PHP kannst Du nicht die Schuld an Deinem
>Wissensnotstand geben in dem Du solche Forderungen hast.

Ich kenne PHP schon seit Jahren und bin mir durchaus über das schreiben
von sauberem code bewusst.
Seit einiger Zeit programmiere ich aber weniger, sondern sichere
webserver ab, z.b. eben für Leute die nicht viel von defensiver
Programmierung verstehen.
Und da interessiert es mich halt mehr wie man die Programmiersprache
soweit möglich "idiotensicher" machen kann...


>Dann muß ohne Ausnahme *jeder* Parameter geprüft werden, der von Aussen
>an das Script übergeben wurde. (POST und GET) Eine direkte Verwendung
>der ans Script übergebenen Parameter ist auszuschließen.

Was ich eigentlich fragen wollte sind sinnvolle Validationsmechanismen
für POST/GET Parameter...

gruss,
Steven

Re: Parameter "chroot-en"

Steven Varco schrieb:

> "Jens Peter Moeller" schrieb:
> > Die Konfigurationsvariable open_basedir bietet natürlich
> > auch noch einen grundlegenden Schutz.
>
> Die ist normalerweise auf den root des vhosts gesetzt und bietet so
> natürlich nur schutz ausserhalb des vhostes.

Nur so nebenbei:
Wenn man schon "open_basedir" einsetzt, ist das natürlich /nicht/ auf das
root directory eingestellt, sondern auf die Directorys, in/unter denen sich
PHP bewegen darf. Wobei ich mir auch nicht sicher bin, wass du jetzt
wirklich mit "root des vhosts" meinst? Um Scriptsprachen (CGI) allgemein
abzusichern, gäbe es auch noch suEXEC.

Automatische Validierung von GET/POST kann es so jedenfalls nicht geben,
weil ja niemand weis, in was für einem Kontext der Input dann benutzt wird.
Das kann nur der Programmierer wissen.

Gruß
Carsten

Re: Parameter "chroot-en"

Am Wed, 23 Aug 2006 17:37:54 +0200 schrieb Ulf Kadner:

Hallo Ulf,

>> Was mich verwundert hat ist, dass PHP ein Konstrukt wie:
>> /home/vhost/public_html/../conf.php überhaupt zulässt... Denke da
>> könnte
>
> Das hat nix mit PHP zu tun. Das ist ein Feature von Betriebsystemen! PHP
> setzt nur um.
>
>> man sicher interpreter-seitig einiges zur security beitragen...
>
> sicher nicht! Das was Du da verlangst ist mehr als abstrus! Es sind PHP
> Grundlagen sauberen und sicheren Code zu schreiben. Diese hast Du
> scheinbar nicht gelernt. Aber PHP kannst Du nicht die Schuld an Deinem
> Wissensnotstand geben in dem Du solche Forderungen hast.

man kann aber sein PHP patchen, damit es etwas sicher
wird.
http://www.hardened-php.net/hphp/a_feature_list.html

cu

r23
--
http://www.myoos.de/fraktal/zoom.php

Re: Parameter "chroot-en"

"Carsten Wiedmann" schrieb:

>>Die ist normalerweise auf den root des vhosts gesetzt und bietet so
>>natürlich nur schutz ausserhalb des vhostes.
>
>Nur so nebenbei:
>Wenn man schon "open_basedir" einsetzt, ist das natürlich /nicht/ auf das
>root directory eingestellt, sondern auf die Directorys, in/unter denen sich
>PHP bewegen darf. Wobei ich mir auch nicht sicher bin, wass du jetzt
>wirklich mit "root des vhosts" meinst?

Ich hab mich vieleicht etwas unverständlich ausgedrückt... Mit vHost
root meine ich natürlich die Bereiche in denen sich PHP bewegt,
also z.B.:
/home/www/vhost1/, aber eben nicht /home/www/vhost1/public_html/, weil
man ja config-files, die man in seine Applikationen einbindet
nicht im Web-Sichtbaren Bereich haben will.
Ich hab das von Ulf so verstanden, dass er mir raten wollte
open_basedir auf den public_html path zu setzen...

>Automatische Validierung von GET/POST kann es so jedenfalls nicht geben,
>weil ja niemand weis, in was für einem Kontext der Input dann benutzt wird.
>Das kann nur der Programmierer wissen.

Nein, aber der Server Admin kann dem Programmierer vorschreiben _wie_
er den input erlangt. In meinem Beispiel hätte ich es dem
Programmierer (in diesem Fall sogar mir selbst *g*) gerne untersagt
jegliche Dateien mit '..' im Pfad einzubinden (wer macht das
schon so?!). ;-)


gruss,
Steven

Re: Parameter "chroot-en"

"Ralf Zschemisch" schrieb:
>>>man sicher interpreter-seitig einiges zur security beitragen...
>>
>>sicher nicht! Das was Du da verlangst ist mehr als abstrus! Es sind PHP
>>Grundlagen sauberen und sicheren Code zu schreiben. Diese hast Du
>>scheinbar nicht gelernt. Aber PHP kannst Du nicht die Schuld an Deinem
>>Wissensnotstand geben in dem Du solche Forderungen hast.
>
>man kann aber sein PHP patchen, damit es etwas sicher
>wird.
>http://www.hardened-php.net/hphp/a_feature_list.html

Klar man kann PHP auch komplett umschreiben... *g*
Der Patch gefällt mir, leider gehöre ich aber zu den Leuten die nach
möglichkeit nicht an software rumpatchen.
Aber einige der Funktionen (natürlich per php.ini jederzeit
AN/AB-schaltbar) hätte ich (und offensichtlich nicht nur ich) schon
gerne in der php-core...

Dann könnte man Applikationen wie pbpBB oder phpNuke (beide von
"erfahrenen" PHP Entwicklern geschrieben) wieder mehr oder weniger
Angstfrei einsetzen.

Re: Parameter "chroot-en"

On Thu, 24 Aug 2006 13:15:19 +0200 Steven Varco wrote:
> einige der Funktionen (natürlich per php.ini jederzeit
> AN/AB-schaltbar) hätte ich (und offensichtlich nicht nur ich) schon
> gerne in der php-core...

Das hier:

| Adds protection against newline attacks to mail()

....haette ich bitte gerne sofort und NICHT abschaltbar drin. Man
taete der Welt damit einen echten Gefallen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktbörse fuer Österreich

Edel? Edeler als Stefan!? Das wird wohl schwer fallen!
(Sloganizer)

Re: Parameter "chroot-en"

Ralf Zschemisch wrote:

> man kann aber sein PHP patchen, damit es etwas sicher
> wird.
> http://www.hardened-php.net/hphp/a_feature_list.html

Hallo Ralf!

Logisch. Ich hab auch nix dagegen. Ab PHP6 werden auch einige der
Features des Projekts übernommen. Aber soweit ich das überblicke
schaltet Hardened PHP das Verhalten auch nicht ab.
Klar gerad so ne Sachen wie "Canary traping" kann man siche bereits im
PHP-Source wesentlich performanter handlen. Aber viele Sachen da im
Projekt sind einfach nicht nötig wenn man weis was man da tut.

MfG, Ulf