تعتبر ثغرة HollowByte في OpenSSL من القضايا الأمنية الهامة التي تستدعي الانتباه. في هذه المقالة، سنستعرض تفاصيل هذه الثغرة وتأثيرها على خوادم OpenSSL.
إن 11 بايت ستجعل خادم OpenSSL غير المحدث يحتفظ بما يصل إلى 131 كيلوبايت من الذاكرة لرسالة لم تصل أبداً. على أنظمة glibc التي اختبرتها Okta، تبقى تلك الذاكرة مفقودة حتى يتم إعادة تشغيل العملية.
قامت OpenSSL بإصدار تصحيح HollowByte في يونيو دون وجود CVE، أو إشعار، أو إدخال في سجل التغييرات يشير إليه. وقد نشرت فرقة Red Team في Okta، التي أبلغت عن خطأ الحرمان من الخدمة وأطلقت عليه اسم، التفاصيل يوم الخميس.
الإصدارات التي تم إصلاحها هي OpenSSL 4.0.1، 3.6.3، 3.5.7، 3.4.6، و3.0.21، جميعها مؤرخة في 9 يونيو. كل إصدار على تلك الفروع قبل الإصدارات المحدثة يحتوي على هذا الخطأ. لا يوجد شيء في عملية التصحيح العادية يشير إليهم: لا يوجد معرف يمكن للمسح مطابقته ولا إشعار يمكن قراءته.
العيب هو أن OpenSSL أخذت كلمة المهاجم على محمل الجد. كل رسالة مصافحة TLS تحمل رأسًا من 4 بايت، ثلاثة بايت منها تعلن عن طول الجسم. كانت الإصدارات القديمة تزيد من حجم ذاكرة الاستقبال إلى الحجم المعلن في اللحظة التي وصلت فيها الرأس، قبل أن تظهر أي بايت من الجسم، وقبل أن تعمل فحوصات المصافحة نفسها.
بالنسبة لـ ClientHello الواردة، الحد الأقصى هو 131 كيلوبايت. ثم يقوم خيط العمل بالانتظار، في انتظار جسم لم يأتِ. لا مصادقة، لا جلسة، لا تبادل مفاتيح.
الذاكرة لا تعود
بحد ذاتها، هذه هجمة استنفاد الاتصال، وتلك قديمة مثل Slowloris. ما يجعل HollowByte يتمسك هو glibc. عندما يقوم المهاجم بإسقاط الاتصال، يقوم OpenSSL بتحرير الذاكرة، لكن glibc يحتفظ بقطع صغيرة ومتوسطة لإعادة الاستخدام بدلاً من إعادتها إلى النواة.
تختلف الهجمة في الحجم المعلن في كل اتصال، وفي اختبارات Okta، كان ذلك كافيًا لمنع الموزع من إعادة استخدام ما تم تحريره. تتفتت الذاكرة، ويزداد حجم مجموعة الذاكرة المقيمة، وتبقى مرتفعة لفترة طويلة بعد مغادرة المهاجم.
في اختبار Okta لـ NGINX، تم قتل خادم بحجم 1 جيجابايت بسبب نفاد الذاكرة مع تجميد 547 ميجابايت من الذاكرة في شظايا. على خادم بحجم 16 جيجابايت، قام HollowByte بتجميد 25% من ذاكرة النظام دون تجاوز سقف الاتصال، ولهذا السبب تقول فرقة Red Team “لن توقفه الدفاعات القياسية لتحديد الاتصال”.
تلك الأرقام هي من Okta نفسها، ولم تنشر أي كود استغلال بجانبها. لم تجد Hacker News أي مستودع إثبات مفاهيم عام على GitHub اعتبارًا من 18 يوليو.
قررت OpenSSL أن هذا ليس ثغرة
تضع طلب السحب من مات كاسويل، الذي كتب التصحيح، الأمر بوضوح: اختار فريق الأمان “التعامل مع هذا كتصحيح ‘خطأ أو تعزيز’ فقط”. تعرف سياسة الأمان الخاصة بـ OpenSSL أربعة مستويات من الخطورة، من حرجة إلى منخفضة، و”خطأ أو تعزيز” ليست من بينها.
حتى المشكلة المنخفضة تكسب CVE، وإدخال في سجل التغييرات، وإدخال في صفحة الثغرات. لا يحتوي HollowByte على أي من الثلاثة. لم تجد Hacker News أي ذكر للتصحيح في ملاحظات الإصدار أو في جميع 23 إدخالًا في سجل تغييرات OpenSSL 4.0.1.
لم توضح OpenSSL السبب. هنا هو الموقف من جانبهم: 131 كيلوبايت لكل اتصال هو حجم صغير، كل خادم TLS يخصص ذاكرة لكل اتصال، والتخصيص المحدود ليس ثغرة. إجابة Okta هي أن الذاكرة لا تعود أبدًا.
سألت Hacker News OpenSSL لماذا تم تصنيف HollowByte أدنى من منخفض، وما إذا كان التصحيح وصل إلى الفروع ذات الدعم الممتد 1.1.1 و1.0.2. كما سألت Okta عما إذا كانت التجزئة تبقى على قيد الحياة في الموزعين بخلاف glibc. سيتم تحديث هذه القصة مع أي رد.
خط المشروع أدق مما يبدو. في يناير، خصصت OpenSSL CVE-2025-66199، المصنفة منخفضة، لخطأ ضغط الشهادات TLS 1.3 حيث نما طول مزود من قبل نظير قبل التحقق، بقيمة حوالي 22 ميغابايت لكل اتصال.
تطلب ذلك أربعة أشياء لتتوافق: ضغط الشهادات تم تجميعه، خوارزمية ضغط متاحة، تم التفاوض على الامتداد، وعلى الخوادم، طلبت شهادات العميل. لا يحتاج HollowByte إلى أي من تلك.
خصص إصدار 9 يونيو أيضًا CVE-2026-34183، المصنفة متوسطة، لنمو الذاكرة غير المحدود في معالج PATH_CHALLENGE لـ QUIC. كلاهما هجمات DoS لاستنفاد الذاكرة. كلاهما حصل على أرقام.
أغلق الإصدار أيضًا 18 CVE، بما في ذلك استخدام بعد التحرير عالي الخطورة في PKCS7_verify()، لذا فإن أي شخص يقوم بتشغيل أحد تلك الإصدارات الأساسية لديه التصحيح دون أن يتم إخطاره.
الوضع في الأسفل أسوأ. الافتراض الموثق من Red Hat هو التحديث بدلاً من تغيير الإصدار، لذا فإن الحزمة المحدثة لا تزال تبلغ عن الإصدار الذي تم إنشاؤها منه. ما يحل عادةً ذلك هو الإشعار وتغذية OVAL، وكلاهما مرتبط بأسماء CVE. لا يوجد CVE هنا للربط به.
هذا يترك سجل تغييرات الحزمة أو المسؤول: اسأل عما إذا كانوا قد أعادوا بناء الإصدار في 9 يونيو أو أخذوا التصحيح، وهو طلب السحب 30792 للماستر و4.0، و30793 لـ 3.6، 3.5، و3.4، و30794 لـ 3.0.
إذا كنت تقوم ببناء OpenSSL بنفسك، قم بالترقية إلى الإصدار المدرج وأعد تشغيل أي شيء قام بتحميل القديم.
التصحيح يغطي TLS فقط. كتب كاسويل في طلب السحب أن DTLS تُركت بمفردها لأن القيام بذلك بشكل صحيح سيكون أكثر تدخلاً بكثير، وأن المشروع قرر عدم الإزعاج بذلك في الوقت الحالي. قارن Hacker News مصدر OpenSSL عند علامات 3.6.2 و3.6.3 ووجد أن ملف المصافحة DTLS متطابق بالبايت عبر التصحيح. في 4.0.1، أحدث إصدار، لا يزال ذلك المسار يقوم بحجم ذاكرته من الطول الذي يعلنه النظير.
لم تصنف OpenSSL ذلك المسار أو تلتزم بإصلاحه. لا تقول ملاحظات الإصدار، سجل التغييرات، وصفحة الثغرات أي شيء حوله. يفعل طلب السحب.
في الختام، من الضروري أن يقوم مسؤولو الأنظمة بتحديث خوادم OpenSSL الخاصة بهم لتجنب المخاطر المرتبطة بثغرة HollowByte. تابعوا تحديثات الأمان لضمان حماية بياناتكم.
