Nederlands CTF-team Eindbazen werd op 3 mei wereldnieuws toen een zeer ernstig beveiligingslek in PHP per ongeluk openbaar werd gemaakt. De kwetsbaarheid in de zeer populaire scripttaal was al in januari door het team ontdekt, maar de ontwikkelaars hadden in mei nog altijd geen update klaar. Door een fout werd het lek in de bugtracker van PHP opeens voor iedereen openbaar, inclusief alle details.

Toen die details online verschenen besloot Eindbazen de details vrij te geven. PHP kwam een dag later met een update, maar die bleek niet te werken. Dit werd echter niet op officiele PHP-website gemeld. Pas drie dagen na het verschijnen van de update verscheen het bericht dat de patch defect was. Uiteindelijk verscheen op 8 mei een werkende patch. Security.nl interviewde Eindbazen, hieronder het eerste deel.

Hoe hebben jullie het lek precies gevonden.
Eindbazen: Het lek is eigenlijk per toeval ontdekt. Tijdens de Nullcon HackIM CTF competitie was er een opdracht om de output van een bekende vulnerability scanner, genaamd Nikto (CIRT.org), te analyseren. Bij een zekere zijstraat in het oplossen van de challenge is deze tool tegen de CTF-website gebruikt en daarbij kwam de bug naar voren in een ongerelateerd test-patroon waarin -s voorkwam.

Nadat we onszelf een onhaalbaar aantal punten in het scoresysteem hadden toebedeeld hebben we contact opgenomen met de beheerders van de CTF-competitie. De beheerders hebben vervolgens het probleem verholpen en ons de door hen gebruikte Apache configuratie gegeven om verder te testen, evenals een eervolle vermelding boven het scoreboard. De details over de bug (aangaande Apache, de CGI RFC, PHP changelog en dergelijke) zijn door verschillende mensen in het team nagezocht om het plaatje compleet te maken, waarna patches en advisories ook in teamverband zijn opgesteld.

Hoe kan het dat niemand dit in de afgelopen 7 jaar heeft opgemerkt/ gerapporteerd?
Eindbazen: Wellicht dat het in ondergrondse kringen bekend was, maar het heeft in ieder geval 7 jaar geduurd voordat het gerapporteerd is. Het was voor ons ook een grote verrassing, maar de bug gaat uit van een specifieke setup, die op de meeste omgevingen niet meer gebruikt wordt.

De reactie/communicatie van PHP kwam niet echt professioneel over. Daarnaast duurde het patchen wel heel erg lang. Wat maken jullie
daarvan als onderzoekers / PHP-programmeurs?
Eindbazen: Het is erg jammer dat PHP ons niet serieus leek te nemen. Wij hebben er alles aan gedaan om deze bug zo verantwoord mogelijk openbaar te maken, helaas kostte het PHP nogal lang om op onze melding in te gaan en het probleem op te lossen. Wij kunnen ons ook goed voorstellen dat andere partijen minder geduld met PHP zouden hebben gehad.

De houding van PHP maakt het er niet makkelijker op om een dergelijke bug op een nette wijze naar buiten te brengen. Helaas bestaat het core PHP ontwikkelteam alleen uit vrijwilligers, waardoor het voortdurend onderbemand is voor zulke zaken. In het algemeen zijn security features van software iets waar achteraf aan gedacht wordt, en in PHP lijkt dit niet anders te zijn.

Waarom werkte de eerste patch niet? Was deze update niet goed getest of was er bij PHP onvoldoende kennis over de werking van het lek?
Het lijkt er sterk op dat PHP de bug pas serieus begon te nemen op het moment dat de bug geopenbaard dreigde te worden via CERT, er waren toen al 3 maanden verstreken sinds onze eerste melding. We hebben vervolgens PHP extra tijd gegeven, tot 17 Mei, zodat ze hun patch goed konden testen. Toen ze per ongeluk zelf de bug publiceerden, konden ze niet anders dan snel met een fix komen, de bug was immers zo triviaal te exploiten.

De patch zal toen waarschijnlijk door te weinig mensen getest zijn. Een van onze Proof-of-concept aanvallen die we naar PHP opgestuurd hebben werd zelfs niet gestopt door de eerste patch. Afgaande op de documentatie van PHP was men zich bewust van deze bug, maar zoals uit de mailinglist-conversatie blijkt is deze kennis over tijd vervaagd of misschien zelfs verloren gegaan. Het is raar dat de PHP developers ook hun eigen documentatie niet lijken te kennen. Dat geeft ons het gevoel dat deelname in het project nogal vrijblijvend wordt bedreven.

Wat zou je PHP adviseren als het gaat om meldingen van beveiligingsonderzoekers, maar ook wat het kan doen om de eigen code
veiliger te maken?
Eindbazen: PHP zou de community om sponsoring kunnen vragen voor security taken / bounties. Daarnaast zou het al een heel stuk beter zijn als PHP meldingen van security onderzoekers serieus nam en deze meldingen niet onnodig lang laat liggen.

Maandag het tweede deel van het interview met de Eindbazen - inmiddels online verschenen