[PHP] Exploit in alle PHP <4.1.2 versies

[Grum]

bron: http://www.php.net/

PHP Security Update

[27-Feb-2002] Due to a security issue found in all versions of PHP (including 3.x and 4.x), a new version of PHP has been released. Details about the security issue are available here. All users of PHP are strongly encouraged to either upgrade to PHP 4.1.2, or install the patch (available for PHP 3.0.18, 4.0.6 and 4.1.0/4.1.1).

Meer info: http://security.e-matters.de/advisories/012002.html

Download patches/nieuwe versie: http://www.php.net/downloads.php

[tomato]

Er gaan heel veel hosts zijn die deze patch voorlopig niet installeren

[Grum]

Er is ook geen proof-of-concept uit dus tja

Maar wat niet is kan nog komen

[HGM]

Op woensdag 27 februari 2002 16:31 schreef Grum_ het volgende:
Er is ook geen proof-of-concept uit dus tja

Is te hopen dat dat ook niet uitkomt, als je ziet hoevaak zwaar oude PHP versies nog gebruikt worden.

Dus maar weer gaan upgraden

[brammetje]

hmmz, alle hosts 4.1.2 laten gebruiken, ben der wel blij mee

[HGM]

Op woensdag 27 februari 2002 17:24 schreef brammetje het volgende:
hmmz, alle hosts 4.1.2 laten gebruiken, ben der wel blij mee

die droom zal nooit uitkomen, iig niet zeer binnenkort.

[brammetje]

Op woensdag 27 februari 2002 17:25 schreef HGM het volgende:
die droom zal nooit uitkomen, iig niet zeer binnenkort.

mja, das waar, toch zou het leuk zijn..

Ook is het wel een goede smoes als jij wilt dat ze updaten

[HGM]

Op woensdag 27 februari 2002 18:06 schreef brammetje het volgende:
Ook is het wel een goede smoes als jij wilt dat ze updaten

Hehe, er zijn bij hosters die zover achterlopen nog wel meer redenen om te gaan updaten

Maar misschien dat dit dan het doorslaggevende argument is ofzo

[elnino]

Op woensdag 27 februari 2002 18:12 schreef HGM het volgende:
Hehe, er zijn bij hosters die zover achterlopen nog wel meer redenen om te gaan updaten

Ik zat bij een webhoster die PHP 3.0.3 gebruikte en het onnodig vond om up te graden naar een nieuwere versie. Hostingproviders zijn over het algemeen lui, helaas. Jammer genoeg kan ik geen eigen server hosten.

Maar in ieder geval raad ik iedereen aan up te graden of één van de patches te downloaden op http://www.php.net/ te gebruiken, omdat anders kwaadwillenden programma's op jouw server kunnen uitvoeren.

[CyberSnooP]

Wat in ieder geval niet snel gaat gebeuren is de recommended settings van PHP gebruiken op elke hosts, hoe jammer ook.

Vooral dingen als "Very-easy-to-exploit" verontrusten mij toch wel. Wat ik vreemd vind is dat de code bij die bugs vaak is veranderd, (anders zou de uitbuitingsmoeilijkheidsgraad niet veranderen) maar niemand heeft de bug opgemerkt tot nu toe.

[brammetje]

Op woensdag 27 februari 2002 21:41 schreef CyberSnooP het volgende:
Wat in ieder geval niet snel gaat gebeuren is de recommended settings van PHP gebruiken op elke hosts, hoe jammer ook.

Tja, dan heb je snel klagende klanten aan de telefoon met de melding dat hun script niet meer werkt.. Ga jij ze allemaal maar eens vertellen dat ze $_POST['foo'] moeten gebruiken ipv. $foo. Ook is save mode af en toe best vervelend(of is dat niet aangeraden?)..

Vooral dingen als "Very-easy-to-exploit" verontrusten mij toch wel. Wat ik vreemd vind is dat de code bij die bugs vaak is veranderd, (anders zou de uitbuitingsmoeilijkheidsgraad niet veranderen) maar niemand heeft de bug opgemerkt tot nu toe.

Dit viel me ook al op.. weird indeed.

