أعلنت وحدة Red Team في Okta عن ثغرة خطيرة في مكتبة OpenSSL أطلق عليها اسم HollowByte، حيث يمكن لمهاجم إرسال طلب TLS لا يتجاوز 11 بايتًا ليجبر الخادم على حجز ما يصل إلى 131 كيلوبايت من الذاكرة لرسالة لن تصل أبدًا. المشكلة تكمن في أن الإصدارات القديمة من OpenSSL كانت تعتمد على طول الرسالة المعلن في رأس الحزمة دون انتظار وصول البيانات الفعلية، مما يؤدي إلى تخصيص الذاكرة بشكل مبكر.
تأثير الثغرة على الأنظمة
في الاختبارات التي أجرتها Okta على خوادم NGINX باستخدام مكتبة glibc، تبيّن أن الذاكرة المحجوزة لا يتم تحريرها بشكل صحيح حتى بعد إنهاء الاتصال، مما يؤدي إلى تجزئة الذاكرة وارتفاع حجمها المقيم بشكل دائم. على سبيل المثال:
- خادم بسعة 1 جيجابايت تم قتله عبر OOM بعد تجميد 547 ميجابايت من الذاكرة.
- خادم بسعة 16 جيجابايت تم تجميد 25% من ذاكرته دون تجاوز الحد الأقصى للاتصالات.
هذا يجعل الهجوم أكثر خطورة من هجمات الحرمان من الخدمة التقليدية مثل Slowloris، إذ أن الدفاعات المعتادة القائمة على تحديد عدد الاتصالات لا توقفه.
موقف OpenSSL من الثغرة
أصدرت OpenSSL إصلاحًا في 9 يونيو 2026 عبر الإصدارات: 4.0.1، 3.6.3، 3.5.7، 3.4.6، 3.0.21، لكن دون أي CVE أو ملاحظة في سجل التغييرات. الفريق الأمني اعتبرها مجرد “إصلاح تقوية” وليس ثغرة أمنية، وهو ما أثار جدلًا واسعًا. فحتى القضايا المصنفة “منخفضة الخطورة” عادةً ما تحصل على CVE وتوثيق رسمي، بينما HollowByte لم يُذكر في أي من صفحات الثغرات أو الملاحظات الرسمية.
الجدل بين Okta و OpenSSL
- Okta ترى أن المشكلة جوهرية لأن الذاكرة لا تعود أبدًا، مما يجعلها ثغرة حرمان من الخدمة حقيقية.
- OpenSSL اعتبرت أن تخصيص 131 كيلوبايت لكل اتصال أمر طبيعي ومحدود، وأن المشكلة أقرب إلى “اختيار نشر” مرتبط بـ glibc وليس خللًا في البروتوكول.
- المطور Alexandr Nedvedicky أوضح أن الاختبار تم على أنظمة OpenBSD التي لا تستخدم glibc، وبالتالي لم يُؤخذ سلوك glibc في الاعتبار.
توصيات الحماية
- الترقية إلى الإصدارات المذكورة أعلاه وإعادة تشغيل الخدمات المرتبطة بـ OpenSSL.
- التحقق من أن التوزيعات مثل Red Hat قد دمجت التصحيح، إذ أن سياسة هذه التوزيعات تعتمد على Backporting مما قد يجعل النسخة المرقعة تحمل نفس رقم الإصدار القديم.
- مراجعة ملفات التصحيح المرتبطة بالطلبات: Pull Request 30792، 30793، 30794.
- مراقبة استهلاك الذاكرة على الخوادم التي تتعامل مع TLS، خصوصًا تلك التي تعتمد على glibc.
ثغرات مرتبطة وإصدارات أخرى
من اللافت أن نفس إصدار يونيو 2026 تضمن إصلاحات لثغرات أخرى حصلت على CVE، مثل:
- CVE-2026-34183 (متوسط الخطورة) المرتبط بنمو غير محدود للذاكرة في معالج QUIC PATH_CHALLENGE.
- CVE-2025-66199 (منخفض الخطورة) المرتبط بضغط الشهادات في TLS 1.3.
لكن HollowByte لم يُصنف رغم أنه يؤدي إلى نفس النتيجة: حرمان من الخدمة عبر استنزاف الذاكرة.
