'Patch voor ernstige PHP-bug helpt niet'

De officiële fix voor een ernstige bug in PHP werkt nauwelijks. Dat stellen de ontdekkers van de bug, die het mogelijk maakt om command line-argumenten naar PHP te sturen op installaties die php-cgi of php in een cgi-wrapper gebruiken.

De beveiligingsonderzoekers die de bug ontdekten, een groep die zichzelf De Eindbazen noemt, adviseren om een van de twee door hen geschreven patches zelf door te voeren in de broncode. De officiële fix van PHP, die donderdag is vrijgegeven, is volgens de groep namelijk eenvoudig te omzeilen.

De bug maakt het mogelijk om command line-argumenten door te geven aan PHP, waardoor met het aanroepen van '/index.php?-s' bijvoorbeeld de broncode van een bestand kan worden gedumpt. Ook is het mogelijk om eigen code uit te voeren.

Alle installaties die php-cgi of PHP in een cgi-wrapper gebruiken, zijn kwetsbaar. Die implementatie wordt niet zo vaak meer gebruikt; veel PHP-installaties draaien via fastcgi of als een Apache-module. Sommige shared hosting-providers gebruiken de kwetsbare methode echter wel.

Het beveiligingsprobleem - dat al sinds 2004 aanwezig was - zou aanvankelijk pas geopenbaard worden wanneer er een fix beschikbaar was, maar nadat de bug per ongeluk was gepubliceerd, deden De Eindbazen hun ontdekking uit de doeken. Naar nu blijkt is de kwetsbaarheid gepubliceerd door een bug in de bugtracker van PHP.

Reacties (41)

[Spider.007]

Voor iedereen die zich afvraagt wat er mis is aan de patch; je kunt het '=' je encoden als %3D en dan kom je er alsnog doorheen...

De patch:

quote: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/

diff --git a/sapi/cgi/cgi_main.c b/sapi/cgi/cgi_main.c
index e6d011b..8e2d0ba 100644
--- a/sapi/cgi/cgi_main.c
+++ b/sapi/cgi/cgi_main.c
@@ -1809,7 +1809,7 @@ int main(int argc, char *argv[])
if(query_string = getenv("QUERY_STRING")) {
decoded_query_string = strdup(query_string);
php_url_decode(decoded_query_string, strlen(decoded_query_string));
- if(*decoded_query_string == '-' && strchr(decoded_query_string, '=') == NULL) {
+ if(*decoded_query_string == '-' && strchr(query_string, '=') == NULL) {
skip_getopt = 1;
}
free(decoded_query_string);

[Reactie gewijzigd door Spider.007 op 24 juli 2024 10:49]

[AugmentoR]

MUST READ ALS JE HIER ZELF LAST VAN HEBT:
In ieder geval even snel:


RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]


in je .htaccess zetten!

Geen garanties, en er is mogelijk wel weer een workaround voor, maar de wel heeel simpele index.php?-s werkt dan in ieder geval niet meer...

Uitleg voer de Rewrite: een '-' is alleen toegestaan als er ook een '=' in de query staat (%2d is alternatieve schrijfwijze voor -)

Zie ook https://bugs.php.net/bug.php?id=61910

[Reactie gewijzigd door AugmentoR op 24 juli 2024 10:49]

[SidewalkSuper]

Volgens onderzoekers op de pagina van De Eindbazen http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/ werkt deze "officiële" oplossing ook niet volledig.

Zie deze reacties:

May 3, 2012 at 8:02 pm
An “official” hotfix has been posted by rasmus in the comments of the bug-page
https://bugs.php.net/bug.php?id=61910
RewriteEngine on
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]

May 4, 2012 at 9:36 am
The ‘official’ one doesn’t work properly either. Does in some cases but not in others.

http://eindbazen.net/2012...e-2012-1823/#comment-1247

De échte oplossing voor het probleem op dit moment is schijnbaar dit:

RewriteEngine on

RewriteCond %{QUERY_STRING} ^[^=]*$

RewriteCond %{QUERY_STRING} %2d|\- [NC]

