TL;DR: Angesichts des dritten Bufferüberlaufs, der im Jahr 2026 entdeckt wurde (und laut F5 RCE, wenn kein ASLR vorhanden ist), während der Arbeit mit regulären Ausdrücken und Variablen, beschloss der Entwickler von freenginx, Maxim Dunin, dass es Zeit war, dies zu beenden. Er fügte in sein Produkt eine Überprüfung der Variablenlänge ein, bevor Daten geschrieben werden. Diese Neuerung wurde auch in nginx übernommen, was Hoffnung auf ein Ende neuer CVEs zu diesem Thema gibt.
Jetzt die Details.
Am 19. Juni wurde Commit in freenginx ein Update implementiert, das dem Variablendescriptor ein Feld für das Ende hinzufügt, welches das Ende des Buffers angibt. Zuvor gab es dort nur einen Zeiger auf den Anfang (pos), die erforderliche Länge wurde (und wird immer noch) im Voraus berechnet, und zum Zeitpunkt des Kopierens der Daten in die Variable wurde angenommen, dass die zuvor korrekt berechnete Länge garantiert, dass die Daten in den Buffer passen. Leider stellte sich im Mai 2026 zwei Mal aufgrund unterschiedlicher Übersehen heraus, dass dies nicht der Fall war (1 (linux.org.ru), 2 (linux.org.ru)), was zu Bufferüberläufen und unglücklichen Folgen führte. Jetzt wird bei der Erstellung des Buffers auch der Zeiger auf dessen Ende gesetzt, und bevor Daten in die Variable geschrieben werden, wird die Bearbeitung der Anfrage kontrolliert mit einem Fehler beendet, wenn die Daten nicht hinein passen. Das bedeutet, dass Fehler bei der Längenberechnung weiterhin auftreten können, aber sie werden nun nicht mehr den Speicher beschädigen, sondern nur einen bestimmten HTTP-Antrag fehlschlagen lassen. In folgenden Commits (2 (freenginx.org), 3 (freenginx.org)) wurde ein ähnlicher Schutz an anderen Stellen im Code hinzugefügt, einschließlich des Codes zur Protokollierung von Zugriffslogs. Am 7. Juli wurde die Version freenginx 1.31.3, die diese Korrektur enthält, veröffentlicht.
Am 15. Juli wurden diese Commits von nginx übernommen (1 (github.com), 2 (github.com), 3 (github.com), wobei seltsamerweise die zweite und dritte in der Kette vertauscht wurden), das Problem wurde mit CVE-2026-42533, und F5 veröffentlichte ein offizielles SA (f5.com).
Bezüglich der spezifischen Schwachstelle diesmal: Sie tritt bei der Verwendung der Map-Direktive mit regulären Ausdrücken und hervorgehobenen Parametern auf. In Bezug auf die anderen notwendigen Bedingungen für ihr Auftreten weichen der Text in der Commit-Beschreibung und der Text im SA etwas voneinander ab: Im SA ist angegeben, dass anschließend eine bestimmte Zeichenfolge berechnet werden muss, die den hervorgehobenen Parameter verwendet, der von der Map bleibt, bevor das Ergebnis dieser Map kommt. In der Commit-Beschreibung wird im Beispiel zwischen diesen Schritten zusätzlich das Zurücksetzen einer Variable erwähnt, die den hervorgehobenen Parameter enthält. Wie auch immer, in den meisten laufenden nginx-Instanzen wird so etwas wahrscheinlich nicht vorkommen, und die Schwachstelle hat somit nur wenige betroffen. Es sei auch erwähnt, dass in den geposteten Änderungen anscheinend keine Korrekturen zur Berechnung der Länge in diesem speziellen Fall vorgenommen wurden (oder ich habe schlecht gesucht?), es gibt nur einen Schutz, der das Problem in einen kontrollierten HTTP-Anforderungsfehler umwandelt. Obwohl am 19. Juli in freenginx einige Korrekturen hinzugefügt wurden (5bfb, 7622, b906) zur Längenberechnung für eine ähnliche Situation, ist sofort nicht klar, ob dies der Fall ist oder nicht.
Die Schwachstelle trat in nginx Version 0.9.6 auf, und die Korrekturen fanden ihren Weg in die Versionen freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
Im SA von nginx werden mehreren Personen für unabhängige Meldungen über die Schwachstelle und das Einhalten der "Standards für koordiniertes Offenlegen" gedankt:
F5 erkennt Ming Xuan, DKD (@pidifn), Ji’an Zhou und Zhen Yan von AntAISecurityLab, Rafael Gacek, Sergii Negodiuk von EVO.company, Lam Jun Rong von Calif.io, Mufeed VH von Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin von depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin von Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil) und Milan Jovic (Kljunowsky) dafür, dass sie dieses Problem unabhängig zur Kenntnis gebracht haben und die höchsten Standards für koordiniertes Offenlegen eingehalten haben.
In freenginx beschränkt sich die begleitende Information zur Behebung grundsätzlich auf die Mitteilung im Commit. In changelog- wird diese Korrektur nicht einmal mit "Sicherheit" (security) oder "Fehlerbehebung" (bugfix) gekennzeichnet, sondern nur als "Hinzugefügt" (feature). Wahrscheinlich sah der Autor dieses Problem nicht als kritisch an. Es war nicht möglich herauszufinden, wie die Meldungen über das Problem von den genannten Personen an F5 und der aus freenginx stammenden Commit zusammenhängen, ob sie (oder jemand anderes) dem Autor von freenginx von dem Problem erzählt haben.
Quelle: linux.org.ru
