Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 56 reacties
Submitter: Boboga

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.

PHPOmdat alleen PHP-installaties die php-cgi gebruiken of via een cgi-wrapper draaien kwetsbaar zijn, valt de impact mee: vaker wordt PHP als Apache-module of via fastcgi geconfigureerd. Wel gebruiken sommige shared hosting-providers nog de - overigens weinig efficiënte - php-cgi-implementatie of cgi-wrappers.

De ict-beveiligingsorganisatie van de Amerikaanse overheid waarschuwt dat hackers gevoelige informatie kunnen binnenhalen, een denial of service kunnen veroorzaken of eigen code kunnen uitvoeren. Bovendien is er nog geen officiële oplossing voor het probleem, hoewel het PHP-team aan een patch zou werken.

Kwetsbare PHP-installaties kunnen eenvoudig worden misbruikt: command line-argumenten kunnen als query string worden meegegeven. Om bijvoorbeeld de broncode van 'index.php' integraal uit te draaien, is het opvragen van '/index.php?-s' voldoende.

De kwetsbaarheid is begin januari ontdekt door De Eindbazen, een groep beveiligingsonderzoekers. Aanvankelijk werd door de groep geheimhouding beloofd, maar toen een PHP-ontwikkelaar de bug-report per ongeluk integraal publiceerde, besloten De Eindbazen om hun ontdekkingen uit de doeken te doen. Tevens hebben ze twee patches vrijgegeven.

Ook websites die onder PHP's safe_mode draaien, wat bij veel shared hosting-providers het geval is, zijn kwetsbaar als ze onder een cgi-wrapper draaien. Wel kunnen onder cgi5 bepaalde omgevingsvariabelen verhinderen dat er code wordt uitgevoerd - maar dat is volgens De Eindbazen eenvoudig te voorkomen.

Opvallend is dat PHP tot 2004 ingebouwde beveiliging bevat om uitvoeren van code via de command line tegen te gaan, maar dat die naderhand is verwijderd. Tegelijkertijd doet de officiële documentatie van PHP nog steeds voorkomen alsof die beveiliging is ingebouwd.

Moderatie-faq Wijzig weergave

Reacties (56)

Het lek was begin januari door de Eindbazen ontdekt, een groep Nederlandse hackers. De kwetsbaarheid werd op 17 januari aan PHP gerapporteerd, inclusief een mogelijke update. Op 1 februari had PHP nog steeds niet gereageerd. De hackers wilden daarom het proces via het Computer Emergency Response Team (CERT) van CERT.org laten lopen.

Op 23 februari werd het CERT ingelicht, waarbij er op 5 april om een statusupdate werd gevraagd. In een reactie liet het CERT weten dat PHP nog aan een update werkte. Op 20 april vroegen de hackers het CERT om het lek te openbaren, tenzij er op korte termijn een update zou verschijnen. Een week later was het CERT inderdaad met een advisory bezig.

Op 2 mei bleek dat PHP een patch aan testen was, maar de ontwikkelaars meer tijd nodig hadden. De Nederlandse hackers gingen daarmee akkoord en wilde het openbaren van het lek uitstellen, totdat iemand bij PHP vandaag per ongeluk het lek openbaarde.

De lek is trouwens hier volledig te bestuderen: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/

Extra informatie: http://www.kb.cert.org/vuls/id/520827

Diegene die FastCGI gebruiken hebben dit probleem echter niet, die zijn veilig! Het probleem zit hem echter in de plain CGI... :Y)

[Reactie gewijzigd door Unflux op 3 mei 2012 18:12]

Dit is apart, iemand die ik ken had dit op fast-CGI geprobeerd, en jawel.... vatbaar voor deze bug....
Welke informatie in je post stond nog niet in het artikel / de originele link?
Ik gebruik fastcgi op mijn lighttpd server. Die gebruikt dan toch ook de CGI wrapper? Waarom is volgens het artikel de fastcgi wrapper niet kwetsbaar? Of ben ik toch kwetsbaar?
Zoals de website van 'De Eindbazen' vermeld:
FastCGI installations are not vulnerable
http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
Fast CGI werkt via het nabootsen van een standard input / output / environment variabelen via een socketconnectie. De CGI executable wordt eenmaling gestart en luistert op de socket naar CGI calls.
Mocht daar, door een bug, een command line gegenereerd worden die per ongeluk iets anders start dan de bedoelde cgi executable, dan komt die niet bij de shell terecht, maar gaat deze alsnog de CGI executable in.
Via CGI wordt invoer van de webserver naar de applicatie gestuurd via de environment, command line arguments, en standard input. Die command line arguments zijn concreet het probleem hier: de PHP developers hebben er niet aan gedacht dat command line arguments in een CGI script via een HTTP request van een onbetrouwbare gebruiker afkomstig kunnen zijn.