RewriteRule .? - [F,L]

http://www.php-security.n...2-1823-CVE-2012-2311.html

[Reactie gewijzigd door SidewalkSuper op 24 juli 2024 10:49]

[paul999]

En dan maar ook gelijk een andere host zoeken, aangezien CGI gewoon zwaar achterhaald is en niet meer gebruikt moet worden.

[tofus]

Ik weet dat klagen over beoordelingen beloond wordt met een instant 'offtopic-irrelevant' beoordeling, maar met dat risico op de koop toe: Ik vraag me werkelijk af waarom deze parent-post zo hoog scoort. Zitten we hier nu werkelijk met z'n allen een security-masturbatie feestje te houden over een technologie die twintig jaar geleden al zo lek als een mandje was, en welke door iedere ICT-engineer met een modicum aan security-kennis al twintig jaar sterk wordt afgeraden deze oplossing te gebruiken?

Zijn we allemaal dan zo dom geweest dat we twintig jaar niet naar deze experts hebben geluisterd, dat dit opeens zo'n hot item is?

Waarom is deze achterhaalde onzin nog zo actueel en populair dat deze nonsense niet een maar zelfs twee DRIE berichten (!!) op tweakers.net nodig heeft, en dat mensen die met een rewrite-asprientje repost komen een +4 beoordeling krijgen, terwijl mensen die al twintig jaar roepen dat je geen CGI moet gebruiken met een -1 irrelevant/off-topic worden weggemod?! Zijn er dan werkelijk zoveel tweakers die nog met deze achterhaalde technogie werken, en waar dit daadwerkelijk een zware impact heeft? En waarom in vredesnaam dan?!

En nee, ik probeer niet te trollen. CGI related security issues kom ik zelf nml. doorgaans al 10-12 jaar niet meer tegen in mijn dagelijkse werk. Ik ben dus werkelijk verbaasd.

[Reactie gewijzigd door tofus op 24 juli 2024 10:49]

[Blokker_1999]

Blijven editten tot je het goed krijgt

En nee, die patch die je post van de eindbazen is ook niet correct. Er circuleren ondertussen rapporten op het net dat ook die patch het probleem niet oplost. De originele patch van hen alsook de cgi wrapper die ze geschreven hebben lossen daarentegen het probleem wel op.

[Spider.007]

Ja, dat lijkt niet zo netjes. Ik dacht oorspronkelijk dat het streepje encoded kon worden, maar dat bleek een foutje in 1 specifieke rewrite-rule te zijn van 1 specifieke hosting-provider.

Vandaar de aanpassing, met later ter verduidelijking de patch erbij

[Reactie gewijzigd door Spider.007 op 24 juli 2024 10:49]

[Gtoniser]

Je vraagt je af waar ze bij PHP/Zend mee bezig zijn soms.
De laatste kritische bug die ze patchten (met de hash key dos kwetsbaarheid) had een nog ergere bug tot gevolg (kunnen uitvoeren van code).
Ook hier lijken ze weer de mist in te gaan.

[Makkelijk]

Zend heeft helemaal niets te maken met de ontwikkeling van PHP te maken hoor. Dat de engine van PHP4 een afstudeerproject van de oprichter van Zend was, meer dan een decennium geleden, verbind Zend niet aan PHP.
PHP wordt ontwikkeld en onderhouden door the PHP group, een groep vrijwilligers, basically community software.

[Reactie gewijzigd door Makkelijk op 24 juli 2024 10:49]

[elmuerte]

ZendEngine2 is het hart van PHP5. Verder zijn veel van de PHP Group members werknemers van Zend.

[Verwijderd]

De Zend Engine is wat de naam al doet vermoeden, een generieke engine die als 'motor' kan dienen voor allerhande programmeertalen. Dat -voor zover ik weet- PHP slechts de enige programmeertaal is die gebruik maakt van de Zend Engine, staat daar even los van.

Hoewel in de praktijk PHP en Zend natuurlijk bijna synoniem aan elkaar zijn, is PHP een zelfstandig initiatief dat gebruikt maakt van de engine.

