TL;DR: Angesichts des dritten im Jahr 2026 entdeckten Pufferüberlaufs (und laut F5, RCE, wenn kein ASLR vorhanden ist), der bei der Arbeit mit RegEx und Variablen auftrat, entschloss sich der Entwickler von freenginx, Maxim Dunin, dass es an der Zeit war, dies zu beenden, und fügte in sein Produkt eine Prüfung der Variablenlänge ein, bevor Daten dort hineingeschrieben werden. Diese Neuerung wurde dann auch bei nginx übernommen, was die Hoffnung auf das Ende neuer CVEs zu diesem Thema weckt.
Nun zu den Einzelheiten.
Am 19. Juni wurde Commits in freenginx ein Update vorgenommen, das dem Variablen-Descriptor ein Endfeld hinzufügt, das das Ende des Puffers angibt. Zuvor gab es nur einen Zeiger auf dessen Anfang (pos), die erforderliche Länge wurde (und wird jetzt auch) im Voraus berechnet und beim Kopieren der Daten in die Variable wurde angenommen, dass die zuvor richtig berechnete Länge garantiert, dass die Daten in den Puffer passen. Leider stellte sich dies in zwei Fällen im Mai 2026 aufgrund verschiedener Übersehungen als nicht zutreffend heraus (1 (linux.org.ru), 2 (linux.org.ru)), was zu Pufferüberläufen und schlechten Folgen führte. Nun, bei der Erstellung eines Variablenpuffers wird auch der Zeiger auf dessen Ende ausgefüllt, und vor dem Schreiben von Daten in die Variable wird die Verarbeitung der Anfrage kontrolliert beendet, wenn die Daten nicht hineinpassen. Das bedeutet, dass Fehler bei der Längenberechnung weiterhin vorkommen können, aber sie werden nun nicht mehr den Speicher beschädigen, sondern lediglich eine spezifische HTTP-Anfrage fehlschlagen lassen. In den folgenden Commits (2 (freenginx.org), 3 (freenginx.org)) wurde ein ähnlicher Schutz an anderen Stellen des Codes hinzugefügt, einschließlich des Zugriffsprotokollcodes. 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 Position in der Kette vertauscht wurden), der Problematik wurde die Bezeichnung CVE-2026-42533, und F5 gab ein offizielles SA (f5.com).
Bezüglich der spezifischen Schwachstelle: Sie tritt auf, wenn die Direktive map mit regulären Ausdrücken und extrahierten Parametern verwendet wird. In Bezug auf die anderen erforderlichen Bedingungen für ihr Auslösen unterscheiden sich die Texte in der Commit-Beschreibung und der Text in SA etwas: In SA wird angegeben, dass später eine bestimmte Zeichenkette berechnet werden sollte, die den extrahierten Parameter, der von map übrig bleibt, verwendet, bevor das Ergebnis von demselben map. In der Commit-Beschreibung wird im Beispiel erwähnt, dass zwischen diesen Schritten auch die Zurücksetzung einer Variablen, die den extrahierten Parameter enthält, stattfindet. Wie dem auch sei, in den meisten betriebenen Nginx-Instanzen wird so etwas wahrscheinlich nicht anzutreffen sein, und die Schwachstelle hat dadurch nur wenige betroffen. Es ist auch zu beachten, dass Korrekturen zur Berechnung der Länge in diesem speziellen Fall in den eingereichten Änderungen anscheinend fehlen (oder ich habe schlecht gesucht?), es gibt nur einen Schutz, der das Problem in einen kontrollierten HTTP-Anfragefehler verwandelt. Obwohl am 19. Juli in freenginx einige Korrekturen hinzugefügt wurden (5bfb, 7622, b906), um die Berechnung der Länge für eine ähnliche Situation zu verbessern, ist jedoch auf Anhieb nicht klar, ob das der Fall ist oder nicht.
Die Schwachstelle trat in der Version nginx 0.9.6 auf, die Korrekturen fanden Einzug in die Versionen freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
In SA nginx wird einigen Personen für die unabhängige Meldung der Schwachstelle und die Einhaltung der "Standards für koordinierte Offenlegung" 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) für die unabhängige Meldung dieses Problems und die Einhaltung der höchsten Standards für koordinierte Offenlegung.
In freenginx beschränkt sich die begleitende Information zur Behebung tatsächlich auf die Mitteilung bei der Einreichung. In changelog- wurde diese Behebung nicht einmal mit dem Hinweis "Sicherheit" (security) oder "Korrektur" (bugfix) gekennzeichnet, sondern schlicht als "Hinzufügen" (feature). Wahrscheinlich hielt der Autor dieses Problem nicht für kritisch. Wie die Meldungen über das Problem von den genannten Personen bei F5 und das aus freenginx übernommene Commit in Beziehung stehen und ob sie (oder jemand anderes) den freenginx-Autor über das Problem informiert haben, konnte nicht geklärt werden.
Quelle: linux.org.ru
