‏بمب HTTP/2 که Codex پیداش کرد

نویسنده‌ٔ مقاله که خودش ۱۴ سال پیش تو شکستن فشرده‌سازی هدر HTTP نقش داشته و بعد بازبینی اصلاحیه‌ای که تبدیل به HPACK تو HTTP/2 شد رو به عهده گرفته بوده، حالا از یه حمله‌ٔ جدید به اسم HTTP/2 Bomb رونمایی می‌کنه؛ یه حمله‌ٔ منع سرویس (DoS) از راه دور علیه بیشتر وب‌سرورهای بزرگ مثل nginx، Apache httpd، Microsoft IIS، Envoy و Cloudflare Pingora. نکته‌ٔ ترسناک اینه که این رفتار آسیب‌پذیر تو پیکربندی پیش‌فرض همه‌شون وجود داره.

به گفتهٔ نویسنده، این حمله رو ابزار هوش مصنوعی Codex کشف کرده، با زنجیر کردن دو تکنیکی که هر دو یه دهه‌ست برای آدم‌ها شناخته‌شده بودن. تکنیک اول یه بمب فشرده‌سازیه که HPACK (طرح فشرده‌سازی هدر تو HTTP/2) رو هدف می‌گیره: HPACK یه جدول پویا از هدرهای اخیر نگه می‌داره و فرستنده می‌تونه یه هدر رو یه‌بار وارد جدول کنه و بعد فقط با یه بایت بهش ارجاع بده، ولی سرور برای هر ارجاع یه کپی کامل از اون هدر تو حافظه می‌سازه. پس یه بایت روی سیم تبدیل به یه تخصیص حافظهٔ کامل می‌شه، اونم هزاران بار تو یه درخواست.

تکنیک دوم یه نگه‌داشت سبک Slowloris هست. تو HTTP/2 کلاینت پنجره‌ٔ کنترل جریان پاسخ سرور رو کنترل می‌کنه؛ مهاجم یه پنجرهٔ صفر بایتی اعلام می‌کنه که سرور هیچ‌وقت نتونه پاسخشو تموم کنه، و با فریم‌های کوچیک WINDOW_UPDATE تایم‌اوت رو مدام ریست می‌کنه تا همهٔ اون حافظه‌ٔ تخصیص‌داده‌شده برای مدت طولانی پین بمونه. ترکیب این دو یعنی هم تقویت حافظه و هم نگه‌داشتنش.

به گفتهٔ مقاله، چیز جدید این حمله جای تقویته. بمب کلاسیک یه مقدار بزرگ رو تو جدول می‌چپوند و بارها بهش ارجاع می‌داد، برای همین سرورها یاد گرفتن کل اندازهٔ هدر دیکد‌شده رو محدود کنن. ولی این نسخه برعکس عمل می‌کنه: خود هدر تقریباً خالیه و تقویت از سربار حسابداری per-entry میاد که سرور دورش تخصیص می‌ده، برای همین محدودیت اندازهٔ دیکد اصلاً فعال نمی‌شه. برای سرورهایی که به‌جاش تعداد فیلد هدر رو محدود می‌کنن (Apache و Envoy)، هدر Cookie راه دور زدنه، چون RFC اجازه می‌ده Cookie به چند فیلد تقسیم بشه و این سرورها این تکه‌ها رو نمی‌شمردن.

نتایج عملی نگران‌کننده‌ست: یه کامپیوتر خانگی روی اتصال ۱۰۰ مگابیتی می‌تونه یه سرور آسیب‌پذیر رو ظرف چند ثانیه از دسترس خارج کنه. روی Apache httpd و Envoy یه کلاینت تنها می‌تونه حدود ۳۲ گیگابایت حافظهٔ سرور رو ظرف تقریباً ۲۰ ثانیه اشغال و نگه داره. ضریب تقویت روی Envoy حدود ۵٬۷۰۰ به ۱ و روی Apache حدود ۴٬۰۰۰ به ۱ می‌رسه، در حالی که روی nginx و IIS حدود ۷۰ به ۱ هست. نویسنده می‌گه بازی مؤثرتر این نیست که پروسه OOM بشه (چون worker کشته‌شده تمیز ری‌استارت می‌شه)، بلکه نگه داشتن فشار حافظه درست زیر آستانه‌ٔ کشتن و فرستادن سرور تو swap تا بقیهٔ درخواست‌ها لاک‌پشتی بشن.

برای رفع مشکل، nginx تو نسخهٔ ۱.۲۹.۸ دایرکتیو max_headers رو با مقدار پیش‌فرض ۱۰۰۰ اضافه کرده و Apache هم با شمردن هدرهای cookie تو LimitRequestFields اصلاحش کرده (شناسهٔ CVE-2026-49975). برای IIS، Envoy و Pingora موقع نوشتن مقاله وصله‌ای نبوده و توصیه اینه که اگه می‌شه HTTP/2 خاموش بشه. درس کلی‌تر اینه که «حداکثر اندازهٔ هدر دیکد‌شده» و «حداکثر تعداد هدر» دو محدودیت متفاوتن و سرور به هر دو نیاز داره؛ ضمناً باید عمر یه stream متوقف‌شده رو هم محدود کرد. نویسنده تأکید می‌کنه وقتی پنج پیاده‌سازی مستقل همگی همین کلاس باگ رو منتشر می‌کنن، نقص تو خود استانداردهه.

نکات کلیدی:

• HTTP/2 Bomb یه حملهٔ DoS از راه دوره که nginx، Apache، IIS، Envoy و Pingora رو تو پیکربندی پیش‌فرض می‌زنه
• ابزار هوش مصنوعی Codex با ترکیب دو تکنیک ده‌سالهٔ شناخته‌شده (بمب HPACK و نگه‌داشت Slowloris) کشفش کرد
• یه کلاینت خانگی می‌تونه ظرف چند ثانیه سرور رو از کار بندازه؛ تا ۳۲ گیگ حافظه با ضریب تقویت تا ۵٬۷۰۰:۱ روی Envoy
• تقویت جدید از سربار حسابداری per-entry میاد، نه از حجم هدر؛ برای همین محدودیت اندازهٔ دیکد فعال نمی‌شه
• رفع: nginx ۱.۲۹.۸+ با max_headers، Apache با CVE-2026-49975؛ برای IIS/Envoy/Pingora فعلاً خاموش کردن HTTP/2