Neemt niet weg dat die natuurlijk een vrij knullige bug is...

[bogy]

ik heb het in ieder geval eens getest op mijn forum en site ..

en die doen of er niets aan de hand is en sturen me terug naar dehomepage van dat forum/website.

als ik het doe op viewforum.php dan zegt die dat de pagina niet bestaat (hoe bizar ook) maar krijg ik dat wel met de forumlayout te zien... dus ik ga er vanuit dat mijn sie / hosting geen last ondervind van deze bug

[SidewalkSuper]

Sterker nog. De laatste kritische bug die ze patchten is helemaal niet gepatcht, omdat die patch het probleem niet verhelpt en dat probleem is zelfs nog steeds niet verholpen.

BTW: it does not look like PHP 5.3.12/5.4.2 that most probably will be released tomorrow will fix the broken HashDOS fix.

https://twitter.com/#!/i0n1c/status/198116784094724096

Deze nieuwe bug heeft ook het kunnen uitvoeren van code tot gevolg, alleen zijn dit keer alleen PHP-CGI systemen kwetsbaar.

@Blokker_1999 mijn opmerking (net als die van Gtoniser) gaat over de voorlaatste (als je deze nieuwe meetelt) kritische bug, de HashDOS bug, die was niet verholpen met de destijds uitgebrachte fix en is dus nog steeds niet verholpen.

[Reactie gewijzigd door SidewalkSuper op 24 juli 2024 10:49]

[Blokker_1999]

Euhm, waar denk je dat deze (en vorige) nieuwspost over gaan?

[crashmatrix]

Moet je voor de lol eens proberen naar https://www.facebook.com/?-s te gaan

[Blokker_1999]

Maar zeker niet op alle paginas.

[AW_Bos]

Haha, dit lijkt me meer een grapje van ze.

Waarom zou je anders op een index-pagina een vacature-pagina willen opvragen die verwijst naar een job om de veiligheid van Facebook te doen vergroten?

Leuk bedacht van Facebook....

[Wampa1]

Niet heel veel bekend over de ontdekkers, jammer. Goed gevonden wel.

[Rob]

Heel veel bekend over de ontdekkers: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/

[basvd]

Jawel hoor.., en T.net publiceerde begin dit jaar nog een artikel over deze "Eindbaas"...

[Reactie gewijzigd door basvd op 24 juli 2024 10:49]

[jabwd]

Geldt deze bug ook voor de combinatie php-fpm + nginx?

[_JGC_]

Nee, aangezien php-fpm met fastcgi werkt. Deze bug wordt getriggerd omdat je via CGI een startup-optie kunt meegeven aan PHP, bij fastcgi of fpm is het niet mogelijk om die opties door te geven aan de opgestarte PHP binary.

[borft]

bij fastcgi wordt de binary namelijk niet bij het request opgestart, maar "draait" al

[Gtoniser]

nee, het geld niet voor fastcgi

[Memori]

Hoewel iedereen hier het juiste antwoord op kan geven (zie post Gtoniser), kan het geen kwaad om het zelf even uit te proberen. Dan weet je het 100% zeker en leer je er mogelijk ook nog iets van.

Dat doe ik eigenlijk met alle ernstige bugs in PHP / Apache, zoals de recente Hash Collision bug en Slow Read exploit. Even zoeken naar de gebruikte tools / methodes, uitproberen op eigen (test/ontwikkel) servers en als je vervolgens vatbaar bent, opzoek gaan naar een fix.

[Blokker_1999]

Bijna 4 maanden, en dan nog een buggy patch releasen terwijl een werkbare oplossing direct werd gegeven door de ontdekkers van de bug.

[carlo]

Zoals in latere berichten al is gepost: de oplossing van de Eindbazen zelf had ook een zwakke plek.

[Verwijderd]

Tja, en waar ga je nu verhaal halen als zo'n open source product er de oorzaak van is dat al je gegevens op straat belanden.

[__fred__]

