In het voorjaar van 2024 veranderde een vierentwintig jaar oud lek in de C-bibliotheek van Linux het gevaarniveau van talloze PHP-applicaties. CVE-2024-2961 treft WordPress niet rechtstreeks, maar maakt het mogelijk een eenvoudige leesactie op een bestand om te zetten in code-uitvoering op afstand. Dit artikel legt het mechanisme uit zonder exploitrecept, wie er getroffen is en vooral hoe je je hosting controleert en corrigeert.
Wat CVE-2024-2961 verhelpt
Het lek zit in de functie iconv() van de GNU C Library (glibc), die tekst omzet van de ene tekenset naar de andere. Bij een conversie naar de tekenset ISO-2022-CN-EXT kan de functie tot 4 bytes voorbij de outputbuffer schrijven die ze heeft gekregen. Die overflow kan de applicatie laten crashen of een naburige variabele in het geheugen overschrijven. Volgens het officiële advies van glibc werd de foutieve code in 2000 geïntroduceerd en was ze nooit opgemerkt.
De National Vulnerability Database kent het lek een CVSS 3.1-score van 7,3 toe. Het werd gevonden door Charles Fol (Ambionics / Lexfo), gemeld op 26 maart 2024 en gepubliceerd op 17 april 2024, tegelijk met de patch.
Waarom PHP het meest blootgestelde doelwit is
Het sleutelpunt is de wrapper php://filter. Met PHP kun je convert.iconv-conversies toepassen op elke stroom die wordt gelezen. Een aanvaller die de applicatie op de een of andere manier een bestand kan laten lezen, kan haar vragen die stroom naar ISO-2022-CN-EXT om te zetten en zo de bug in glibc activeren. Volgens de analyse van de ontdekker zijn alle standaard leesfuncties van PHP getroffen:
file_get_contents(),file(),readfile(),fgets()getimagesize()enSplFileObject- schrijffuncties zoals
file_put_contents()zijn dat ook - functies die een bestand alleen testen (
file_exists(),is_file()) activeren de conversie daarentegen niet
De techniek werd gedemonstreerd op PHP-versies van 7.0 tot en met 8.3. Met andere woorden: PHP bijwerken is niet genoeg, het is de glibc van de server die moet worden gepatcht. De wrapper phar:// speelt hier evenmin een rol, in tegenstelling tot andere deserialisatieaanvallen.
Het filter is niet de enige toegangsweg. De onderzoeker noemt verschillende manieren om een stroom naar iconv te leiden: een SQL-injectie die LOAD DATA LOCAL INFILE misbruikt, een XXE-lek, bepaalde bibliotheken voor beeldverwerking of vertaling. De gemeenschappelijke factor is altijd dezelfde: je hebt een manier nodig om de applicatie content te laten verwerken die de aanvaller beheerst, en daaronder een niet-gepatchte glibc. Daarom wordt het probleem op systeemniveau opgelost, niet in één enkele plugin.
Een WordPress-geval en massaal misbruik
De eerste openbare demonstratie richtte zich op een WordPress-site met de plugin BuddyForms 2.7.7, kwetsbaar voor CVE-2023-26326 (niet-geauthenticeerde deserialisatie). Dat pluginlek leverde de leesprimitief die nodig was om de glibc te bereiken. Een goede herinnering: een pluginkwetsbaarheid die als middelmatig wordt beoordeeld, kan kritiek worden zodra ze wordt gekoppeld aan een systeemfout.
Het gevaar bleef niet theoretisch. Vanaf de zomer van 2024 koppelde de zogeheten CosmicSting-campagne CVE-2024-34102 (een XXE-lek in Adobe Commerce / Magento) aan CVE-2024-2961 om code-uitvoering te verkrijgen. Volgens Sansec, aangehaald door BleepingComputer in oktober 2024, werden meer dan 4.000 webwinkels (ongeveer 5% van alle Adobe Commerce- en Magento-installaties) gecompromitteerd. Onder de genoemde slachtoffers bevonden zich grote merken.
Getroffen en gepatchte glibc-versies
Het lek treft glibc 2.39 en alle eerdere versies. Het is verholpen in versie 2.40 en gebackport naar de onderhoudsbranches. Op een server telt bijna altijd het pakket van je distributie, niet de upstreamversie.
| Bron | Status | Detail |
|---|---|---|
| glibc upstream < 2.40 | Kwetsbaar | Foutieve code aanwezig sinds branch 2.1.93 |
| glibc 2.40 | Gepatcht | Referentiepatch, april 2024 |
| Branches 2.32 tot en met 2.39 | Gepatcht via backport | Via de pakketten van distributies |
| Debian 12 (bookworm) | Gepatcht | 2.36-9+deb12u6 en hoger |
| Debian 13 (trixie) | Gepatcht | 2.37-18 en hoger |
De pakketversies komen uit de trackers van Debian en het advies van glibc; bevestig de precieze status met de bulletins van je eigen distributie (Red Hat, Ubuntu, AlmaLinux…).
Hoe je weet of je getroffen bent
Op gedeelde hosting beheer je de glibc niet altijd zelf, maar je kunt vaak wel controleren en je support waarschuwen. Als je SSH-toegang hebt:
- Toon de actieve tekensets:
iconv -l | grep -E 'CN-?EXT'. Bevat de uitvoerISO-2022-CN-EXT, dan is de kwetsbare module aanwezig. - Vergelijk de versie van het glibc-pakket (
ldd --version) met de patch die je distributie heeft aangekondigd. - Vraag je hostingprovider wanneer de glibc-patch op je servers is toegepast.
Volgens Zend is een applicatie langs deze weg niet blootgesteld als aan een van deze voorwaarden is voldaan: ze gebruikt de extensie iconv niet, de glibc is bijgewerkt, de tekenset ISO-2022-CN-EXT is uit de configuratie verwijderd, of de applicatie geeft alleen expliciet toegestane tekensets aan iconv door.
Corrigeren en het risico beperken
De enige echte oplossing is de glibc bijwerken. Zoals Zend en Red Hat benadrukken, komt er geen PHP-patch, omdat de fout in de systeembibliotheek zit. In afwachting van de update documenteren Red Hat en Rocky Linux een tijdelijke maatregel: de tekenset ISO-2022-CN-EXT verwijderen door de drie betreffende regels in gconv-modules-extra.conf uit te commentariëren en daarna de cache opnieuw op te bouwen met iconvconfig. Laat dit over aan een beheerder, na testen, want het kan applicaties breken die deze tekenset echt gebruiken.
Daarnaast beperken twee reflexen de reikwijdte van zo'n keten. Ten eerste: verminder het aantal plugins dat een bestand kan lezen op basis van een parameter, want zij leveren de primitief waarmee het begint. Ten tweede: houd in je logbestanden pogingen in de gaten om gevoelige bestanden te lezen, vaak het teken van een verkenningsfase vóór een gekoppelde aanval. Een systeemlek dat snel wordt gepatcht, is altijd beter dan detectie achteraf.
Om te onthouden
- CVE-2024-2961 is een overflow in glibc (iconv, tekenset ISO-2022-CN-EXT), niet in PHP: alleen PHP bijwerken beschermt je niet.
- Het lezen van een bestand via een pluginlek kan, gekoppeld aan deze bug, tot code-uitvoering leiden.
- glibc 2.39 en ouder zijn getroffen; de patch zit in 2.40 en in de gebackporte pakketten.
- Controleer de glibc-versie van je hosting en de datum van de patch; houd PHP en je plugins up-to-date.
De rol van WP Masquerade
Laten we duidelijk zijn: WP Masquerade verhelpt geen lek in glibc, PHP, een thema of een plugin. De rol ervan is het aanvalsoppervlak en de ruis te verkleinen en gezond onderhoud aan te vullen, nooit te vervangen. Drie bijdragen zijn hier relevant. Ten eerste vertragen de hardening en het verbergen van publieke kenmerken het geautomatiseerde profileren dat vaak aan misbruik voorafgaat. Ten tweede tellen de botvallen verzoeken naar gevoelige adressen (/.env, .sql-back-ups, paden van andere software), wat een vroeg signaal van verkenning geeft. Ten slotte helpt de integriteitscontrole van de core (Pro) om een wijziging na een inbraak op te sporen. De basisbescherming blijft het bijwerken van glibc, PHP en plugins, met geteste back-ups.
Video's om verder te gaan
Bronnen
- NVD - CVE-2024-2961 (opent in een nieuw tabblad)
- glibc-advies GLIBC-SA-2024-0004 (oss-security) (opent in een nieuw tabblad)
- Red Hat - CVE-2024-2961 en mitigerende maatregel (opent in een nieuw tabblad)
- NVD - CVE-2023-26326 (BuddyForms) (opent in een nieuw tabblad)
Andere geraadpleegde bronnen: officiële documentatie, officiële pagina's van de leveranciers, publicaties van beveiligingsonderzoekers en artikelen uit de vakpers.
