Het Nederlandse CTF-team Eindbazen dat een ernstig lek in de populaire scripttaal PHP ontdekte, ziet dit niet als het failliet van het open source-model. Dat laten de Eindbazen in een interview met Security.nl weten. Het lek in PHP bleef jarenlang onopgemerkt, wat volgens sommige critici aangeeft dat het idee van open source, dat de beschikbaarheid van broncode ervoor zorgt dat iedereen ernaar kan kijken en lekken snel worden ontdekt en verholpen, niet werkt.

Lees ook het eerste deel van dit interview

Wat zegt het lek over het idee van open source dat veel ogen de code kunnen inzien en het veilig maken?
Eindbazen: Het zegt dat ook open source projecten niet altijd veilig zijn. Het voordeel was wel dat we met de source de achterliggende oorzaak konden achterhalen en met de release ook patches konden meeleveren. Het is natuurlijk wel goed om te bedenken dat dit natuurlijk slechts één incident is en dat daaruit niet al te veel conclusies getrokken kunnen worden. Elk groot open source project heeft een community en sommige communities zijn zich meer bewust van veiligheidsrisico's dan anderen, dit is niet anders dan tussen softwareleveranciers.

Verder heeft open-source software het voordeel dat de gebruikers van de software de leveranciers niet hoeven te vertrouwen als het gaat om de kwaliteit van de code. Door de code kwaliteit te vergelijken kan een klant beter een oordeel vellen over welk stuk software waarschijnlijk veiliger is. Dan is er nog de vraag of je de leverancier wel wil vertrouwen, wie zegt dat er geen backdoor in jouw software zit?

Misschien is de leverancier wel gedwongen door een overheid om een achterdeur in jouw software te stoppen. Verder hoeft een getroffen gebruiker van kwetsbare open source software niet hopeloos af te wachten totdat een lakse vendor de bug fixt. Ook is het niet gezegd dat aanvallers geen toegang hebben tot de source code van closed source software.

De source van een closed software project hoeft maar een keer te lekken, zoals recentelijk bijvoorbeeld bij Norton gebeurde. Verder is het niet waar dat een aanvaller zonder beschikbare source helemaal in het donker tast. Als CTF team krijgen we geregeld kwetsbare binaries voorgeschoteld zonder source code en er zijn genoeg methodes om daarin de kwetsbaarheden na te gaan. Het is ook niet onhaalbaar om binary software updates na te gaan op de bugs die ze patchen, en daaruit de 'bruikbare' bugs te extraheren. Software updates maken ironisch genoeg de meest recente bugs voor het eerst publiek.

Wat zouden jullie systeembeheerders adviseren die servers beheren waar PHP op draait. Wat moeten ze bijvoorbeeld wel of niet instellen
om het veilig te houden?
Eindbazen: PHP is een taal die zich makkelijk laat oppakken door beginnende programmeurs, dus zoals de lezers van security.nl welbekend is, zitten de makkelijk te vinden bugs natuurlijk vaak in de PHP-code en niet in het PHP-platform. Het is daarom nuttig om automatische vulnerability scanners los te laten op de verschillende virtual hosts en, aangezien je als beheerder die mogelijkheid hebt, ook eens de broncode met een statische checker na te lopen op potentieel gevaar.

PHP security features zoals disable_functions, safe_mode en de Suhosin uitbreiding (die zich juist op security richt) waren niet bestand tegen deze bug, omdat het een bug in het platform betrof. Deze zijn normaal gesproken moeilijk op te sporen, maar de php-cgi bug was ondanks de eenvoud van misbruik blijkbaar nooit gepubliceerd. Het is een vrij obscure feature van CGI die alleen optreedt in een modus die nog weinig gebruikt wordt, terwijl de documentatie beweert dat PHP niet kwetsbaar is. De perfecte samenloop van omstandigheden voor hacks. Tegen een dergelijke zero-day aanval is eigenlijk nauwelijks te beveiligen.

Jullie doen veel beveiligingsonderzoek, wat voor fouten kom je vaak in PHP applicaties / configuraties tegen?
Eindbazen: Eindbazen is in principe een CTF team en doet geen beveiligingsonderzoek, dit probleem kwamen we bij toeval tegen. Het Eindbazen team bestaat uit zowel studenten als professionals met uiteenlopende banen. Het zal dus ook voor iedereen anders zijn wat we in de praktijk tegen komen. Veel van de fouten zijn ook niet PHP specifiek maar generieke beveiligingsproblemen van webapplicaties. De meest voorkomende fouten in PHP zullen grotendeels overeen komen met de OWASP top 10.

Wat is volgens jullie de veiligste opstelling van PHP of bestaat die niet?
Eindbazen: In ieder geval een opstelling die volledig up to date is. Dit beschermt natuurlijk niet tegen zero-day aanvallen, maar het is wel het minste wat je zelf kan doen. Daarnaast is het belangrijk dat PHP code van verschillende gebruikers, ook met scheiding van permissies uitgevoerd wordt. PHP code die door een gebruiker op de webserver wordt gezet, zou uitgevoerd moeten worden met zeker niet meer permissies dan die gebruiker heeft.

Er zijn verschillende manieren om dit te bewerkstelligen, waarvan de meest populaire manieren ironisch genoeg op CGI gebaseerd zijn (suexec, suphp). Daar bovenop kan je oneindig ver gaan met securitymaatregelen. Uiteindelijk wordt je alleen tegengehouden door de wens om nog iets bruikbaars over te houden.

77% van de websites draait PHP, is er voor deze sites ook een veiliger alternatief, of maakt het niet uit welk scripttaal je gebruikt?
Eindbazen: Een veilig alternatief is statische HTML. Helaas is dit geen realistisch alternatief in de huidige web omgeving. Verder maakt het over het algemeen niet uit welke scripttaal je gebruikt, zolang je maar zorgt dat de code veilig is. De bugs in het PHP platform zelf vermijd je alleen door over te stappen op een ander platform, maar dat zal weer z'n eigen problemen hebben. Aangezien het nog steeds door een meerderheid van sites gebruikt wordt en voor veel programmeurs bekend is zullen we nog wel een tijdje met PHP van doen hebben.

Wat is volgens jullie een potentieel groter probleem: PHP-applicaties die onveilig zijn geprogrammeerd, of beveiligingslekken in PHP zelf?
Eindbazen: Potentieel is een groot lek in PHP uiteraard een groter probleem dan een probleem met een specifieke applicatie geschreven in PHP. Onveilige PHP applicaties komen echter veel vaker voor waardoor die in de praktijk een veel groter probleem vormen ?-s