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