[LuCarD]

Op woensdag 27 februari 2002 21:45 schreef brammetje het volgende:

[..]

Tja, dan heb je snel klagende klanten aan de telefoon met de melding dat hun script niet meer werkt.. Ga jij ze allemaal maar eens vertellen dat ze $_POST['foo'] moeten gebruiken ipv. $foo. Ook is save mode af en toe best vervelend(of is dat niet aangeraden?)..
[..]

De zelf gemaakte scripts zijn niet zo ernstig... Maar de scripts die van een of andere code-gallery is afgetrokken die zijn pas lastig aan te passen...

Bah nog meer werk voor ons...


[edit]
vergeten ...


[edit2]
Bah heb net vorige week twee systemen lopen updaten naar 4.1.1 kan ik weer beginnen ...

[Grum]

nou wat een moeite

wget http://www.php.net/do_download.php?download_file=php-4.1.2.tar.gz
tar -zxvf php-4.1.2.tar.gz
cd php-4.1.2
head -20 ../php-4.1.1/config.status
copy & paste de config line
make && sudo make install

whoooeei

[Rense Klinkenberg]

Zie ik het verkeerd, of zijn er nog geen windows binaries. Op zich natuurlijk wel te verwachten, maar toch

[tomato]

freak007: Zie ik het verkeerd, of zijn er nog geen windows binaries.

En nu snel een proof of concept uitgeven

[Rense Klinkenberg]

Op donderdag 28 februari 2002 01:25 schreef tomato het volgende:
En nu snel een proof of concept uitgeven

Hehe

Moet ik toch maar eens aan het compileren onder win2k, er zou in de cvs versie nl. ook wat leuke niet xslt functies zitten, dus dan heb ik wel een reden.

[CubicQ]

Op donderdag 28 februari 2002 01:25 schreef tomato het volgende:

[..]

En nu snel een proof of concept uitgeven

"Finally I want to mention that most of these vulnerabilities are exploitable only on linux or solaris"

Dus ze kunnen wel even rustig aandoen met die windowsport (zoals gewoonlijk...)

[Rense Klinkenberg]

Dat compileren onder windows is eigenlijk best wel te doen. Na de laatste snapshop gecompileerd te hebben, bedacht ik me dat er best wel wat mensen blij zouden worden als er ook een windows versie van 4.1.2 uit zou zijn, vandar dat ik die maar effe in elkaar gedraaid heb.

[zipje] - Alle extensies die bij 4.1.1 zaten draaien er perfect onder, dus die heb ik niet opnieuw gecompileerd.

Enjoy en laat effe horen als er iets mis mee is.

[Kees]

Goed, alle t.net servers draaien ook de nieuwe php
scheelt weer een hackje

[maartenvdv737]

Hoe installeer je die update nou eigenlijk?

[Verwijderd]

- broken boundary check (very easy to exploit)

Ik snap em nie

[Scorpion]

hmmz, de patch voor 3.x is ook voldoende neem ik aan? er zijn hier noggal _VEEL_ scripts van een ex collega die behoorlijk fuckedup zijn, en dat gaat me een enorme tijd kosten om die shit te fixen.

[wasigh]

niet goed werkende grens controle

Je kunt dus bij geheugen komen waar je niet bij mag komen. Hoe je dat dan kan exploiten weet ik niet, maar duik ik de oude source zou ik zeggen


btw, bekende fouten exploiten is lame

[GraasGast]

Op donderdag 28 februari 2002 08:52 schreef maartenvdv het volgende:
Hoe installeer je die update nou eigenlijk?

Dat legt Grum_ net uit

nou wat een moeite

wget http://www.php.net/do_download.php?download_file=php-4.1.2.tar.gz
tar -zxvf php-4.1.2.tar.gz
cd php-4.1.2
head -20 ../php-4.1.1/config.status
copy & paste de config line
make && sudo make install

whoooeei

[paulh]

ach zolang je geen file upload scripts in je site hebt zitten. Dan is er niets aan de hand.

File upload scripts zijn zowiezo niet erg veilig. Vooral als je het toelaat om scripts te uploaden.