Via FastCGI wordt echter alle request-informatie via een UNIX socket ontvangen; de command line arguments van de FastCGI binary kunnen dus niet via een HTTP request beÔnvloed worden. Vandaar dat FastCGI niet vatbaar is voor deze (en enkele andere) potentiŽle problemen.
Test het gewoon? Probeer index.php?-s en als je je broncode ziet heb je een probleem ;)
Omdat de FastCGI implementatie anders in elkaar zit dan de "klassieke" CGI wrappers
Als je CGI gebruikt, ben je in principe kwetsbaar. Het is in theorie mogelijk om een veilige CGI oplossing te implementeren, maar het hele mechanisme is 'gebrekkig' in vergelijking met andere alternatieven, en daarnaast nooit ontworpen met 'security' als uitgangspunt. CGI heeft dan ook een geschiedenis vol exploits, backdoor, configuratie-problemen, etc.

Je bent dus, vanuit een security-standpunt bekeken, altijd beter af/veiliger door een niet-CGI alternatief te gebruiken.

[Reactie gewijzigd door tofus op 3 mei 2012 15:17]

fastcgi is dus niet hetzelfde als cgi. Met fastcgi ben je voor deze exploit veilig.
Die timeline is trouwens dramatisch:

13-01: Vulnerability discovered, used to pwn Nullcon Hackim 2012 scoreboard
13-01: We discuss the issue with Nullcon admins, find out it is a php 0day
17-01: We contact security@php.net with a full report and a suggested patch
01-02: We ask PHP to confirm receipt, state our intent to hand off the vulnerability to CERT if progress is not made
01-02: PHP forwards vulnerability report to PHP CGI maintainer


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

Happy patching all....

[Reactie gewijzigd door AW_Bos op 3 mei 2012 20:33]

Omdat alleen php-installaties die een klassieke cgi-wrapper gebruiken kwetsbaar zijn, valt de impact mee:
Wie anno 2012 nog steeds niet ergens op een webpagina is gestuit met daarin uitgebreidt de risico's van een cgi weboplossing beschreven, gebruikt het internet uberhaupt veel te weinig om er een webserver op te mogen hosten! Potjandorie! :o

Maar goed, wel weer ok dat zelfs deze categorie 'clueless'-people middels dit artikel nog even nadrukkelijk op de risico's wordt gewezen. Let echter wel: er zijn veel modernere, actuelere en meer dringende security issues met een veel grotere impact dan de bijna twintig jaar oude cgi meuk. Wellicht dan ook goed om daar aandacht aan te besteden?

[Reactie gewijzigd door tofus op 3 mei 2012 14:58]

Da's niet een probleem met CGI, maar met de PHP wrapper. CGI applicaties zijn niet magischerwijs meer of minder kwetsbaar voor bugs. Problemen treden pas op als interpreters die bedoelt zijn om door een vertrouwde gebruikers uitgevoerd te worden, aangeroepen kunnen worden met invoer die van een (onbetrouwbare) externe gebruiker afkomstig is.

De pagina van de Eindbazen hierover legt de fout dan ook terecht bij de PHP implementatie van hun CGI binary, en constateert dat het gedrag niet overeenkomt met de documentatie (waarin geclaimd wordt dat de CGI binary command line arguments negeert, wat inderdaad zou moeten).
Dringender issues dan een lek dat op een bepaald aantal systemen remote code execution toestaat? Goed, het publiek dat hinder ondervindt van deze bug zal klein zijn, maar die paar servers die er last van hebben, zullen er wel dermate veel last van kunnen hebben dat het behoorlijke problemen op kan leveren. Klantgegevens die op straat belanden, servers die een botnet joinen of in een warez- danwel kinderpornohost veranderen... Het probleem is wereldwijd gezien niet groot maar bij de affected installs is het wel dermate dringend om dit te fixen dat ik me niet voor kan stellen dat er veel grotere issues zijn om eerder te fixen.
Het probleem is wereldwijd gezien niet groot maar bij de affected installs is het wel dermate dringend om dit te fixen dat ik me niet voor kan stellen dat er veel grotere issues zijn om eerder te fixen.
Dat is dan eerder een probleem met jouw voorstellingsvermogen dan met mijn argumentatie. Simpele sqlinjections leveren voor een veel groter aantal websites nml. precies dezelfde problemen: het mogelijk maken van het uitvoeren van willekeurige code. En dit soort exploits treft dagelijks honderden zo niet duizenden websites. En naast sqlinjections zijn er dan nog stack-overflows etc.