Ach bij Open Source heb je i.i.g. nog redelijk kans dat er af en toe een paar deskundige ogen naar de broncode kijken. Er staan dagelijks bedrijven op de frontpage met closed source producten die door de eerste sql injectionmand vallen.

En als het echt misgaat, zoals bij diginotar, zijn de aandeelhouders meer dan bereid om de assets er als een gek uit te trekken en de rest te laten ploffen. Nog voordat er uberhaupt een advocaat naar een schadeclaim heeft kunnen kijken.

[The Jester]

Een bug in de bug-tracker

[xiphoid]

Ja, want de ENIGE software in de wereld zonder een enkel bug, is de bug tracker zelf. Natuurlijk.

[The Jester]

Ik begrijp ook wel dat geen enkel pakket 100% veilig is, maar dit is toch écht zo'n WTF-momentje. Die laatste zin in het stukje is gewoon een uitsmijter. Ik heb er dubbel om gelegen. Voor de ontwikkelaars lijkt het mij de meest lullige plek waar zoiets voor kan komen.

[kamerplant]

Vermoedelijk draait de bug-tracker op PHP

[EzMe]

Jammer dat ik dat niet kan "Like-en" =)

[Ulster Seedling]

Off-topic: onder elk artikel zit de social sharing-balk waar gewoon een Like-button in the vinden is.

[EzMe]

Hmja.. bedoelde eigenlijk het grapje van facebook. Reactie op de verkeerde plek geplaatst..

[Verwijderd]

Ik draai hier Apache+PHP op Windows

Ik had dit in m'n httpd.conf

#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
ScriptAlias /php/ "C:/Applications/PHP/"
Action application/x-httpd-php "C:/Applications/PHP/php-cgi.exe"
PHPIniDir "C:/Applications/PHP/"
LoadModule php5_module "C:/Applications/PHP/php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL

heb het gewijzigd naar dit, ben ik nu safe wat deze bug betreft?:

#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
#ScriptAlias /php/ "C:/Applications/PHP/"
#Action application/x-httpd-php "C:/Applications/PHP/php-cgi.exe"
PHPIniDir "C:/Applications/PHP/"
LoadModule php5_module "C:/Applications/PHP/php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL

[arjankoole]

heb het gewijzigd naar dit, ben ik nu safe wat deze bug betreft?:

zo te zien lost dat je probleem wel op, ja. Maar het beste is altijd door het te testen, en dat doe je heel makkelijk door een php pagina in je site aan te roepen (bijvoorbeeld themajor.php):

http://www.themajor.nl/themajor.php?-s

die ?-s is het belangrijkste, als je de source van die pagina ziet, ben je nog niet gered, als je gewoon de gerenderde pagina ziet: je bent safe.

overigens was het sowieso redelijk weird, dat je die 2 door elkaar gebruikt.

[Reactie gewijzigd door arjankoole op 24 juli 2024 10:49]

[Verwijderd]

Bedankt! Als ik ?-s achter een php zet, krijg ik gewoon de pagina (geen source) gelukkig.

De php-installatie had inderdaad niet op 2 manieren in de config moeten staan. Dat had ik blijkbaar over het hoofd gezien bij de installatie en/of de php-installer heeft dit zelf erin gezet!

Edit: overigens werkte de exploit ook niet toen php-cgi.exe nog actief was. Misschien omdat de tweede methode door Apache voorrang krijgt.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:49]

[arjankoole]

Edit: overigens werkte de exploit ook niet toen php-cgi.exe nog actief was. Misschien omdat de tweede methode door Apache voorrang krijgt.

Eerder doordat de AddHandler statement in de apache configuratie alles met de .php extensie mapped aan de module, en niet aan de cgi. Alleen de module aanzetten, of de cgi, doet an sich nog weinig.

[pim]

Naar nu blijkt is de kwetsbaarheid gepubliceerd door een bug in de bugtracker van PHP.

Er zat een bug in de bugtracker? Maar goed dat de bug-tracker niet in een oneindige loop terecht is gekomen.