Onderwerp: Gevaarlijk lek met PHP als CGI......

PHP-installaties die via cgi worden aangeroepen, kunnen eenvoudig worden misbruikt. Op afstand kunnen argumenten aan het cgi-script worden toegevoegd, waardoor bijvoorbeeld code kan worden uitgevoerd of de broncode gedumpt.

Zie ook: http://tweakers.net/nieuws/81743/php...stige-bug.html

Een 'leuk' bugje dus, door elke persoon die maar weet hoe een URL-balk werkt maar te misbruiken. Gelukkig zijn er niet een groot aantal mensen meer die PHP draaien als CGI-wrapper, maar toch is het voor diegene al een flink probleem.

Ik heb enkele hostingplatformen van een paar bedrijven al geattendeerd op deze bug, gezien zij nog CGI gebruiken...

Ook wel jammer dat zoiets is uitgelekt.....

Wat is jullie mening?

Niet alleen jammer maar ook gevaarlijk dat zoiets uitlekt.
Nog veel gevaarlijker is het feit dat dit euvel dus al sinds 2004 bleek te bestaan, omdat toen door de php developpers een stukje code verwijderd is die juist dit probleem tegen ging.
Verder zijn ze al maanden bezig dit probleem te fixen en het is nog steeds niet gebeurt. Zo gezien is het dus goed dat het publiek wordt zodat er dan misschien wat sneller een fix komt. Van de andere kant is het eigenlijk een te gevaarlijk iets om publiek te zetten, gezien je er ook relatief eenvoudig machines mee kunt kapen.

Hopelijk komt er dan ook snel een fix uit. Er zijn volgens mij nog wel wat DA servers die php5-cgi in options.conf hebben en da's geen fastcgi, m.a.w. die systemen hebben een probleem.

Oorspronkelijk geplaatst door Blacky

Hopelijk komt er dan ook snel een fix uit. Er zijn volgens mij nog wel wat DA servers die php5-cgi in options.conf hebben en da's geen fastcgi, m.a.w. die systemen hebben een probleem.

Er draaien behoorlijk veel DA servers met php5-cgi volgens mij. Echter is dit met suphp meen ik en niet vatbaar voor deze bug. Kan echter zijn dat ik dat helemaal mis heb. Zal zo thuis eens wat meer inlezen

Bug werkt niet met suPHP wat inderdaad ook CGI based is. Volgens mij is php5-cgi meteen ook suPHP bij DA, maar pin me er niet op vast. Ik zie dit namelijk in build:

Code:

        php5-cgi) doChecks; doPhp5_suphp;

Wat meldt een suPHP installatie met phpinfo()?

Met PHP als CLI, zie ik dit:
Server API Apache 2.0 Handler

Oorspronkelijk geplaatst door Aar

Wat meldt een suPHP installatie met phpinfo()?

Met PHP als CLI, zie ik dit:
Server API Apache 2.0 Handler

Server API CGI/FastCGI

edit:
http://help.directadmin.com/item.php?id=197 - php5_cgi = suphp.

Het blijft een kwalijke zaak dat iets met zo`n impact zo lang duurt voordat er een bugfix is. Nu het uitlekt en meer in de belangstelling komt zit nog steeds de vaart er niet in, die je zou verwachten bij zulke lekken.

Ik heb net even wat dingen getest. Het lijkt erop dat FastCGI dezelfde bug heeft, volgens http://eindbazen.net/2012/05/php-cgi...cve-2012-1823/ zou FastCGI niet de bug bevatten. CGI i.c.m. SuPHP heeft geen last van de bug.

En de patch is er....
http://www.php.net/archive/2012.php#id2012-05-03-1

Happy patching all....

De patch blijkt dus ook niet te helpen als je = encoded als %3D

http://tweakers.net/nieuws/81760/pat...elpt-niet.html

Oorspronkelijk geplaatst door dennis0162

De patch blijkt dus ook niet te helpen als je = encoded als %3D

http://tweakers.net/nieuws/81760/pat...elpt-niet.html

Het was al een suffe bug, maar deze patch is helemaal niet te geloven. Je hoeft niet echt een woeste hacker te zijn om dit soort dingen te bedenken.

Ligt het aan mij of is de niet werkende patch alleen voor 5.3 en 5.4? Leuk voor de mensen die de laatste 5.2 release draaien (die deprecated is maar tot eind dit jaar updates zou krijgen volgens mij).

Las net dat de zakelijke hosting van KPN en ook de servers van aanbieder Byte kwetsbaar waren voor dit lek.
En het dan raar vinden als een 17 jarige puber al je servers hacked...

Oorspronkelijk geplaatst door pierce

Las net dat de zakelijke hosting van KPN en ook de servers van aanbieder Byte kwetsbaar waren voor dit lek.
En het dan raar vinden als een 17 jarige puber al je servers hacked...

XS4all precies hetzelfde, die hebben gisteren nog de servers gefixed.

- edit-

Byte doet toch iets met Magento Webhosting? En dan CGI draaien, dat is erg traag.

Oorspronkelijk geplaatst door dennis0162

XS4all precies hetzelfde, die hebben gisteren nog de servers gefixed.

- edit-

Byte doet toch iets met Magento Webhosting? En dan CGI draaien, dat is erg traag.

Byte doet inderdaad iets met Magento, Voor onze Magento setup hebben we echter een andere opstelling en zijn we druk bezig om een nieuw platform voor neer te zetten.

Overigens is de snelheid op vele manieren in Magento te krijgen, niet alleen door PHP met fcgi of mod_php te draaien, maar bijvoorbeeld ook door memcache goed neer te zetten, of varnish te gebruiken


Gelukkig werden wij erg vroeg ingelicht via directe connecties en konden we erg snel het platform voorzien van een patch. Wel respect voor partijen als KPN en XS4ALL dat ze het snel opgepakt hebben,

Disclaimer: ik werk bij Byte