Het probleem met insecure CGI oplossingen was zoals ik al zei al bijna twintig jaar bekend, en zal, vanwege de architectuur van het CGI concept, wat nooit is ontworpen met 'security' als uitgangspunt, ook weinig verbeteringen geven. Er zullen maar weinig gebruikers van CGI oplossingen zijn die zich hier niet heel bewust van zijn, en daardoor lijkt me deze issue een stuk minder relevant dan sqlinjections en stack-overflows in gebruikte hosting software.

Maar goed, zoals ik al aangaf: toch ook mooi dat deze laatste groep nog even expliciet gewaarschuwd wordt.

[Reactie gewijzigd door tofus op 3 mei 2012 15:18]

SQL-injecties moeten niet door Zend/PHP zelf gefixt worden maar door de makers van de websites in kwestie. Dat zijn fouten op een geheel ander niveau dan dit specifieke probleem waar iedereen die PHP-CGI draait last van heeft, zonder uitzondering. Goede developer of niet, je hebt die kwetsbaarheid en kan er niks aan doen behalve een niet-officiŽle patch installeren.

SQL-injecties zijn sowieso over het algemeen minder erg dan remote code execution. Bij remote code execution heb je namelijk dezelfde nadelen die een SQL-injectie ůůk heeft omdat je de wachtwoorden van de database ermee kan achterhalen, met het bijkomende nadeel dat het naast de database-server ook de webserver kwetsbaar maakt.

Dus nogmaals: er zijn voor Zend/PHP weinig issues die net zo dringend zouden moeten zijn om te fixen als deze. Het feit dat specifieke site-eigenaren en/of programmeurs ook hun eigen problemen kunnen veroorzaken staat daar geheel los van.

Hou bovendien in het achterhoofd dat de mensen die gebruik maken van PHP-CGI niet altijd evenveel daarvan op de hoogte zijn. Er zijn vast nogal wat gratis of goedkope hostingpartijen die dat draaien en de mensen die dat soort goedkope diensten gebruiken zijn helemaal niet zo op de hoogte van de zwakheden erin, of zelfs maar van het feit dŠt het op die server zo werkt. Die installeren gewoon hun WordPress-blogje of Joomla-site, zien dat het werkt en zijn tevreden.

[Reactie gewijzigd door NMe op 3 mei 2012 15:57]

Gewoon geen PHP-CGI draaien. Is sowieso al flink achterhaald.
weet jij een goeie manier om php te draaien op een shared hosting omgeving, waarbij alle php processen onder de uid van de owner draaien? cgi+php+suexec+apache is een mooie oplossing daarvoor namelijk.

Overigens, als ik gewoon #!/usr/bin/php als shell in mijn script zet, en het gewoon als cgi draait is het helemaal niet vatbaar voor deze bug, ik bepaal dan namelijk zelf de parameters die ik aan php meegeef ;)
weet jij een goeie manier om php te draaien op een shared hosting omgeving, waarbij alle php processen onder de uid van de owner draaien? cgi+php+suexec+apache is een mooie oplossing daarvoor namelijk.
O.a. FastCGI, dat niet vatbaar is? :?
Overigens, als ik gewoon #!/usr/bin/php als shell in mijn script zet, en het gewoon als cgi draait is het helemaal niet vatbaar voor deze bug, ik bepaal dan namelijk zelf de parameters die ik aan php meegeef ;)
Mja, maar dat zit ook (bijna per definitie) niet aan het web, dus kan een GET-parameter sowieso geen issue zijn.
nja bijna maar niet helemaal, heb het hier namelijk draaien als cgi met suexec ;) Maar het is opzich geen toepasasing die publiekelijk beschikbaar is.
Wat denk je van mod_ruid? Dan kun je gewoon cli draaien en elke website onder zijn eigen user.

[Reactie gewijzigd door TJVB op 3 mei 2012 16:20]

suPHP, FastCGI, mod_ruid, etc.
Die conclusie had ik allang getrokken. Maar sommige mensen hebben dus "geen keuze" omdat ze bij een goedkope hoster zitten en te weinig kennis van zaken hebben om Łberhaupt te zien dat PHP-CGI er draait, laat staan om te weten wat de implicaties daarvan zijn.

Zie ook de post van Mental hieronder.

[Reactie gewijzigd door NMe op 3 mei 2012 15:38]

