هجمات تضخيم QPACK تهدد خوادم HTTP/3

يمكن لعميل بعيد غير موثّق أن يجبر خادم HTTP/3 على تخصيص ذاكرة تفوق ما يرسله بعشرات أو آلاف المرات. ويكفي اتصال واحد لاستنزاف ذاكرة الخادم، أو لتعطيل خادم بإعداداته الافتراضية. ومن بين التطبيقات العشرة التي تم اختبارها، سبعة معرّضة للخطر، وقد تم إصلاح عدة منها بالفعل.

يقوم QPACK بضغط ترويسات HTTP/3 لتقليل حجم البيانات المرسلة عبر الشبكة. وفي التطبيقات المتأثرة، تكون حدود الترويسات بعد فك الترميز مفقودة أو غير مكتملة، أو تُطبَّق متأخرة جدًا. ولذلك يمكن أن يتوسع إطار HEADERS صغير إلى مئات الآلاف من كائنات الترويسات في الذاكرة. ولمنع هذا التوسع، يجب فرض ميزانية تراكمية أثناء فك ترميز الحقول والاحتفاظ بها.

بدأ البحث أثناء دراسة مكدسات QUIC لأداة فحص TLS المسماة JA4Scan، حيث ظهرت الفئة نفسها من الثغرات في عدة تطبيقات لـ HTTP/3. ويحدد RFC 9114 كيفية تقييد حجم الترويسات بعد فك الترميز، لكن بعض التطبيقات تتحقق فقط من حجم الإطار المضغوط، أو تفك ضغط كل شيء قبل التحقق، أو تتجاهل الحمل الإضافي البالغ 32 بايتًا لكل حقل، أو تعتبر القيمة غير محدودة عند عدم ضبط الإعداد، أو لا تطبّق الإعداد أبدًا.

ويعمل الهجوم في اتجاهين. فإطار HEADERS بحجم 1,000,000 بايت يمكن أن يحتوي على نحو 160,000 ترويسة فريدة، بينما يُدرج متغير الجدول الديناميكي مدخلًا كبيرًا واحدًا ويشير إليه آلاف المرات بفهارس من بايت واحد، مما ينتج نسبة 4064:1 في lsquic وBun.

تتوفر إصلاحات لـ quic-go وCloudflare quiche وlsquic وWireshark. أما Bun وh3 crate وaioquic/mitmproxy فبقيت غير مُصلحة حتى 20 أكتوبر 2026. وتشمل إجراءات التخفيف عدم تعريض خوادم HTTP/3 للشبكة العامة، وتعطيل HTTP/3 في mitmproxy، وضبط max_field_section_size معقول في h3. أما IIS وEnvoy وngtcp2/nghttp3 فغير متأثرة.

المصدر: Hacker News · لخّصه HeadlinesBriefing