Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, a remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server's lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. Versions 4.1.132.Final and 4.2.10.Final fix the issue.
Netty HTTP/2 servers prior to versions 4.1.132.Final and 4.2.10.Final are vulnerable to remote Denial of Service attacks through malicious CONTINUATION frame floods. Attackers can bypass size-based mitigations using zero-byte frames to cause excessive CPU consumption with minimal bandwidth, rendering affected services unresponsive. This vulnerability poses significant risk to Saudi organizations operating HTTP/2-based services, particularly in financial and government sectors relying on Netty for API gateways and microservices.
IMMEDIATE ACTIONS:
1. Identify all Netty deployments in your infrastructure using vulnerability scanning tools and dependency analysis (Maven, Gradle, npm registries)
2. Prioritize HTTP/2 enabled services and API gateways for immediate assessment
3. Implement rate limiting on CONTINUATION frames at the load balancer/WAF level (limit to 100 frames per connection)
4. Enable HTTP/2 connection timeout settings (reduce from default 30s to 10s)
PATCHING GUIDANCE:
1. Upgrade Netty to version 4.1.132.Final or 4.2.10.Final immediately upon release
2. For applications unable to upgrade immediately, apply vendor-specific patches if available
3. Test patches in staging environment before production deployment
COMPENSATING CONTROLS (until patch available):
1. Disable HTTP/2 protocol if not critical to operations; revert to HTTP/1.1
2. Implement connection-level rate limiting: max 50 CONTINUATION frames per connection
3. Configure aggressive connection timeout: 5-10 seconds for idle connections
4. Deploy WAF rules to detect and block CONTINUATION frame floods
5. Implement CPU-based circuit breakers to auto-scale or shed load
DETECTION RULES:
1. Monitor for abnormal CONTINUATION frame counts per connection (threshold: >100 frames)
2. Alert on CPU spikes correlating with HTTP/2 traffic patterns
3. Track connection reset rates and incomplete HTTP/2 streams
4. Log and analyze zero-byte frame patterns in HTTP/2 traffic
5. Implement Netty debug logging: enable frame-level logging to detect malformed sequences
الإجراءات الفورية:
1. تحديد جميع نشرات Netty في البنية التحتية الخاصة بك باستخدام أدوات المسح الضوئي للثغرات وتحليل التبعيات (Maven و Gradle و npm)
2. إعطاء الأولوية لخدمات HTTP/2 وبوابات API للتقييم الفوري
3. تنفيذ تحديد معدل إطارات CONTINUATION على مستوى موازن التحميل/WAF (حد أقصى 100 إطار لكل اتصال)
4. تفعيل إعدادات انتهاء صلاحية اتصال HTTP/2 (تقليل من 30 ثانية الافتراضية إلى 10 ثوان)
إرشادات التصحيح:
1. ترقية Netty إلى الإصدار 4.1.132.Final أو 4.2.10.Final فوراً عند الإصدار
2. للتطبيقات غير القادرة على الترقية فوراً، تطبيق التصحيحات الخاصة بالبائع إن أمكن
3. اختبار التصحيحات في بيئة التدريج قبل نشر الإنتاج
الضوابط التعويضية (حتى توفر التصحيح):
1. تعطيل بروتوكول HTTP/2 إذا لم يكن حرجاً للعمليات؛ العودة إلى HTTP/1.1
2. تنفيذ تحديد معدل على مستوى الاتصال: بحد أقصى 50 إطار CONTINUATION لكل اتصال
3. تكوين انتهاء صلاحية الاتصال العدواني: 5-10 ثوان للاتصالات الخاملة
4. نشر قواعد WAF للكشف عن فيضانات إطارات CONTINUATION وحجبها
5. تنفيذ قواطع دوائر قائمة على CPU للتوسع التلقائي أو تقليل الحمل
قواعد الكشف:
1. مراقبة عدد إطارات CONTINUATION غير الطبيعي لكل اتصال (الحد الأدنى: >100 إطار)
2. التنبيه على ارتفاعات CPU المرتبطة بأنماط حركة HTTP/2
3. تتبع معدلات إعادة تعيين الاتصال والتدفقات غير المكتملة HTTP/2
4. تسجيل وتحليل أنماط الإطارات ذات الحجم الصفري في حركة HTTP/2
5. تنفيذ تسجيل تصحيح Netty: تفعيل تسجيل على مستوى الإطار للكشف عن التسلسلات المشوهة