Even voor de duidelijkheid, het gaat hier dus alleen om oude cgi oplossingen. suPHP werkt ook onder CGI. En die wordt nog veel gebruikt en aangeraden. En is hier ook niet vatbaar voor.
Goede developer of niet, je hebt die kwetsbaarheid en kan er niks aan doen behalve een niet-officiŽle patch installeren.
..Of je verdiepen in de bestaande ervaringen van beveilingsexperts die al letterlijk twintig jaar aangeven dat CGI geen veilige methode is om een website onder te draaien, en er bij je leidinggevende op aandringen dat jullie online-security eindelijk naar de 21ste eeuw wordt getrokken.

Als je in de afgelopen twintig jaar niet de tijd of mogelijkheid hebt gehad om de benodigde aanpassingen te maken, dan is dat heel triest natuurlijk, maar imho gewoon een gevalletje 'slecht security beleid'. Ik kan security-related issues met CGI oplossingen dan ook niet echt als serieus probleem zien.

Net zo min als dat ik de milieu-onvriendelijkheid en passagiers-veiligheid van een Trabant (volledig random voorbeeld) niet als een serieus probleem kan zien. Niet omdat een Trabant niet milieu-onvriendelijk of onveilig is, maar simpelweg omdat er te weinig trabant-rijders zijn om dit een serieuze issue te maken, en omdat de Trabant technisch inmiddels zo vreselijk achterhaald is, dat het nauwelijks een 'recente' issue genoemd kan worden. En toch rijden er nog steeds mensen rond in die dingen.

Imho geldt hetzelfde voor iemand die nu nog productie-servers met een standaard CGI-oplossing draait, en zich verbaasd dat dit regelmatig security-issues geeft.

[Reactie gewijzigd door tofus op 3 mei 2012 17:01]

Knappe jongen die KPN had kunnen overtuigen om php5 als fastcgi te draaien / php4 niet meer te supporten (om maar geen php5 cgi truuk uit te halen) zonder het bestaan van deze bug.
Wat je roept klopt allemaal wel maar een klap van de molen die realisme heet heb je klaarblijkelijk nog niet gehad.
een klap van de molen die realisme heet heb je klaarblijkelijk nog niet gehad.
Lol, je brengt 't bijna alsof het krijgen van een klap van een molen 'a good thing' is... ;)
Knappe jongen die KPN had kunnen overtuigen om php5 als fastcgi te draaien / php4 niet meer te supporten
Ik wil best nogmaals herhalen wat ik zei, maar dan toegepast op jouw voorbeeld: Als KPN al twintig jaar met een op security gebied gebrekkige oplossing werkt, en end-of-life producten als PHP4 inzet in productie-omgevingen, zonder zelf de capaciteit in huis te hebben voor interne audits en de bijbehorende beveilings-patches, dan is dat meer een issue van 20 jaar slecht security beleid van KPN zelf dan van een neipende issue die ons allemaal aangaat. En daar mag je als werknemer van KPN imho best je leidinggevende op aanspreken. Sterker nog: als goede ICT'er heb je feitelijk de 'plicht' om 't te doen, want als jij het als KPN'er niet doet als onderdeel van je werk, dan doet een hacker het straks over vijf jaar als onderdeel van z'n hobby. Met alle schade van dien.

Ik zie niet in wat realisme of irrealisme hier mee te maken heeft, overigens. En gezien het feit dat ik al wat jaartjes meedraai in de ICT, blijken mijn realistische en rationele capaciteiten in ieder geval afdoende voor functioneren in de praktijk. Maar mijn geestelijke gesteldheid terzijde: laten we on-topic blijven, vindt je niet?

[Reactie gewijzigd door tofus op 3 mei 2012 18:53]

Zelfs op Facebook wordt je er over gewaarschuwd ;)
Ai, dat is wel heel erg slordig. Vreemd ook dat de bug al maanden bestaat maar nog steeds niet verholpen is; je zou verwachten dat dit relatief simpel op te lossen is, zeker als de beveiliging vroeger wel aanwezig was - en De Eindbazen posten ook een patch ervoor die effectief genoeg lijkt.

Het geeft ook weer mooi aan waarom je code hoort te documenteren:
As far as I can tell this wouldn't conflict with anything, but somebody at some point must have had a reason for disallowing this.
Hierom dus, Rasmus ;)
de bug bestaat niet al maanden, hij bestaat al 8 jaar!
Mea culpa; ik bedoelde natuurlijk dat de bug al maanden bekend is :)
99 maanden; dat zei 'ie toch? :P
KPN bied met zijn software online oplossing ook webhosting aan.. mag jij raden hoe php5 geimplementeerd is: als cgi module.
Zit net dus ook vrolijk naar de source van mijn eigen php scripts te kijken via mijn webbrowser.
it's not a bug, it's a feature ... kan je altijd nog de bron terugvinden ;)

