image

PHP publiceert defecte patch voor ernstig lek

vrijdag 4 mei 2012, 09:23 door Redactie, 17 reacties

PHP heeft een beveiligingsupdate voor een zeer ernstig lek in de software uitgebracht, maar die blijkt niet te werken. Gisteren werd per ongeluk een groot gat in de populaire scripttaal geopenbaard, waardoor aanvallers kwetsbare servers konden overnemen. Het lek, dat door een groep Nederlandse hackers genaamd Eindbazen was ontdekt, was al maanden bij PHP bekend, maar een update liet op zich wachten.

Door nog onbekende reden werd de bugmelding gisteren opeens publiek toegankelijk, waarna die op het web belandde. De Eindbazen besloten hun advisory over het beveiligingslek dan ook te publiceren.

Noodpatch
PHP kwam gisteren met een noodpatch, maar die blijkt defect. "De update voor het PHP CGI-lek, die dagen lang getest zou zijn, verhelpt helemaal niets", aldus PHP-beveiligingsexpert Stefan Esser op Twitter. "Ze blijven dit soort blunders keer op keer herhalen."

Esser was onderdeel van het PHP Security Response Team, maar verliet de organisatie in 2006. De PHP Group zou namelijk alle pogingen om de populaire scripttaal veiliger te maken saboteren.

Ook de Eindbazen bevestigen dat PHP 5.3.12 en PHP 5.4.2, alsmede de officiële mod_rewrite oplossing het probleem niet verhelpen. 77,6% van alle websites op het internet gebruikt PHP.

Update 12:30
Stefan Esser haalt op Twitter hard uit naar PHP. "Typisch PHP, dat als ze beseffen dat hun patch stuk is, ze geen waarschuwing op de frontpage plaatsten. Nu downloadt iedereen de defecte update. En als ze vandaag 5.4.3 en 5.3.13 uitbrengen, moeten al die mensen het opnieuw downloaden."

Esser gaat verder: "Maar ze denken misschien dat ze [de laatste versie] al hebben. Als een systeembeheerder vandaag de update installeert en morgen een waarschuwing op een nieuwssite ziet, denkt hij dat hij de update al gedaan heeft."

Inmiddels is er ook een exploit aan hackertool Metasploit toegevoegd, maar die blijkt bepaalde functies niet uit te schakelen.

Reacties (17)
04-05-2012, 10:32 door Anoniem
77,6% van alle websites op het internet gebruikt PHP

Gelukkig is slechts een klein deel hiervan kwetsbaar voor deze bug.
04-05-2012, 10:53 door Anoniem
Ik snap er werkelijk geen donder van. Ik probeer die bug hier te reproduceren, maar op geen enkele site hier en we hebben zo ongeveer alle smaken, behalve de cgi-implementatie. (De domste setup die ik me kan voorstellen, overigens. We hebben wel *f*cgi.) Het lukt me niet. Ik zie 'm nergens.
04-05-2012, 10:54 door Anoniem
Door Anoniem: 77,6% van alle websites op het internet gebruikt PHP

Gelukkig is slechts een klein deel hiervan kwetsbaar voor deze bug.

Waaronder facebook, kind of. (Doh.)

http://facebook.com/?-s
04-05-2012, 11:00 door Anoniem
Door Anoniem: Ik snap er werkelijk geen donder van. Ik probeer die bug hier te reproduceren, maar op geen enkele site hier en we hebben zo ongeveer alle smaken, behalve de cgi-implementatie. (De domste setup die ik me kan voorstellen, overigens. We hebben wel *f*cgi.) Het lukt me niet. Ik zie 'm nergens.

Dat is het 'm juist: FCGI is niet kwetsbaar, alleen klassieke CGI. Zie ook de FAQ van de Eindbazen.
04-05-2012, 11:07 door Anoniem
Dit is weer een heerlijk schreeuwerig artikel dat eigenlijk helemaal nergens over gaat.

De "platte" CGI implementatie van PHP is een optie die door vrijwel niemand wordt gebruikt, de meest voorkomende zijn apache modules of fastCGI.

Overigens is Stefan Esser voor PHP wat Florian Mueller voor opensource en patenten is, een grote troll wiens volledige bedrijfsmodel draait op het zwartmaken van de reguliere initiatieven.

