PDA

Bekijk Volledige Versie : php & phpinfo / imap



WH-Tim
16/12/04, 13:56
Ik heb hier een zeer raar verschijnsel. In de shell geeft php andere modules en versies aan dan de phpinfo(); ..

In de shell:


# php -v
PHP 4.3.9 (cli) (built: Dec 16 2004 12:07:01)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

#php -m
[PHP Modules]
bcmath
calendar
ctype
curl
ftp
gd
gettext
imap
mcrypt
mhash
mysql
openssl
overload
pcre
posix
session
sockets
standard
tokenizer
xml
zip
zlib

[Zend Modules]


Terwijl als ik phpinfo(); doe krijg ik dit:


PHP Version 4.3.4

'./configure' '--enable-force-cgi-redirect' '--enable-cgi' '--with-curl' '--with-curl-dir=/usr/local/lib' '--with-gd' '--with-gd-dir=/usr/local/lib' '--with-gettext' '--with-jpeg-dir=/usr/local/lib' '--with-kerberos' '--with-mcrypt' '--with-mysql' '--with-pear' '--with-png-dir=/usr/local/lib' '--with-xml' '--with-zlib' '--with-zlib-dir=/usr/local/lib' '--enable-bcmath' '--enable-calendar' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-track-vars'


Imap weg.. en de versie is opeens anders. De imap applicaties draaien overigens ook niet, terwijl imap WEL draait en is meecompiled.



# netstat -an | grep 143
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN


Iemand een idee wat hier aan de hand kan zijn?

PeterT
16/12/04, 14:03
Het mag duidelijk zijn dat Apache (of je webserver) een andere PHP versie gebruikt.
Ik zie ook dat je niet --with-apxs=/usr/local/apache/bin/apxs (of evt. andere locatie van apache) hebt gebruikt bij je php compilatie.. is wel handig op zich ;)

WH-Tim
16/12/04, 14:14
Kan aan mij liggen, maar het leek mij tot vandaag nogal vrij normaal dat er maar 1 phpversie draait op de server. Indien mijn apache op 3.4.3 ingesteld staat, wat volgensmij ook zo is, kan dit dan niet veranderd worden dat deze gewoon de goede versie pakt, de standalone compiled 3.4.9?

PeterT
16/12/04, 14:19
Als je de standalone goed compiled wordt deze automatisch door Apache opgepakt.

tino
16/12/04, 14:24
Doe op de server eens een locate php.
Ik weet zeker dat er meerdere op staan. Misschien één die standaard bij OS geleverd wordt en ééntje van source gecompileerd?

Tino

WH-Tim
16/12/04, 14:34
Klopt, dit komt doordat ik suphp aan het installeren ben geweest. Momenteel bestaan er:

php
php.CGI
php.CLI

Maar dit is een vrij normale installatie van suphp, zo met deze bestanden. Kan ik niet ergens opgeven welke hij als standaard moet pakken?

/edit:

Heb inderdaad nog een source installatie gevonden, zal even de rotzooi opruimen en opnieuw testen.

PeterT
16/12/04, 15:06
Ik zou gewoon even opnieuw compilen, kan je meteen php 4.3.10 erop zetten ;)

WH-Tim
16/12/04, 15:40
suPHP kan het goed verkloten als je er nog niet eerder mee gewerkt hebt :x

Goed dat het nog een server in aanbouw is, anders waren er al veel boze mails binnengekomen vandaag :p

PeterT
16/12/04, 15:45
suPHP is sowieso niet iets dat ik snel op een produktie server zou zetten..

WH-Tim
16/12/04, 15:52
Lijkt mij wel een stuk veiliger... Het OS is dan wel goed beveiligd met rechten en groepen, open_basedir per virtualhost en nog paar andere dingen, maar als je alles onder de user zelf kunt laten draaien lijkt mij dit toch de ultieme oplossing.

WH-Tim
16/12/04, 20:15
Pfieuw, apache+php draait weer (sinds vanmiddag eigenlijk al ;)) alleen die suphp nog goed configureren of eraf knallen. Wat zou jij als alternatief bieden PeterT als ik vragen mag, of laat jij het liever gewoon helemaal weg?