Natuurlijk niet leuk en te hopen dat men het gat snel dicht. Zeker bij zulke grote bedrijven weet je nooit of het snel zal gaan danwel lang kan duren.
Lek is gemeld bij KPN, nu maar afwachten wanneer er wat mee gebeurt en wŠt er mee gebeurt.
Als php5 op deze manier blijven aanbieden dan kon het nog wel eens een vervelend verhaal voor ze gaan worden.
Ben ook aan het melden....

Het is bevestigd door de support, er wordt aan gewerkt _O_

[Reactie gewijzigd door AW_Bos op 3 mei 2012 17:34]

Zojuist vernomen dat KPN vandaag gaat overschakelen naar FastCGI
Bovendien is er nog geen officiŽle oplossing voor het probleem, hoewel het php-team aan een patch zou werken.
Als mensen nu nog PHP-CGI gebruiken, acht ik de kans klein dat men Łberhaupt de patch zal installeren. PHP-CGI is - zoals reeds gemeld in de tekst - niet efficiŽnt en lijkt het me daardoor dat potentiŽle slachtoffers verouderde software gebruiken (om wat voor reden dan ook). Dit laat dus wel het belang van updaten zien. :)
Er zijn meerdere redenen om php5 als cgi te draaien, bijv. om php4 ernaast te kunnen ondersteunen in 1 webhosting omgeving.
Updaten is leuk, maar php5-cgi wordt nog steeds ondersteund en is dus vatbaar voor een bizar eenvoudig misbruikbare bug.
Als je nu nog PHP4 aanbied hoef je je echt niet druk te maken over deze bug, je bent dan toch al kwetsbaar voor tientallen andere security leaks.. PHP4 is al ruim 4 jaar niet meer ondersteund, en de laatste security fix is vandaag exact 5 jaar oud...
Dan kun je je afvragen waarom je in vredesnaam een niet meer ondersteunde versie van PHP wilt gebruiken op een productieserver. PHP 4 wordt al sinds 2008 niet meer ondersteund.
Complexe grote, legacy websites die door wat voor reden dan ook niet (kunnen) worden herschreven.
In 4 jaar tijd niet kunnen worden herschreven? Dan doe je toch echt iets grondig fout en verdien je het om getroffen te worden door exploits als deze...

Software gebruiken die geen ondersteuning/security patches meer ontvangt gedurende 4 jaar in een productieomgeving is gewoon een onvergeeflijke fout. PHP5 is al 8 jaar beschikbaar en de EOL van PHP4 is ruimschoots op tijd aangekondigd. Best als je het wil blijven gebruiken maar dan moet je de consequenties ervan ook maar nemen.
Complexe grote, legacy websites die door wat voor reden dan ook niet (kunnen) worden herschreven.
Meeste grote websites (zie deze site bijvoorbeeld) regelen hun eigen hosting wel, hebben daar dan ook het geld voor. Enig nut om dan je website te laten hosten lijkt me dan ook niet fijn voor de hostende partij.
Zeker als het "complex" is wil je ook je eigen servers in beheer hebben en zo optimaal als mogelijk voor de website ingesteld hebben, bij een (shared) hosted omgeving is dat verre van optimaal, dan wŪl je bijvoorbeeld gťťn PHP4 nŠŠst PHP5 kunnen draaien.
Er zijn meerdere redenen om php5 als cgi te draaien, bijv. om php4 ernaast te kunnen ondersteunen in 1 webhosting omgeving.
Updaten is leuk, maar php5-cgi wordt nog steeds ondersteund en is dus vatbaar voor een bizar eenvoudig misbruikbare bug.
Zoiets doe je al vrij lang met FastCGI, dat is veilig. Tegenwoordig kan je gewoon de FastCGI process pool laten beheren door PHP zelf (met de meegeleverde FPM daemon), en hoeft je web server alleen nog maar verzoeken door te sturen zonder dat deze op wat voor manier dan ook invloed heeft op de PHP opties.

PHP als klassiek CGI laten draaien doen alleen nog mensen die minder verstand hebben dan een pinda. Het is extreem inefficiŽnt ook nog.

[Reactie gewijzigd door Sfynx op 3 mei 2012 22:55]

Jeej Eindbazen, niet zo zeer "beveiligingsonderzoekers" als CTF pwners! ;)
"Kwetsbaar voor een bug" is een rare bewoording; de bug zit in de code of niet. Kwetsbaar voor een exploit (vanwege die bug) lijkt mij correcter.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True