image

Ernstig PHP-lek per ongeluk openbaar gemaakt

donderdag 3 mei 2012, 11:52 door Redactie, 35 reacties

Een zeer ernstig beveiligingslek in de populaire scripttaal PHP waavoor nog geen patch is, is per ongeluk door het ontwikkelteam geopenbaard, waardoor miljoenen servers risico lopen om gehackt te worden. Via de PHP-CGI query string parameter kwetsbaarheid is het mogelijk om een remote shell te krijgen en op afstand willekeurige code uit te voeren.

Wie PHP met behulp van CGI draait is kwetsbaar, ongeacht wat het PHP-script doet. Veel hostingproviders zouden deze opstelling gebruiken.

De kwetsbaarheid was bij PHP aangemeld en in de bugtracker opgenomen. Door een fout van het PHP-ontwikkelteam was de bugmelding voor iedereen zichtbaar. Inmiddels is de kwetsbaarheid weer op privé gezet, maar de informatie is nu ook online te vinden. Op dit moment is er nog geen beveiligingsupdate beschikbaar.

Update 12:12
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.

Impact
"De impact is groot. Er is momenteel geen fix vanuit PHP beschikbaar en het geeft remote code execution op kwetsbare servers. Daarnaast kan eenvoudig de broncode van elk PHP-script gelezen worden", aldus een woordvoerder van de Eindbazen tegenover Security.nl. Op het blog van de groep zijn verschillende onofficiële patches verschenen.

"Deze zouden geïnstalleerd kunnen worden totdat er een update van de leverancier komt. Onze updates kunnen mogelijk bepaalde opstellingen breken. Een andere optie is om tijdelijk servers uit te zetten, totdat er een fix beschikbaar is."

Wat betreft de blunder aan de kant van PHP is de woordvoerder ontsteld. "Dit had nooit mogen gebeuren natuurlijk. De fout is snel gecorrigeerd maar toen was het kwaad al geschied. Iemand heeft vervolgens de bugmelding gekopieerd en online gezet. Een fout is natuurlijk menselijk, maar deze kan grote gevolgen hebben", aldus de woordvoerder.

Reacties (35)
03-05-2012, 12:01 door DanielG
Zozo, grote impact. Niet slim om zomaar zonder patch al te posten.
03-05-2012, 12:06 door regenpijp
He, die kwam op het IRC-kanaal voorbij. Lek is door de Eindbazen gevonden.
03-05-2012, 12:12 door Anoniem
ik denk dat ik mijn internet ga opzeggen.
03-05-2012, 12:39 door [Account Verwijderd]
[Verwijderd]
03-05-2012, 12:43 door Anoniem
"People have been asking whether FastCGI servers are vulnerable. The answer is no, this vulnerability applies only to classic CGI."
03-05-2012, 13:18 door [Account Verwijderd]
[Verwijderd]
03-05-2012, 13:48 door Anoniem
Meer een Apache/PHP combi probleem. Apache shell script escaped niet de meegegeven variablen. XS-HTTPD heeft er bijvoorbeeld geen last van.
03-05-2012, 13:53 door Anoniem
dit is geen hoax, heb het getest en op sommige servers is het probleem te reproduceren.
03-05-2012, 13:53 door [Account Verwijderd]
[Verwijderd]
03-05-2012, 14:05 door Anoniem
Ook hier reproduceerbaar, meteen de bende gepatched.
03-05-2012, 14:07 door [Account Verwijderd]
[Verwijderd]
03-05-2012, 14:12 door Anoniem
Als mensen hier het probleem kunnen reproduceren, geef dan ajb ook de gebruikte versies van software aan (bijv. apache-versie, lighttpd-versie, type cgi, versie php). Dat geeft toch iets meer een indicatie van waar het nou allemaal wel en niet speelt, want er worden nogal wat tegenstrijdige dingen over dit beveiligingsgat genoemd.
03-05-2012, 14:16 door Anoniem
Door Hugo:
Door Anoniem: dit is geen hoax, heb het getest en op sommige servers is het probleem te reproduceren.
Maar zit het probleem dan niet in de gebruikte webserver in plaats van PHP? Ik gebruik zelf geen Apache en krijg het met geen mogelijkheid gereproduceerd...
Nee, apache houdt zich aan de RFC. Als andere webservers niet vulnerable zijn betekend dat dat ze zich niet aan de RFC houden. De vuln ligt wel degelijk bij PHP, zij moeten er vanuit gaan dat de variabelen unescaped bij de webserver vandaan komen.

Lees de blogpost even, daar staat precies in hoe en waarom het vulnerable is.
03-05-2012, 14:16 door [Account Verwijderd]
[Verwijderd]
03-05-2012, 14:30 door Anoniem
http://www.kb.cert.org/vuls/id/520827
03-05-2012, 14:39 door DanielG
Door Hugo: Ook vreemd dat websites zoals exploit-db.com en secunia.com er niks over zeggen...
De United States Computer Emergency Readiness Team wel (http://www.kb.cert.org/vuls/id/520827), zo beter?

Door Hugo: ....Ik gebruik zelf geen Apache en krijg het met geen mogelijkheid gereproduceerd...
van de blog:
SECOND NOTE: This problem only exists on server software that implements the rfc3875 behavior described above. Apache does this, but many other HTTP servers do not.
03-05-2012, 14:43 door [Account Verwijderd]
[Verwijderd]
03-05-2012, 15:06 door DanielG
Door Hugo: Rustig maar. Ik val je niet aan... Is iedereen een beetje cranky vandaag?
Rustig maar, ik heb al je post een duim omhoog gegeven ;).
03-05-2012, 15:38 door Vergeten
Naja ik gebruik Apache en PHP5, echter als ik deze methode op mijn eigen site gebruik zie ik gewoon de normale pagina..