[CyberSnooP]

Op donderdag 28 februari 2002 12:43 schreef paulh het volgende:
ach zolang je geen file upload scripts in je site hebt zitten. Dan is er niets aan de hand.

File upload scripts zijn zowiezo niet erg veilig. Vooral als je het toelaat om scripts te uploaden.

Ik ben bang dat je niet selectief kunt toestaan wat er wordt geupload en wat niet. Ik denk zelfs dat de fout ook optreed zonder dat er sprake is van file uploads gebruiken in je script. Aangezien de files die worden opgestuurd sowieso verwerkt worden door PHP ongeacht of jouw script ze achteraf uitleest of niet.

(toch?)

[Crazy D]

Op donderdag 28 februari 2002 12:43 schreef paulh het volgende:
File upload scripts zijn zowiezo niet erg veilig. Vooral als je het toelaat om scripts te uploaden.

Misschien een opmerking hoor, maar (even niet van deze bug uitgaande) als je upload naar een dir waar je alleen schrijfrechten hebt maar geen execute rechten (kweet niet hoe dat met apache/php zit, maar in IIS kun je dat per dir aangeven) dan is er toch sowieso niks aan de hand, ook al uploaden ze een script? Bij het opvragen zal dan alleen de source getoont worden cq. je de file ter download aanbieden, maar toch verder niks?

[ACM]

Op donderdag 28 februari 2002 12:51 schreef CyberSnooP het volgende:
(toch?)

Ik denk dat je daarin gelijk hebt

Gelukkig zijn de servers van t.net al gepatched aangezien GoT en fok!forum wel standaard al van dat soort forms gebruik maken in bijv de profile pagina.

Op donderdag 28 februari 2002 12:54 schreef Crazy_D het volgende:
Bij het opvragen zal dan alleen de source getoont worden cq. je de file ter download aanbieden, maar toch verder niks?

Ik denk dat je dat verkeerd ziet, waarschijnlijk kan de code _in_ de geuploade file _door_ je php-script uitgevoerd worden.

[Bigs]

Hmm, ook maar ff updaten dan.

[Scorpion]

Op donderdag 28 februari 2002 12:51 schreef CyberSnooP het volgende:

[..]

Ik ben bang dat je niet selectief kunt toestaan wat er wordt geupload en wat niet. Ik denk zelfs dat de fout ook optreed zonder dat er sprake is van file uploads gebruiken in je script. Aangezien de files die worden opgestuurd sowieso verwerkt worden door PHP ongeacht of jouw script ze achteraf uitleest of niet.

(toch?)

yep, je kunt het zo bekijken: het moet eerst door php (waar de bug in zit) en gaat dan pas door naar het script.

[file] -> [internet] -> [server] -> [php] -> [script]

anyways, je kan het uitschakelen door in de .ini file "file_uploads = off" te plaatsen afaik. hoef je em niet eens te patchen. (maar als je de file-uploads nodig hebt dan moet je em dus wel patchen)

[Crazy D]

Op donderdag 28 februari 2002 12:59 schreef ACM het volgende:
Ik denk dat je dat verkeerd ziet, waarschijnlijk kan de code _in_ de geuploade file _door_ je php-script uitgevoerd worden.

Ik bedoelde niet specifiek met deze bug, maar gewoon in z'n algemeenheid (er even vanuit gaande dat hetgeen wat je upload gewoon bit voor bit weggeschreven wordt en dus niet ge-execute wordt door de parser (asp, php, whatever).
Mjah misschien snap ik het wel gewoon niet

[Belgar]

@freak007 -> zipje is corrupt

[Nikel]

Lijkt me niet zo eng allemaal. Ten eerste moeten er al bestanden geupload kunnen worden in eens script, dat doen niet veel mensen vaak. Ten tweede kun je alleen code uitvoeren met dezelfde rechten als php, en dan kun je niet echt veel verneuken, hoewel een site defacen dan natuurlijk wel prima gaat.

Je telnetd open laten staan lijkt me enger (he Kees? ), heb ik ook eens gedaan, werd meteen geh4x0rd .