TSG-Hans
16/12/04, 20:30
Origineel geplaatst door WH-Tim
Lijkt mij wel een stuk veiliger... Het OS is dan wel goed beveiligd met rechten en groepen, open_basedir per virtualhost en nog paar andere dingen, maar als je alles onder de user zelf kunt laten draaien lijkt mij dit toch de ultieme oplossing.

open_basedir en suphp gaan niet samen.

Ik raad jou af suphp op een productie server " te knallen", omdat jou vragen hierboven aantonen dat jij het verschil niet begrijpt tussen php-cli en php-cgi. Bovendien zet je met een onjuiste configuratie van php-cgi en suphp meer open dan dicht. Ga eerst eens uitgebreid "spelen" met suphp ;)

WH-Tim
16/12/04, 21:22
Klopt, is me nog steeds niet duidelijk ;) Ik haal hem inderdaad eerst weer even eraf aangezien het op het moment geen zin heeft. Bedankt voor de tip in regel 1 :)

wv-
17/12/04, 17:07
tip voor in productie:

Je kan je huidige php, die gecompileerd is als module, in apache laten zitten. Je zet in je config dan een 2e handler voor de nieuwe php, bvb voor .phptest files. Eenmaal je uitgebreid getest hebt met .phptest files, kan je .phptest veranderen naar .php

PeterT
17/12/04, 18:09
Origineel geplaatst door WH-Tim
Wat zou jij als alternatief bieden PeterT als ik vragen mag, of laat jij het liever gewoon helemaal weg?

Geen van beide eigenlijk.
Simpelweg een aantal utilities root/wheel only maken en je bent redelijk veilig.
Nooit 100%, maar er zijn gewoon scripts die niet werken met suPHP / open base dir

TSG-Hans
17/12/04, 18:25
Origineel geplaatst door PeterT


Geen van beide eigenlijk.
Simpelweg een aantal utilities root/wheel only maken en je bent redelijk veilig.
Nooit 100%, maar er zijn gewoon scripts die niet werken met suPHP / open base dir

Indien php als apache module draait, is het niet aanzetten van open_basedir naar mijn mening onverantwoordelijk. Klanten kunnen immers in elkaars directory en over de hele server wandelen.

PeterT
17/12/04, 18:35
Hans,

Ik zei "liever geen van beide".. niet dat het ook zo was ;)

wv-
17/12/04, 19:05
Origineel geplaatst door PeterT


Geen van beide eigenlijk.
Simpelweg een aantal utilities root/wheel only maken en je bent redelijk veilig.
Nooit 100%, maar er zijn gewoon scripts die niet werken met suPHP / open base dir

Ik heb zelf een phpwrapper geschreven en heb nog geen enkel PHP script gehad dat niet werkte op die manier. Misschien dat je heel soms wel eens een configuratieoptie anders moet zetten in een scriptje die een bepaalde environment variabele gebruikt, maar voor de rest ben ik nog niets tegen gekomen.

Zoals vermeld is ook open_basedir zeker niet veilig om alles af te schermen. Er zijn verschillende zaken om dit te omzeilen.

