آسیب‌پذیری جدید در پروتکل HTTP/3: حملات تقویت QPACK و خطرات اتمام حافظه

بررسی‌های امنیتی اخیر روی پشته‌های مختلف QUIC و پروتکل HTTP/3 نشان داده است که یک آسیب‌پذیری ساختاری مشترک در نحوه پردازش و دیکد کردن هدرها وجود دارد. این نقص که به حملات تقویت QPACK مربوط می‌شود، به مهاجمان راه دور و احرازویت‌نشده اجازه می‌دهد با ارسال ترافیک دستکاری‌شده، سرور را وادار به تخصیص حافظه‌ای کنند که ده‌ها یا هزاران برابر بزرگ‌تر از حجم داده ارسالی روی شبکه است.

پس‌زمینه و مفهوم QPACK

پروتکل HTTP/3 برای به حداقل رساندن حجم ترافیک ارسالی، از مکانیزم فشرده‌سازی هدر به نام QPACK استفاده می‌کند. در این روش، فیلدهای تکرارپذیر مانند User-Agent یا Content-Type به جای متن کامل، به صورت ایندکس‌های کوچک (بر اساس جداول استاتیک و دینامیک) ارسال می‌شوند. برای مثال، یک هدر طولانی می‌تواند به یک بایت ساده تبدیل شود.

بر اساس استاندارد RFC 9114، سرورها موظفند برای جلوگیری از سوءاستفاده، محدودیت مشخصی برای اندازه هدرهای دیکد شده اعمال کنند و سربار ۳۲ بایتی هر فیلد را در محاسبات خود لحاظ نمایند. با این حال، تحقیقات نشان داد که بسیاری از پیاده‌سازی‌های محبوب این قوانین را به‌درستی پیاده‌سازی نکرده‌اند:

• بررسی اندازه فریم فشرده شده به جای داده‌های دیکد شده.
• عدم اعمال محدودیت تجمعی (Cumulative Budget) برای کل هدرها.
• فراموش کردن سربار ۳۲ بایتی استاندارد در محاسبات حافظه.
• پیش‌فرض‌گرفتن حالت نامحدود (Unlimited) در صورت عدم تنظیم دقیق.

جزئیات فنی حمله (Header Accordions)

مهاجمان از دو روش اصلی برای این سوءاستفاده استفاده می‌کنند:

• بمب هدرهای منحصربه‌فرد: ارسال یک فریم HEADERS با هزاران نام فیلد مختلف و کوچک که باعث ایجاد ورودی‌های مجزا در نقشه حافظه سرور می‌شود.
• سوءاستفاده از جدول دینامیک (Dynamic Table Trick): درج یک هدر بزرگ (حدود ۴ کیلوبایت) در جدول دینامیک و سپس ارجاع دادن مکرر و هزاران‌باره به آن با شناسه‌های تک‌بایتی. هر ارجاع باعث کپی‌برداری و تخصیص کامل حافظه جدید می‌شود (نسبتی بیش از ۴۰۰۰ به ۱).

وضعیت کتابخانه‌ها و پشته‌های مختلف

بر اساس گزارش‌ها، تعدادی از پشته‌های معروف HTTP/3 آسیب‌پذیر شناخته شده‌اند که برخی از آن‌ها وصله‌های امنیتی خود را ارائه کرده‌اند:

• quic-go: کتابخانه محبوب زبان Go (مورد استفاده در Caddy و Cloudflared) اندازه هدر فشرده را محدود می‌کرد اما حجم دیکد شده را بررسی نمی‌کرد که اکنون با استفاده از مکانیزم افزایشی و خطای HTTP 431 اصلاح شده است.
• Cloudflare quiche: به دلیل عدم احتساب سربار ۳۲ بایتی و آسیب‌پذیری پیش‌تخصیص بافر فریم‌ها دچار مشکل بود که در نسخه 0.29.3 برطرف شد.
• lsquic و Bun: در محیط Bun به دلیل جایگزینی برخی توابع و عدم بررسی محدودیت تجمعی، حمله می‌تواند علاوه بر اتمام حافظه (OOM)، سرور را به دلیل یک باگ سرریز عدد صحیح وارد حلقه بی‌نهایت پردازشی کند و به یک Denial of Service دائمی تبدیل شود.
• aioquic / mitmproxy: کتابخانه پایتون که تنظیمات مربوط به محدودیت اندازه را می‌خواند اما هرگز در هنگام دیکد کردن اعمال نمی‌کند.
• سایر موارد: کتابخانه h3 در اکوسیستم Rust به دلیل سرریز شدن ظرفیت نقشه هدر دچار Panic می‌شود. جالب اینجاست که حتی ابزار تحلیل شبکه Wireshark نیز به دلیل پردازش کنترل‌نشده تعداد هدرها دچار کرش می‌شد.

چرا این مسئله برای مهندسان مهم است؟

این آسیب‌پذیری نشان می‌دهد که اعتماد به مکانیزم‌های فشرده‌سازی استاندارد بدون پیاده‌سازی دقیق محدودیت‌های منابع (Resource Limits) و بودجه‌بندی تجمعی حافظه، چه خطرات بزرگی به همراه دارد. برای توسعه‌ندگانی که از پروکسی‌ها، دروازه‌های API یا سرورهای مبتنی بر HTTP/3 استفاده می‌کنند، اطمینان از به‌روزرسانی کتابخانه‌های زیرساختی و تنظیم دقیق پارامترهایی نظیر max_field_section_size اهمیت حیاتی دارد.

در بحث‌های جامعه هکرنیوز نیز اشاره شد که از آنجا که این حمله از نوع مصرف حافظه و DoS است، هرچند خطرات اجرای کد از راه دور را ندارد، اما به راحتی می‌تواند سرویس‌های پیش‌فرض را از دسترس خارج کند و بسیاری از کتابخانه‌ها طی ماه‌های گذشته وصله‌های لازم را منتشر کرده‌اند.