[Olaf van der Spek]

Op woensdag 27 februari 2002 17:25 schreef HGM het volgende:

[..]

die droom zal nooit uitkomen, iig niet zeer binnenkort.

Je kunt het toch zelf installeren als je host het niet wil doen ?

[Grum]

slechte host die jou root geeft

[Rense Klinkenberg]

Op donderdag 28 februari 2002 15:58 schreef Belgar het volgende:
@freak007 -> zipje is corrupt

mmm, met winrar gemaakt, dus misschien dat winzip er niet te happig op is.

Alle aparte bestanden staan hier.

[Verwijderd]

joepie, daar word ik weer blij van weer ruzie met systeembeheer om alles servers te laten upgraden ...

[Verwijderd]

waarom zie ik geen enkele melding hiervan in de openBSD 3.0 errata PHP wordt met openBSD als package meegeleverd dus ik zou een patch van hun verwachten

[Olaf van der Spek]

Op donderdag 28 februari 2002 16:27 schreef Grum_ het volgende:
slechte host die jou root geeft

Ik bedoelde door gebruik te maken van deze exploit. Maar dan heb je inderdaad wel meer nodig omdat PHP normaal ook niet als root draait.

[admiral866]

na uploaden niet in de www dir zetten, maar elders op hd.
Dan bij downloaden de file vanaf buiten de www dir naar de gebruiker sturen.
Dan kan ie em niet executen.

[Grum]

admiral: dat is de exploit dus niet maar ok

[admiral866]

ooh, ik dacht dat iedereen het er hier over had?
nahja nm dan

[Grum]

de exploit zit em altijd in buffers die overflowen en dan 'foute-code' executen dus niet executable files ofzo

[Verwijderd]

Ik krijg een error tijdens make
-----------------------------------------------------
In file included from libmysql.c:5:
global.h:253: warning: redefinition of `uint'
/usr/include/sys/types.h:131: warning: `uint' previously declared here
global.h:254: warning: redefinition of `ushort'
/usr/include/sys/types.h:130: warning: `ushort' previously declared here
In file included from libmysql.c:12:
m_string.h:180: parse error before `__extension__'
m_string.h:180: parse error before `&&'
make[4]: *** [libmysql.lo] Error 1
make[4]: Leaving directory `/home/sites/home/php-4.1.2/ext/mysql/libmysql'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/sites/home/php-4.1.2/ext/mysql/libmysql'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/sites/home/php-4.1.2/ext/mysql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sites/home/php-4.1.2/ext'
make: *** [all-recursive] Error 1
-----------------------------------------------------------
Met deze command in ./configure
---------------------------------
./configure --prefix=/usr --with-apxs=/usr/sbin/apxs --with-gd --enable-safe-mode --with-config-file-path=/etc/httpd --with-exec-dir=/usr/bin --with-zlib --enable-magic-quotes --with-regex=system --with-ttf --with-db --with-gdbm --with-mbstring --with-mbstr-enc-trans --enable-track-vars --enable-xml --disable-debug --with-libdir=/usr/lib --with-ldap --with-imap --enable-ftp --with-imap-ssl --with-mysql

[MikeN]

Ik zou proberen niet de ingebouwde, maar je eigen mysql library te gebruiken. Met bijvoorbeeld --with-mysql=/usr doe je dat geloof ik.

[Verwijderd]

Volgende error
Die --with-mysql=/usr werkte!!
erg bedankt er voor..
Weten jullie een oplossing voor deze probleem ?
---------------------------------------------
TSRM/libtsrm.la -lcrypto -lssl -lc-client -ldl -lmysqlclient -lz -lldap -llber -lcrypt -lgd -lttf -lz -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt
libtool: link: warning: library `/usr/lib/libgdbm.la' was moved.
/usr/bin/ld: cannot find -lcrypto
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/home/sites/home/php-4.1.2'
make: *** [all-recursive] Error 1

[Verwijderd]

Op woensdag 27 februari 2002 16:31 schreef Grum het volgende:
[... drie posts na elkaar binnen een dag..]

UTFEB _{use the fucking edit button}