TL؛ DRپس از مواجهه با سومین سرریز بافر کشفشده در سال ۲۰۲۶ (و طبق گفته F5، یک RCE در صورت عدم وجود ASLR) هنگام کار با regexps و متغیرها، ماکسیم دونین، توسعهدهنده freenginx، تصمیم گرفت که زمان متوقف کردن آن فرا رسیده است و قبل از نوشتن دادهها در محصول خود، یک بررسی اندازه متغیر را به آن اضافه کرد. Nginx از آن زمان این ویژگی را کپی کرده است و این امید را ایجاد کرده است که CVE های جدید مربوط به این مشکل حذف شوند.
حالا برای جزئیات.
۱۹ ژوئن ساخته شد مرتکب شدن در Freenginx، که یک فیلد انتهایی به توصیفگر متغیر اضافه میکند که نشاندهندهی انتهای بافر است. پیش از این، فقط یک اشارهگر به ابتدای آن (pos) وجود داشت، طول مورد نیاز از قبل محاسبه میشد (و هنوز هم محاسبه میشود)، و تا زمانی که دادهها در متغیر کپی میشدند، فرض بر این بود که طول محاسبهشدهی صحیح، تضمین میکند که دادهها در بافر جا میشوند. متأسفانه، این موضوع به دلیل سهلانگاریهای مختلف، دو بار در ماه مه ۲۰۲۶ نادرست ثابت شده است.۲ (linux.org.ru), ۲ (linux.org.ru)) که منجر به سرریز بافر و عواقب ناگواری شد. اکنون، وقتی بافر یک متغیر ایجاد میشود، اشارهگر به انتهای آن نیز پر میشود و قبل از نوشتن داده در متغیر، اگر دادهها جا نشوند، پردازش درخواست با یک خطا به شیوهای کنترلشده خاتمه مییابد. این بدان معناست که خطاهای محاسبه طول ممکن است همچنان ادامه داشته باشند، اما حافظه را هدر نمیدهند؛ آنها فقط درخواست HTTP خاص را با شکست مواجه میکنند. کامیتهای زیر (۳ (freenginx.org), ۳ (freenginx.org)) محافظت مشابهی به سایر بخشهای کد، از جمله کد ثبت دسترسی، اضافه شد. نسخهای از آن در ۷ جولای منتشر شد. فرینجینکس ۱.۳۱.۳، که شامل این اصلاحیه میشود.
در ۱۵ جولای، این کامیتها توسط nginx دریافت شدند (۳ (github.com), ۳ (github.com), ۳ (github.com)، به دلایلی جابجایی دوم و سوم در زنجیره)، مسئله به این صورت تعیین شد CVE-2026-42533و F5 یک خبر رسمی منتشر کرد SA (f5.com).
در مورد آسیبپذیری خاص این بار: این آسیبپذیری هنگام استفاده از دستورالعمل map با regexps با پارامترهای استخراجشده خود را نشان میدهد. در مورد سایر شرایط مورد نیاز برای فعال شدن آن، متن موجود در توضیحات commit و متن موجود در SA کمی متفاوت است: SA بیان میکند که یک رشته خاص باید در مرحله بعد محاسبه شود که از پارامتر استخراجشده باقیمانده از map، قبل از نتیجه همان map استفاده میکند. در توضیحات commit در مثال، بین این مراحل، متغیر حاوی پارامتر استخراجشده نیز صفر میشود. با این حال، بعید است که این اتفاق در اکثر nginxهای در حال اجرا رخ دهد و بنابراین این آسیبپذیری افراد کمی را تحت تأثیر قرار داده است. همچنین شایان ذکر است که اصلاحیهای برای محاسبه طول بهطور خاص برای این مورد در ویرایشهای انجامشده وجود ندارد (یا من بد جستجو کردم؟)، فقط یک محافظت وجود دارد که مشکل را به یک درخواست HTTP کنترلشده ناموفق تبدیل میکند. اگرچه برخی از اصلاحات در 19 جولای به freenginx اضافه شدند (5bfb, 7622, b906) محاسبه طول برای یک موقعیت مشابه، اما بلافاصله مشخص نیست که آیا این مورد صادق است یا خیر.
این آسیبپذیری در نسخه nginx 0.9.6 ظاهر شد، اصلاحاتی در نسخههای freenginx 1.31.3، nginx 1.30.4، nginx 1.31.3 گنجانده شده است.
شرکت nginx SA از تعدادی از افراد به خاطر گزارش مستقل این آسیبپذیری و پایبندی به «استانداردهای افشای هماهنگ» تشکر میکند:
F5 از مینگ ژوان، DKD (@pidifn)، جیآن ژو و ژن یان از AntAISecurityLab، رافائل گاچک، سرگی نگودیوک از EVO.company، لام جون رانگ از Calif.io، موفید وی اچ از Winfunc Research (winfunc.com)، وکسرا ایآی (https://vexera.ai)، تو تران دین (@1w4y)، استن شاو (cyberstan)، qianshuidewajueji، زنث (randomguy6407)، ژنپنگ (لئو) لین از depthfirst، لوکاس یوهانس مولر، ملیح تولگا شاهین از Vodafone Türkiye، ایوب نبیل بوباگرات (GitHub: @ayoubnabil) و میلان یوویچ (Kljunowsky) به خاطر اینکه به طور مستقل این موضوع را به اطلاع ما رساندند و از بالاترین استانداردهای افشای هماهنگ پیروی کردند.
در freenginx، اطلاعات همراه در مورد رفع مشکل در واقع به پیام کامیت محدود میشود. تغییراتاین اصلاحیه حتی به عنوان «امنیت» یا «رفع اشکال» نامگذاری نشده، بلکه فقط «ویژگی» است. ظاهراً نویسنده این مشکل را بحرانی در نظر نگرفته است. تعیین رابطه بین مشکلات گزارش شده توسط افراد فوق الذکر در F5 و کامیت کپی شده از freenginx یا اینکه آیا آنها (یا هر کس دیگری) این مشکل را به نویسنده freenginx گزارش کردهاند یا خیر، غیرممکن است.
منبع: linux.org.ru