Wat ik niet snap is wat je bedoelt met een aantal utilities root/wheel only te maken, aangezien een gebruiker zijn eigen binary kan uploaden en die executen. Wat je eigenlijk creeerd is een vals gevoel van veiligheid. (De setuid binary's nu niet meegerekend, want dat is nog een andere zaak)

PeterT
17/12/04, 19:44
Kwam er trouwens achter dat op 1 van onze servers het nog niet aanstond..

En wv- natuurlijk kunnen ze hun eigen binaries uploaden, dat kan altijd.. maar waarom zou je het ze makkelijker maken door bepaalde utilities (zoals compilers/w get etc.) niet root/wheel only te maken?

wv-
17/12/04, 19:49
Origineel geplaatst door PeterT
En wv- natuurlijk kunnen ze hun eigen binaries uploaden, dat kan altijd.. maar waarom zou je het ze makkelijker maken door bepaalde utilities (zoals compilers/w get etc.) niet root/wheel only te maken?

Dat mag je, maar heeft niet veel zin.

PeterT
17/12/04, 20:01
Toch ben je dan al iets veiliger, security werkt nog altijd in layers.
Deze layer jaagt meestal de scriptkiddies al weg.

wv-
17/12/04, 20:05
Origineel geplaatst door PeterT
Toch ben je dan al iets veiliger, security werkt nog altijd in layers.
Deze layer jaagt meestal de scriptkiddies al weg.

mja inderdaad. Ik doe het niet, maar php draait in een jail dus het komt uiteindelijk wel op hetzelfde neer.

PeterT
17/12/04, 20:11
Heb je PHP of Apache in een jail draaien ?
Indien PHP, dan neem ik even aan dat je het als CGI draait ?

Cybafish
17/12/04, 23:32
Origineel geplaatst door PeterT
suPHP is sowieso niet iets dat ik snel op een produktie server zou zetten..

Is dat zo? Wij draaien het al anderhalf jaar, vlekkeloos.

PeterT
17/12/04, 23:37
Origineel geplaatst door Cybafish


Is dat zo? Wij draaien het al anderhalf jaar, vlekkeloos.



Please note that the suPHP binary has to be installed setuid-root to work, so a security bug in suPHP probably will allow atackers to run commands with root privileges. Although I currently don't know any bug in suPHP I can't guarantee that there aren't any.

... dat is genoeg voor mij

wv-
17/12/04, 23:42
Origineel geplaatst door PeterT




... dat is genoeg voor mij

Er zijn alternatieven, of ge kunt zelf iets schrijven.

Veel auteurs zetten zo'n gelijkaardige teksten bij hun programma's, niks is bugfree, overal kan een bug in zitten.

Het enige wat bij zo'n wrappers ernstig fout kan zijn is dat er zich buggy code zou bevinden tussen het setuid() doen van de user en het aanroepen van het root setuid'd binary 'php-wrapper'. De regels hiertussen zullen zo weinig zijn dat er wel al iets ernstig fout zou moeten zijn dat daar nog een bug in gevonden wordt.

PeterT
17/12/04, 23:49
http://www.securityfocus.com/bid/11020/discussion/

In ieder geval 1 'report'..

WH-Tim
18/12/04, 00:44
Het is eigenlijk best jammer dat de lokale beveiliging steeds moeilijker wordt terwijl de beveiliging van buitenaf simpel te patchen of te blokkeren is..
Zou er niet iemand tussen die honderden hosters zijn die iets nuttigs op de markt kan brengen die ons in 1 keer van alle problemen afhelpt?

PeterT
18/12/04, 01:05
Stoppen met hosten bedoel je?
Geen klanten ?

Of wat wil je? :D

wv-
18/12/04, 01:52
Origineel geplaatst door PeterT
http://www.securityfocus.com/bid/11020/discussion/

In ieder geval 1 'report'..

als een gebruiker een bestand aanmaakt dat world writeable is, dan is het mogelijk om su-php te misbruiken om PHP te executen onder de rechten van die gebruiker. Dat is zonder die su-php ook mogelijk, hangt allemaal van de configuratie af. Ik heb persoonlijk su-php niet gebruikt, maar het gebruik van wrappers kan niet op tegen de brakke en snel omzeilbare beveiligingen van PHP zelf.


Origineel geplaatst door WH-Tim
Het is eigenlijk best jammer dat de lokale beveiliging steeds moeilijker wordt terwijl de beveiliging van buitenaf simpel te patchen of te blokkeren is..
Zou er niet iemand tussen die honderden hosters zijn die iets nuttigs op de markt kan brengen die ons in 1 keer van alle problemen afhelpt?

hosters? Ik ben nog niet veel hosters tegen gekomen die deftige software schrijven voor het securen van een webserver. Het zijn hosters die de software gebruiken en hun klanten laten denken dat ze het zelf geschreven hebben :)