Bekijk Volledige Versie : 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-onder-cgi-is-kwetsbaar-door-ernstige-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.
rensariens
03/05/12, 18:27
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:
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
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.
dennis0162
03/05/12, 20:07
Ik heb net even wat dingen getest. Het lijkt erop dat FastCGI dezelfde bug heeft, volgens http://eindbazen.net/2012/05/php-cgi-advisory-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....
dennis0162
04/05/12, 10:44
De patch blijkt dus ook niet te helpen als je = encoded als %3D
http://tweakers.net/nieuws/81760/patch-voor-ernstige-php-bug-helpt-niet.html
De patch blijkt dus ook niet te helpen als je = encoded als %3D
http://tweakers.net/nieuws/81760/patch-voor-ernstige-php-bug-helpt-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...
dennis0162
04/05/12, 17:21
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.
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
PHP zegt sorry en biedt zijn excuses aan. Er komt weer een nieuwe patch aan. Het PHP-team komt dagen na het uitbrengen van de brakke spoedpatch voor het kritieke 0-day gat alsnog met excuses en belooft beterschap. Vandaag zou er een nieuwe beveiligingsupdate uitkomen.
Bron:
http://webwereld.nl/nieuws/110421/php-biedt-excuses-aan--plus-nieuwe-patch.html
nou nou nou zeg, weer echte webwereld taal
dreamhost_nl
08/05/12, 20:10
En dan als spuit elf enkele dagen met oud nieuws aankomen... (voor de duidelijkheid: duidt op Webwereld)