TL;DR: W obliczu trzeciego wykrytego w 2026 roku przepełnienia bufora (a według F5, RCE jeśli brak ASLR) podczas pracy z regexpami i zmiennymi, deweloper freenginx, Maksym Dunin, postanowił, że czas to zakończyć i dodał do swojego produktu sprawdzanie rozmiaru zmiennej przed zapisaniem do niej danych. Stamtąd to nowo введzenie zostało zabrane do nginx, co daje nadzieję na zaprzestanie nowych CVE w tej sprawie.
Teraz szczegóły.
19 czerwca dokonano commitu w freenginx, który dodaje do opisu zmiennej pole end, wskazujące na koniec bufora. Wcześniej był tylko wskaźnik na jego początek (pos), potrzebna długość była obliczana (i nadal jest obliczana) z wyprzedzeniem, a w momencie kopiowania danych do zmiennej zakładano, że prawidłowo obliczona wcześniej długość gwarantuje, że dane zmieszczą się w buforze. Niestety, już dwa razy w maju 2026 roku z powodu różnych przeoczeń okazało się, że tak nie jest (1 (linux.org.ru), 2 (linux.org.ru)), co prowadziło do przepełnień bufora i złych konsekwencji. Otóż teraz, podczas tworzenia bufora, zmienna jest również wypełniana wskaźnikiem na jej koniec, a przed zapisaniem danych do zmiennej, jeśli dane się nie mieszczą, przetwarzanie żądania będzie kontrolowane i zakończy się błędem. To znaczy, że błędy obliczenia długości mogą się zdarzać dalej, ale teraz nie będą uszkadzać pamięci, a jedynie powodować niepowodzenia konkretnego zapytania http. Kolejnymi commitami (2 (freenginx.org), 3 (freenginx.org)) dodano analogiczną ochronę w innych miejscach kodu, w tym w kodzie prowadzenia logu dostępu. 7 lipca opublikowano wersję freenginx 1.31.3, która zawiera to poprawienie.
15 lipca te commity zostały zaadoptowane przez nginx (1 (github.com), 2 (github.com), 3 (github.com), dlaczegoś zamieniając miejscami drugi i trzeci w łańcuchu), problemowi przypisano CVE-2026-42533, a F5 wydało oficjalne SA (f5.com).
W odniesieniu do konkretnej luki tym razem: objawia się ona przy użyciu dyrektywy map z wyrażeniami regularnymi z wydzielonymi parametrami. W kwestii pozostałych warunków koniecznych do jej wyzwolenia tekst w opisie commita i tekst w SA nieco się różnią: w SA wskazano, że później musi być obliczona pewna strona, która wykorzystuje wydzielony parametr pozostały z map, wcześniej niż wynik tego samego map. W opisie commita w przykładzie między tymi krokami bierze jeszcze udział zerowanie zmiennej zawierającej wydzielony parametr. Niemniej jednak w większości uruchomionych nginxów takie coś prawdopodobnie się nie zdarzy, a luka w ten sposób dotknęła niewielu. Należy również zauważyć, że poprawki obliczenia długości konkretnie w tym przypadku w zakomitowanych poprawkach wydają się nie być (czy źle szukałem?), jest tylko ochrona, która przekształca problem w kontrolowane niepowodzenie żądania http. Chociaż 19 lipca w freenginx dodano jakieś poprawki (5bfb, 7622, b906) obliczenia długości dla podobnej sytuacji, ale na pierwszy rzut oka trudno powiedzieć, czy to to, czy nie.
Luka pojawiła się w wersji nginx 0.9.6, poprawki trafiły do wersji freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
W SA nginx podano podziękowania dla kilku osób za niezależne zgłoszenia o luce oraz przestrzeganie „standardów skoordynowanego ujawniania informacji”:
F5 przyznaje podziękowania Ming Xuan, DKD (@pidifn), Ji’an Zhou oraz Zhen Yan z AntAISecurityLab, Rafael Gacek, Sergii Negodiuk z EVO.company, Lam Jun Rong z Calif.io, Mufeed VH z Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin z depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin z Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil) oraz Milan Jovic (Kljunowsky) za niezależne zwrócenie uwagi na ten problem i przestrzeganie najwyższych standardów skoordynowanego ujawniania.
W freenginx towarzyszące informacje o poprawce praktycznie ograniczają się do komunikatu w przy commit. W changelog- tym poprawka nawet nie jest oznaczona ani podpisem „bezpieczeństwo” (security), ani „poprawka” (bugfix), tylko „dodanie” (feature). Prawdopodobnie autor nie uważał tego problemu za krytyczny. Jak mają się zgłoszenia o problemie ze strony wymienionych osób w F5 do zapożyczonego z freenginx commita, czy informowali oni (lub ktoś inny) o problemie autora freenginx, nie udało się ustalić.
Źródło: linux.org.ru
