TL;DR: Сблъсквайки се с третото открито за 2026 година преливане на буфер (и, според F5, RCE, ако няма ASLR) при работа с регулярни изрази и променливи, разработчикът на freenginx Максим Дунин реши, че е време да сложи край на това и добави в своя продукт проверка на размера на променливата преди записването на данни в нея. Оттам това нововъведение бе откраднато за nginx, което дава надежда за прекратяване на нови CVE по тази тема.
Сега подробности.
На 19 юни беше направен комит в freenginx, който добавя в описателя на променливата поле end, указващо края на буфера. Преди това там имаше само указател на неговото начало (pos), необходимата дължина се изчисляваше (и сега се изчислява) предварително, и по времето на копирането на данни в променливата се предполага, че правилно изчислената дължина по-рано гарантира, че данните ще се поберат в буфера. За съжаление, вече два пъти през май 2026 година заради различни пренебрегвания се оказа, че това не е така (1 (linux.org.ru), 2 (linux.org.ru)), което доведе до преливания на буфера и негативни последствия. И така, сега при създаването на буфер, променливата се запълва и с указател на нейния край, а преди записването на данни в променливата, ако данните не се побират в нея, обработката на заявката ще бъде контролирано прекратена с грешка. Тоест, грешките при изчисляването на дължината могат да продължат да съществуват, но сега те няма да повреждат паметта, а само ще провалят конкретна http-заявка. Следващите комити (2 (freenginx.org), 3 (freenginx.org)) включваха подобна защита в други места в кода, включително кода за водене на access-лог. На 7 юли беше публикувана версията freenginx 1.31.3, включваща това поправяне.
На 15 юли тези комити бяха заимствани от nginx (1 (github.com), 2 (github.com), 3 (github.com), по някаква причина разменяйки втория и третия в поредицата), на проблема беше назначен CVE-2026-42533, а F5 издаде официално SA (f5.com).
По отношение на конкретната уязвимост този път: тя се проявява при използването на директива map с регулярни изрази с извлечени параметри. Що се отнася до останалите необходими условия за нейното задействие, текстът в описанието на комита и текстът в SA малко се разминават: в SA е посочено, че в бъдеще трябва да бъде изчислена някаква стойност, която използва изтегления параметър, останал от map, преди резултатът от този същия map. В описанието на комита в примера между тези стъпки участва и нулирането на променлива, съдържаща извлечения параметър. Каквото и да е, в повечето инсталирани nginx-ове подобно нещо вероятно няма да се срещне и така уязвимостта е засегнала съвсем малко хора. Трябва също така да се отбележи, че поправките в изчисляването на дължината конкретно в този случай в закомитените изменения изглежда ги няма (или аз лошо търсех?), има само защита, която превръща проблема в контролирана повреда на http заявката. Въпреки че на 19 юли в freenginx са добавени някакви поправки (5bfb, 7622, b906) за изчисляване на дължината за подобна ситуация, но не е ясно дали това е то или не.
Уязвимостта се е появила в версия nginx 0.9.6, поправките достигнали версиите freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
В SA nginx са посочени благодарности на няколко лица за независими съобщения относно уязвимостта и спазването на "стандартите за координирано разкриване на информация":
F5 благодарим на Ming Xuan, DKD (@pidifn), Ji’an Zhou и Zhen Yan от AntAISecurityLab, Rafael Gacek, Sergii Negodiuk от EVO.company, Lam Jun Rong от Calif.io, Mufeed VH от Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin от depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin от Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil) и Milan Jovic (Kljunowsky) за независимо привеждане на този проблем в нашето внимание и следване на най-високите стандарти за координирано разкриване.
В freenginx придружаващата информация за поправката всъщност се ограничава до съобщение при комита. В changelog-то тази поправка дори не е отбелязана с подпис "сигурност" (security), нито "поправка" (bugfix), просто "добавяне" (feature). Вероятно авторът не е считал този проблем за критичен. Как се свързват съобщенията за проблема от посочените лица в F5 и заимствания комит от freenginx, съобщавали ли са те (или някой друг) за проблема на автора на freenginx, не успяхме да разберем.
Източник: linux.org.ru