Kan iemand misschien voorbeeld geven, doel ik dus simpele page op je eigen of gratis hosting. Ben namelijk wel eens nieuwsgierig.
03-05-2012, 15:41 door Anoniem
Er valt weinig te zien en beleven.
Parameter ?-s geeft bij een doelsysteem de broncode inbeeld i.p.v. de pagina zelf.
03-05-2012, 15:44 door Anoniem
Het zit em in het PHP-CGI component. Dit is niet default meegeleverd bij PHP en dien je los te installeren. Als je dat dus niet hebt ben je ook niet kwetsbaar.
http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
http://www.kb.cert.org/vuls/id/520827
03-05-2012, 15:46 door Anoniem
Door Vergeten: Naja ik gebruik Apache en PHP5, echter als ik deze methode op mijn eigen site gebruik zie ik gewoon de normale pagina..

Kan iemand misschien voorbeeld geven, doel ik dus simpele page op je eigen of gratis hosting. Ben namelijk wel eens nieuwsgierig.
Je moet wel php-cgi gebruiken, dat is niet standaard. Verder denk ik niet dat iemand een link gaat posten want je geeft iemand shell op je server.
03-05-2012, 16:00 door S-q.
+ en - veelrood en een beetje groen: mooie kleurtjes.

Is er een troll??

Voor mij nu min 2 dus( ;-))
03-05-2012, 16:01 door [Account Verwijderd]
[Verwijderd]
03-05-2012, 16:14 door Preddie
Hugo, volgens mij moet je de waardering op deze site niet erg geloofwaardig beschouwen. Ik zelf vraag me wel eens af of ik een post moet beoordelen op wat ik er van vind of dat ik de post een bijdrage vind in de discussie .......
03-05-2012, 16:45 door DanielG
Door Anoniem: Er valt weinig te zien en beleven.
Parameter ?-s geeft bij een doelsysteem de broncode inbeeld i.p.v. de pagina zelf.

Waar dus ook database wachtwoorden instaan en als je de Eindbazen blog leest kom je erachter dat je met deze kwetsbaarheid ook code executie krijgen. Niet echt "weinig te zien en beleven".
03-05-2012, 16:54 door Anoniem
Door Anoniem:
Door Vergeten: Naja ik gebruik Apache en PHP5, echter als ik deze methode op mijn eigen site gebruik zie ik gewoon de normale pagina..

Kan iemand misschien voorbeeld geven, doel ik dus simpele page op je eigen of gratis hosting. Ben namelijk wel eens nieuwsgierig.
Je moet wel php-cgi gebruiken, dat is niet standaard. Verder denk ik niet dat iemand een link gaat posten want je geeft iemand shell op je server.

Ik vraag mij meer af hoeveel mensen Apache + PHP-CGI draaien, vooral als je voor PHP-CGI of PHP-FPM gaat dan gebruikt men vaak een alternatieve webserver zoals Nginx/Cherokee/Lighttpd.

Wat is de probability van dit ding eigenlijk?
03-05-2012, 17:03 door SirDice
Door DanielG:
Door Anoniem: Er valt weinig te zien en beleven.
Parameter ?-s geeft bij een doelsysteem de broncode inbeeld i.p.v. de pagina zelf.

Waar dus ook database wachtwoorden instaan en als je de Eindbazen blog leest kom je erachter dat je met deze kwetsbaarheid ook code executie krijgen. Niet echt "weinig te zien en beleven".
Dat noemen ze ook wel een gebrek aan fantasie ;)

Sommige mensen zien gaten niet, of begrijpen niet goed hoe je zoiets zou kunnen misbruiken. Legio mogelijkheden in dit geval, dat is zeker.
03-05-2012, 17:04 door Anoniem
@DanielG, dit was n.a.v. de bovenstaande reactie.
Als je enkel nieuwschierig bent maar geen systeem hebt wat mogelijk kwetsbaar is.
Valt er zoals aangegeven "weinig te zien en beleven".
03-05-2012, 17:09 door Vergeten
Door Anoniem:
Door Vergeten: Naja ik gebruik Apache en PHP5, echter als ik deze methode op mijn eigen site gebruik zie ik gewoon de normale pagina..

Kan iemand misschien voorbeeld geven, doel ik dus simpele page op je eigen of gratis hosting. Ben namelijk wel eens nieuwsgierig.
Je moet wel php-cgi gebruiken, dat is niet standaard. Verder denk ik niet dat iemand een link gaat posten want je geeft iemand shell op je server.

Ja klopt, ik heb even maar wat meer gezocht zodat het wat duidelijker is. Nee heb ook geen voorbeeld nodig meer, naja om excution deel te gebruiken zou ik toch eerst moeten weten hoe.

Zelf gebruik ik idd PHP als Apache Module, daarnaast dacht ik dat er FastCGI op zat. Heb eigenlijk vrij weinig gekeken naar mn nieuwste VPS die ik gebruik als hosting, zal thuis eens kijken.
03-05-2012, 17:16 door Anoniem
Het deel over de bug is net zo tendentieus als het artikel op Webwereld. Welke zichzelf respecterende provider gebruikt tegenwoordig nog plain CGI? Dat is allemaal hetzij FastCGI, hetzij een Apachemodule en die hebben dat probleem niet.
03-05-2012, 17:58 door Anoniem
De meeste mensen gebruiken fastcgi en je kan het geen eens bereiken als die normaal is ingesteld.
03-05-2012, 21:15 door [Account Verwijderd]
[Verwijderd]
04-05-2012, 09:48 door Anoniem
@hugo: ze zouden apache dan gewoon in een jail moeten draaien
04-05-2012, 11:44 door Anoniem
https://www.facebook.com/?-s
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.