TL, д-р: Сутыкнуўшыся з трэцім выяўленым за 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 acknowledges Ming Xuan, DKD (@pidifn), Ji'an Zhou, і Zhen Yan of AntAISecurityLab, Rafael Gacek, Sergii Negodiuk of EVO.https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Лео) Lin of depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin of Vodafone Türki @ayoubnabil), і Milan Jovic (Kljunowsky) для незалежна прымаючы гэтую паслугу і нас ацэньваюць і сфармуляваць высокія стандарты радыкальнай disclosure.
У freenginx суправаджальная інфармацыя аб выпраўленні фактычна абмяжоўваецца паведамленнем пры коміце. У змяненняў-е дадзенае выпраўленне нават не пазначана ні подпісам "бяспека" (security), ні "выпраўленне" (bugfix), проста "даданне" (feature). Верагодна, аўтар не лічыў дадзеную праблему крытычнай. Як суадносяцца паведамленні аб праблеме з боку паказаных асоб у F5 і запазычаны з freenginx коміт, паведамлялі яны (ці хтосьці яшчэ) пра праблему аўтару freenginx, высветліць не ўдалося.
Крыніца: linux.org.ru