Nee, de PHP core ontwikkelaars hebben zeker geen schone handen als het gaat om quality assurance en testing, hoewel dat de laatste jaren bijzonder sterk verbeterd is, schijnbaar raakt Stefan hierdoor teveel business kwijt en moest er weer eens geschopt worden...
04-05-2012, 11:09 door Anoniem
Door Anoniem: Ik snap er werkelijk geen donder van. Ik probeer die bug hier te reproduceren, maar op geen enkele site hier en we hebben zo ongeveer alle smaken, behalve de cgi-implementatie. (De domste setup die ik me kan voorstellen, overigens. We hebben wel *f*cgi.) Het lukt me niet. Ik zie 'm nergens.
Het werkt *alleen* op classic cgi implementaties. Er zijn nog best veel sites die zo php draaien, om php onder verschillende uid's te draaien.
04-05-2012, 11:19 door [Account Verwijderd]
[Verwijderd]
04-05-2012, 11:40 door Anoniem
de voorpagina van facebook is wel kwetsbaar dus wat draaien ze daar een slechte setup zeg
04-05-2012, 11:53 door [Account Verwijderd]
[Verwijderd]
04-05-2012, 12:59 door Anoniem
Door Krakatau:
Door redactie:
Update 12:30
Stefan Esser haalt op Twitter hard uit naar PHP. "Typisch PHP, dat als ze beseffen dat hun patch stuk is, ze geen waarschuwing op de frontpage plaatsten. Nu downloadt iedereen de defecte update. En als ze vandaag 5.4.3 en 5.3.13 uitbrengen, moeten al die mensen het opnieuw downloaden."
Dat geeft eens te meer aan dat PHP beter niet gebruikt kan worden voor bedrijfskritische sites. Op zich niets tegen PHP - mijn eigen bedrijfssite draait onder Drupal - maar voor bedrijfskritische sites of sites met persoonsgegevens kan je echt beter Java Enterprise Edition gebruiken! Of desnoods ASP.NET - als je niet geeft om vendor neutrality en bereid bent je ziel aan Microsoft te verkopen ;-)
Waarom denk je dat het beter is bij Java? Hun RE hangt met plakband aan elkaar en wordt regelmatig lek geschoten. Verder staat Oracle ook niet goed bekend als het om security fixes gaat. Het gebeurt regelmatig dat bugs pas na jaren aandringen gepatched worden, of er komt zelfs helemaal geen reactie vanuit Oracle.

Hoe het bij ASP.net is kan ik geen uitspraken over doen, geen ervaring mee.
04-05-2012, 13:19 door [Account Verwijderd]
[Verwijderd]
04-05-2012, 13:23 door Anoniem
Door Krakatau:
Door redactie:
Update 12:30
Stefan Esser haalt op Twitter hard uit naar PHP. "Typisch PHP, dat als ze beseffen dat hun patch stuk is, ze geen waarschuwing op de frontpage plaatsten. Nu downloadt iedereen de defecte update. En als ze vandaag 5.4.3 en 5.3.13 uitbrengen, moeten al die mensen het opnieuw downloaden."
Dat geeft eens te meer aan dat PHP beter niet gebruikt kan worden voor bedrijfskritische sites. Op zich niets tegen PHP - mijn eigen bedrijfssite draait onder Drupal - maar voor bedrijfskritische sites of sites met persoonsgegevens kan je echt beter Java Enterprise Edition gebruiken! Of desnoods ASP.NET - als je niet geeft om vendor neutrality en bereid bent je ziel aan Microsoft te verkopen ;-)

Java? Nee dat is echt veiliger, wat Sun laakte in veiligheid zet Oracle moedeloos door.

Ik werk zelf met PHP, en er is prima mee te werken.
Iedere taal heeft zijn/haar quirks rariteiten, Perl 6 is al meer dan 10 jaar ontwikkeling en nog niet stable.
Het zelfde gelde voor PHP6 (IE6?, Windows Vista NT 6.0?! - Is dit nummer soms vervloekt!?)

PHP op zich zelf niet slecht maar de meeste ontwikkelaars van PHP doen niet echt hun best.
De bedenker zelf bijvoorbeeld https://en.wikiquote.org/wiki/Rasmus_Lerdorf

En de grote baas Zend Technologies, een jaar na de uitgave van PHP 5.3 was er nog steeds geen compatible versie van Zend optimizer beschikbaar! Ze werken er zelf aan mee, maar kunnen niet op tijd leveren.

Sinds PHP 5.4 is het gelukkig al een stuk serieuzer geworden maar ze hebben nog een lange weg te gaan.
Beste zou zijn om net als Python 3.0 een compleet nieuwe versie uit te geven die compleet niet terugwaarts compatible is en dan alle troep en inconsistentie functienamen er uit te gooien.
04-05-2012, 13:30 door [Account Verwijderd]
[Verwijderd]
04-05-2012, 13:33 door [Account Verwijderd]
[Verwijderd]
04-05-2012, 14:58 door dutchfish
Dit zou eigenlijk wel een hoger Gna..Gna..gehalte verdienen. Of niet soms?

In ieder geval dit: http://www.hardened-php.net/

Chears
04-05-2012, 15:32 door [Account Verwijderd]
[Verwijderd]
05-05-2012, 10:37 door [Account Verwijderd]
[Verwijderd]
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.