TL;DR: Angesichts des dritten im Jahr 2026 entdeckten Bufferüberlaufs (und, laut F5, RCE bei fehlendem ASLR) bei der Arbeit mit Regex und Variablen beschloss der Entwickler von freenginx, Maxim Dunin, dass es an der Zeit sei, dies zu beenden, und fügte in sein Produkt eine Überprüfung der Variablenlänge hinzu, bevor Daten in diese geschrieben werden. So wurde diese Neuerung auch von nginx übernommen, was die Hoffnung auf das Ende neuer CVEs zu diesem Thema gibt.
Jetzt die Details.
Am 19. Juni wurde Commit in freenginx ein Update veröffentlicht, das dem Variablen-Descriptor ein Endfeld hinzufügt, das das Ende des Puffers angibt. Früher gab es nur einen Zeiger auf den Anfang (pos), die benötigte Länge wurde (und wird auch jetzt) im Voraus berechnet, und zum Zeitpunkt der Datenkopie in die Variable wurde angenommen, dass die zuvor korrekt berechnete Länge gewährleistet, dass die Daten in den Puffer passen. Leider stellte sich bereits zweimal im Mai 2026 aufgrund verschiedener Übersehen heraus, dass dies nicht der Fall war (1 (linux.org.ru), 2 (linux.org.ru)), was zu Bufferüberläufen und schlechten Folgen führte. Nun, bei der Erstellung des Puffers wird auch der Zeiger auf sein Ende gefüllt, und bevor Daten in die Variable geschrieben werden, wird die Anfrage kontrolliert mit einem Fehler beendet, wenn die Daten nicht hinein passen. Das heißt, Berechnungsfehler in der Länge können weiterhin auftreten, aber sie werden jetzt nicht mehr den Speicher beschädigen, sondern nur eine bestimmte HTTP-Anfrage fehlschlagen lassen. Mit den 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 anscheinend die zweite und dritte in der Kette vertauscht wurden), das Problem erhielt die CVE-Nummer CVE-2026-42533, und F5 veröffentlichte ein offizielles SA (f5.com).
Bezüglich der spezifischen Schwachstelle dieses Mal: Sie tritt auf, wenn die map-Direktive mit regulären Ausdrücken und выделяемыми Parameter verwendet wird. In Bezug auf die anderen Bedingungen, die für das Auslösen erforderlich sind, unterscheiden sich der Text in der Commit-Beschreibung und der Text im SA etwas: Im SA ist angegeben, dass später eine bestimmte Zeichenfolge berechnet werden sollte, die den выделяемый Parameter verwendet, der von map übrig bleibt, bevor das Ergebnis dieses gleichen map kommt. In der Commit-Beschreibung wird im Beispiel erwähnt, dass zwischen diesen Schritten auch das Zurücksetzen einer Variablen, die den выделяемый Parameter enthält, eine Rolle spielt. Wie dem auch sei, in den meisten laufenden Nginx-Instanzen wird ein solches Problem wahrscheinlich nicht zu finden sein, und die Schwachstelle hat in dieser Weise die meisten vermutlich nicht betroffen. Es sollte auch angemerkt werden, dass die Korrekturen zur Berechnung der Länge in diesem speziellen Fall in den committen Änderungen anscheinend nicht vorhanden sind (oder ich habe schlecht gesucht?), es gibt nur einen Schutz, der das Problem in einen kontrollierten Fehler des HTTP-Anfragen umwandelt. Obwohl am 19. Juli in freenginx einige Korrekturen hinzugefügt wurden (5bfb, 7622, b906) zur Berechnung der Länge für eine ähnliche Situation, lässt sich auf den ersten Blick nicht genau erkennen, ob dies der Fall ist oder nicht.
Die Schwachstelle trat in der Version Nginx 0.9.6 auf, die Korrekturen wurden in den Versionen freenginx 1.31.3, Nginx 1.30.4, Nginx 1.31.3 umgesetzt.
Im SA von Nginx werden Danksagungen an mehrere Personen für unabhängige Meldungen über die Schwachstelle und die Einhaltung der „Standards für koordiniertes Offenlegen“ angegeben:
F5 dankt 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 Thema unabhängig zur Sprache gebracht haben und die höchsten Standards für koordiniertes Offenlegen eingehalten haben.
In freenginx ist die begleitende Information zur Korrektur tatsächlich auf eine Mitteilung beim Commit beschränkt. In der changelog-ten Korrektur ist dieses sogar nicht mit dem Hinweis „Sicherheit“ (security) oder „Korrektur“ (bugfix) gekennzeichnet, sondern einfach als „Hinzugefügt“ (feature) aufgeführt. Wahrscheinlich hielt der Autor dieses Problem nicht für kritisch. Inwiefern die Meldungen zu dem Problem von den genannten Personen in F5 und der aus freenginx übernommenen Commit-Zusammenfassung übereinstimmen oder ob sie (oder jemand anderes) dem Autor von freenginx über das Problem berichtet haben, konnte nicht ermittelt werden.
Quelle: linux.org.ru
