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 визнають 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 depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin of Vodafone Türki @ayoubnabil), і Milan Jovic (Kljunowsky) для незалежного bringing this issue до нашої аттенції і спричиняючи високі стандарти з coordinated disclosure.
У freenginx інформація про виправлення, що супроводжує, фактично обмежується повідомленням при коміті. У змін-е дане виправлення навіть позначено ні підписом «безпека» (security), ні «виправлення» (bugfix), просто «додавання» (feature). Ймовірно, автор не вважав цю проблему критичною. Як співвідносяться повідомлення про проблему з боку зазначених осіб у F5 і запозичений з freenginx коміт, чи повідомляли вони (чи хтось ще) про проблему автору freenginx, з'ясувати не вдалося.
Джерело: linux.org.ru
