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 версии подобно не е вероятно да срещнете, и уязвимостта по този начин малко хора е засегнала. Следва също така да се отбележи, че поправки за изчисляването на дължината конкретно в този случай в закомитираните поправки изглежда няма (или аз лошо търсих?), има само защита, превръщаща проблема в контролираna грешка на 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
