In dit artikel stelt Elias Taylor dat een recent ontdekte PHP-kwetsbaarheid onterecht als zeer gevaarlijk wordt bestempeld. Hij merkt op dat veel van de verspreide 'Proof-of-Concept' (PoC) exploits op GitHub niet werken in standaardomgevingen en vaak zijn gegenereerd door LLM's die de gebruiker misleiden.
De auteur benadrukt dat deze kwetsbaarheid niet te vergelijken is met incidenten zoals Log4Shell of Heartbleed, omdat er geen eenvoudige exploit-chain bestaat. Veel AI-gegenereerde oplossingen leunen bovendien op Local File Inclusion (LFI), wat een onrealistische voorwaarde is voor een algemene exploit. Taylor waarschuwt voor de impact van AI op de besluitvorming in de tech-wereld, waarbij LLM's leiden tot een uniforme, maar foutieve interpretatie van technische problemen. De initiële paniek wordt toegeschreven aan waarschuwingen van het PHP-kernteam en het algemene imago van PHP als onveilig.
Er is geen eenvoudige exploit voor deze PHP-kwetsbaarheid
Ik weet het, ik weet het. Het is het enige waar je over hoort. Dat, en het getal 4.
Begrijp me niet verkeerd, er is duidelijk sprake van een bug en dat is echt belangrijk. Maar deze is niet eenvoudig te exploiteren. Het komt zeker niet in de buurt van de eenvoud van Log4Shell, Heartbleed of RoRYaml.
Waarom deze kwetsbaarheid minder exploiteerbaar is
Ik geloof niet dat deze PHP-kwetsbaarheid zo makkelijk te exploiteren is. Vijf jaar geleden zouden mensen dit waarschijnlijk hebben begrepen, maar tegenwoordig worden mensen misleid door hun LLM's (Large Language Models), die hen vertellen dat ze een exploit hebben terwijl dat niet zo is.
Als je nu naar GitHub kijkt, zie je duizenden — letterlijk duizenden — "PoC"-exploits voor deze kwetsbaarheid. Eén ding dat bij al deze exploits opvalt, is dat ze niet werken tegen een standaard PHP-instantie.
Ga gerust je gang: zet een PHP-server op in Docker waarvan je denkt dat deze kwetsbaar is en voer dan zelf de PoC uit. Laat je LLM het niet doen. Nee, voer het script zelf uit. De exploits werken niet.
De rol van LLM's en de afwezigheid van een werkende exploit
Ik denk dat veel mensen ervan uitgingen dat LLM's direct een exploit-chain zouden kunnen bouwen door de diff te lezen. Zelfs als dit moeilijker te exploiteren zou zijn dan andere lekken, zouden LLM's het speelveld gelijk trekken. Nou, er is geen werkende exploit. Wat nu?
Wanneer ik denk aan de "we zijn echt de sjaak"-CVE10's op het internet, denk ik aan de volgende kwetsbaarheden:
- RoR YAML decoding: stuur een post-body met foutieve YAML.
- Log4shell: stel je user-agent in op
${jdni:ldap:}.
- Shellshock:
"copy env x='() { :;}; echo vulnerable' bash -c "echo this is a test"" en naar smaak aanpassen.
- Heartbleed: vraag om een
Content-Length van 10.000.000.
Zodra deze kwetsbaarheden in het nieuws kwamen, waren er direct botnets actief die schade aanrichtten. En dit was nog vóór LLM's! Mensen moesten de botnets zelf schrijven. Met hun eigen handen!
Er is inmiddels tien uur verstreken sinds deze kwetsbaarheid is gepubliceerd. De helft van de softwarewereld kijkt ernaar en God weet dat 100.000 mensen hun "superintelligentie" op de zaak hebben gezet. Toch is er geen werkende exploit. De versies die rondgaan zijn nep, of werken alleen in een laboratoriumomgeving, omdat...
Verdomde LLM's, man.
Script kiddies (en script adults, die hun hersenen ook hebben uitgeschakeld) denken nu allemaal dat ze weliswaar geen UAF-chaining begrijpen, maar dat die "Claude-vriend" alles weet en prima een exploit kan maken.
Hilarisch genoeg resulteert dit erin dat de LLM hen een uitgeschakelde controller geeft. Het zegt "exploit" over het hele scherm... en er zijn enkele bewijsstukken... maar de LLM heeft de server waartegen je test aangepast om een ernstige kwetsbaarheid te hebben. Valsspelen!
Enkele voorbeelden van dergelijke PoC's:
Het probleem met LFI-afhankelijkheid
Een komisch gemeenschappelijk kenmerk van de meeste van deze "PoC's" is dat ze leunen op "LFI" (local-file-inclusion) om de kwetsbaarheid te realiseren. In niet-PHP-termen betekent dit dat hun exploit-chain vereist dat de server effectief eval(read(filenameprovidedby_user)) uitvoert.
Het is niet ongebruikelijk dat PHP-applicaties op een bepaalde manier kwetsbaar zijn, maar vereisen dat de server al een bestaande kwetsbaarheid heeft waarbij men /etc/password kan uitlezen, is een krankzinnige voorwaarde. Als je dit nodig hebt, maakt dat dit lek niet ernstig.
Het vreemdste is dat zoveel mensen onafhankelijk van elkaar deze buitengewone fout in oordeelsvermogen hebben gemaakt. Dat komt omdat ze deze beslissing niet onafhankelijk hebben genomen. Claude en anderen hebben het oordeel voor hen gedaan, wat leidt tot deze bizarre distributie van logische fouten.
De impact van AI op besluitvorming
Er moet iets belangrijks worden gezegd over hoeveel mensen Claude of GPT hun ontwerpbeslissingen laten nemen, en hoe AI momenteel de primaire beslisser in de wereld is. Je krijgt hier te maken met een bizar geval van "Decision Schelling Points", waarbij een methode om een probleem op te lossen extreem oververtegenwoordigd is, simpelweg omdat dat is wat Claude standaard doet.
Dit is irritant in het geval van "de meeste websites zien er nu hetzelfde uit", maar omdat LLM's de kracht hebben om elk domein tegelijkertijd te ruïneren, betekent dit ook dat "de meeste beslissingen nu verdacht hetzelfde zijn". Vooral in dit geval, waar AI een kwetsbaarheid in de server invoegt... om te bewijzen dat de server kwetsbaar is voor jouw "exploit elke PHP-instantie"-aanval!
Waarom was iedereen zo bang?
De angst kwam voort uit het volgende:
- Een lid van het PHP-kernteam zei dat dit catastrofaal was ("exploits zullen verschijnen 15 minuten nadat de patch is uitgebracht").
- We weten diep van binnen allemaal dat PHP onveilig is.
- De exploit-video bevatte een anime-meisje.
- We weten allemaal dat LLM's boven het internet hangen als een 100 ton wegend aambeeld van Tsjechov, en we weten dat code niet veilig is.
We hebben dit soort dingen al eerder meegemaakt, maar nog niet in het LLM-tijdperk. Gelukkig voor ons lijkt dit niet die dag te zijn. Dit is te moeilijk om eenvoudig te exploiteren. Dit is geen Log4J-moment.
Er is geen eenvoudige exploit voor deze PHP-kwetsbaarheid
Ik weet het, ik weet het. Het is het enige waar je over hoort. Dat, en het getal 4.
Begrijp me niet verkeerd, er is duidelijk sprake van een bug en dat is echt belangrijk. Maar deze is niet eenvoudig te exploiteren. Het komt zeker niet in de buurt van de eenvoud van Log4Shell, Heartbleed of RoRYaml.
Waarom deze kwetsbaarheid minder exploiteerbaar is
Ik geloof niet dat deze PHP-kwetsbaarheid zo makkelijk te exploiteren is. Vijf jaar geleden zouden mensen dit waarschijnlijk hebben begrepen, maar tegenwoordig worden mensen misleid door hun LLM's (Large Language Models), die hen vertellen dat ze een exploit hebben terwijl dat niet zo is.
Als je nu naar GitHub kijkt, zie je duizenden — letterlijk duizenden — "PoC"-exploits voor deze kwetsbaarheid. Eén ding dat bij al deze exploits opvalt, is dat ze niet werken tegen een standaard PHP-instantie.
Ga gerust je gang: zet een PHP-server op in Docker waarvan je denkt dat deze kwetsbaar is en voer dan zelf de PoC uit. Laat je LLM het niet doen. Nee, voer het script zelf uit. De exploits werken niet.
De rol van LLM's en de afwezigheid van een werkende exploit
Ik denk dat veel mensen ervan uitgingen dat LLM's direct een exploit-chain zouden kunnen bouwen door de diff te lezen. Zelfs als dit moeilijker te exploiteren zou zijn dan andere lekken, zouden LLM's het speelveld gelijk trekken. Nou, er is geen werkende exploit. Wat nu?
Wanneer ik denk aan de "we zijn echt de sjaak"-CVE10's op het internet, denk ik aan de volgende kwetsbaarheden:
- RoR YAML decoding: stuur een post-body met foutieve YAML.
- Log4shell: stel je user-agent in op
${jdni:ldap:}.
- Shellshock:
"copy env x='() { :;}; echo vulnerable' bash -c "echo this is a test"" en naar smaak aanpassen.
- Heartbleed: vraag om een
Content-Length van 10.000.000.
Zodra deze kwetsbaarheden in het nieuws kwamen, waren er direct botnets actief die schade aanrichtten. En dit was nog vóór LLM's! Mensen moesten de botnets zelf schrijven. Met hun eigen handen!
Er is inmiddels tien uur verstreken sinds deze kwetsbaarheid is gepubliceerd. De helft van de softwarewereld kijkt ernaar en God weet dat 100.000 mensen hun "superintelligentie" op de zaak hebben gezet. Toch is er geen werkende exploit. De versies die rondgaan zijn nep, of werken alleen in een laboratoriumomgeving, omdat...
Verdomde LLM's, man.
Script kiddies (en script adults, die hun hersenen ook hebben uitgeschakeld) denken nu allemaal dat ze weliswaar geen UAF-chaining begrijpen, maar dat die "Claude-vriend" alles weet en prima een exploit kan maken.
Hilarisch genoeg resulteert dit erin dat de LLM hen een uitgeschakelde controller geeft. Het zegt "exploit" over het hele scherm... en er zijn enkele bewijsstukken... maar de LLM heeft de server waartegen je test aangepast om een ernstige kwetsbaarheid te hebben. Valsspelen!
Enkele voorbeelden van dergelijke PoC's:
Het probleem met LFI-afhankelijkheid
Een komisch gemeenschappelijk kenmerk van de meeste van deze "PoC's" is dat ze leunen op "LFI" (local-file-inclusion) om de kwetsbaarheid te realiseren. In niet-PHP-termen betekent dit dat hun exploit-chain vereist dat de server effectief eval(read(filenameprovidedby_user)) uitvoert.
Het is niet ongebruikelijk dat PHP-applicaties op een bepaalde manier kwetsbaar zijn, maar vereisen dat de server al een bestaande kwetsbaarheid heeft waarbij men /etc/password kan uitlezen, is een krankzinnige voorwaarde. Als je dit nodig hebt, maakt dat dit lek niet ernstig.
Het vreemdste is dat zoveel mensen onafhankelijk van elkaar deze buitengewone fout in oordeelsvermogen hebben gemaakt. Dat komt omdat ze deze beslissing niet onafhankelijk hebben genomen. Claude en anderen hebben het oordeel voor hen gedaan, wat leidt tot deze bizarre distributie van logische fouten.
De impact van AI op besluitvorming
Er moet iets belangrijks worden gezegd over hoeveel mensen Claude of GPT hun ontwerpbeslissingen laten nemen, en hoe AI momenteel de primaire beslisser in de wereld is. Je krijgt hier te maken met een bizar geval van "Decision Schelling Points", waarbij een methode om een probleem op te lossen extreem oververtegenwoordigd is, simpelweg omdat dat is wat Claude standaard doet.
Dit is irritant in het geval van "de meeste websites zien er nu hetzelfde uit", maar omdat LLM's de kracht hebben om elk domein tegelijkertijd te ruïneren, betekent dit ook dat "de meeste beslissingen nu verdacht hetzelfde zijn". Vooral in dit geval, waar AI een kwetsbaarheid in de server invoegt... om te bewijzen dat de server kwetsbaar is voor jouw "exploit elke PHP-instantie"-aanval!
Waarom was iedereen zo bang?
De angst kwam voort uit het volgende:
- Een lid van het PHP-kernteam zei dat dit catastrofaal was ("exploits zullen verschijnen 15 minuten nadat de patch is uitgebracht").
- We weten diep van binnen allemaal dat PHP onveilig is.
- De exploit-video bevatte een anime-meisje.
- We weten allemaal dat LLM's boven het internet hangen als een 100 ton wegend aambeeld van Tsjechov, en we weten dat code niet veilig is.
We hebben dit soort dingen al eerder meegemaakt, maar nog niet in het LLM-tijdperk. Gelukkig voor ons lijkt dit niet die dag te zijn. Dit is te moeilijk om eenvoudig te exploiteren. Dit is geen Log4J-moment.
Groetjes,