إحدى عشرة بايت ستجعل خادم OpenSSL غير المصحح يخصص ما يصل إلى 131 كيلو بايت من الذاكرة للرسالة التي لا تصل أبدًا. في أنظمة glibc التي تم اختبارها بواسطة Okta، اختفت تلك الذاكرة حتى تتم إعادة تشغيل العملية.
قام OpenSSL بشحن ملف هولو بايت سيتم الإصلاح في شهر يونيو بدون أي مكافحة التطرف العنيف أو الاستشارات أو أي إدخال في سجل التغيير يشير إليه. ونشر فريق 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، كان ذلك كافيًا لمنع المُخصص من إعادة استخدام ما حرره. أجزاء الكومة، ويتسلق حجم المجموعة المقيمة، ويظل متسلقًا لفترة طويلة بعد رحيل المهاجم.
في اختبار NGINX الذي أجرته شركة Okta، تم إيقاف خادم سعة 1 جيجابايت بواسطة OOM مع تجميد ذاكرة تبلغ 547 ميجابايت في أجزاء. على خادم سعة 16 جيجابايت، قامت شركة HollowByte بحجز 25% من ذاكرة النظام دون تجاوز سقف الاتصال على الإطلاق، ولهذا السبب يقول الفريق الأحمر “الدفاعات القياسية التي تحد من الاتصال لن توقفه”.
هذه الأرقام مملوكة لشركة Okta، ولم تنشر أي تعليمات برمجية للاستغلال بجانبها. لم تجد Hacker News أي مستودع عام لإثبات المفهوم على GitHub اعتبارًا من 18 يوليو.
قرر OpenSSL أن هذه ليست ثغرة أمنية
طلب السحب من Matt Caswell، الذي كتب التصحيح، يوضح الأمر بوضوح: اختار فريق الأمان “التعامل مع هذا باعتباره إصلاحًا فقط لخلل أو تصلب”. تحدد سياسة الأمان الخاصة بـ OpenSSL أربعة مستويات خطورة، من الحرجة إلى المنخفضة، وليس من بينها “الخلل أو التصلب”.
حتى الإصدار المنخفض يحصل على CVE، ومذكرة بسجل التغيير، وإدخال في صفحة نقاط الضعف. لا يوجد في HollowByte أي من الثلاثة. لم تجد Hacker News أي إشارة للإصلاح في ملاحظات الإصدار أو في جميع الإدخالات الـ 23 لسجل التغيير 4.0.1 الخاص بـ OpenSSL.
لم يذكر OpenSSL السبب. هذا هو الحال بالنسبة لهم: 131 كيلو بايت لكل اتصال صغير، وكل خادم TLS يخصص الذاكرة لكل اتصال، والتخصيص المحدود ليس ثغرة أمنية. إجابة أوكتا هي أن الذاكرة لا تعود أبدًا.
سألت 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، المصنف متوسطًا، لنمو الذاكرة غير المحدود في معالج QUIC PATH_CHALLENGE. كلاهما DoS مرهق للذاكرة. كلاهما حصل على أرقام.
أغلق الإصدار أيضًا 18 مشكلة خطيرة خطيرة، بما في ذلك الاستخدام عالي الخطورة بعد الاستخدام المجاني في PKCS7_verify()، لذا فإن أي شخص يقوم بتشغيل إحدى هذه الإصدارات الأولية لديه الإصلاح دون إخباره.
المصب هو أسوأ. الإعداد الافتراضي الموثق لـ Red Hat هو النقل الخلفي للإصدار بدلاً من نقله، لذلك تظل الحزمة المصححة تبلغ عن الإصدار الذي تم إنشاؤه منه. ما يحل هذه المشكلة عادة هو الاستشارة والموجز البيضاوي، وكلاهما مرتبط بأسماء مكافحة التطرف العنيف. لا يوجد هنا برنامج مكافحة التطرف العنيف.
هذا يترك سجل تغيير الحزمة أو المشرف: اسأل ما إذا كانوا قد استندوا إلى إصدار 9 يونيو أو أخذوا التصحيح، وهو طلب السحب 30792 للإصدار الرئيسي و4.0، و30793 للإصدارات 3.6، و3.5، و3.4، و30794 للإصدار 3.0.
إذا قمت بإنشاء OpenSSL بنفسك، فقم بالترقية إلى الإصدار المدرج وأعد تشغيل أي إصدار قام بتحميل الإصدار القديم.
يغطي الإصلاح TLS فقط. كتب Caswell في طلب السحب أنه تم ترك DTLS بمفردها لأن القيام بذلك بشكل صحيح سيكون أكثر تدخلاً بكثير، وأن المشروع قرر عدم الاهتمام به في الوقت الحالي. قارنت Hacker News مصدر OpenSSL في العلامتين 3.6.2 و3.6.3 ووجدت أن ملف مصافحة DTLS متطابق بالبايت عبر عملية الإصلاح. في الإصدار 4.0.1، الإصدار الأحدث، لا يزال هذا المسار يقيس حجم المخزن المؤقت الخاص به من الطول الذي يعلنه النظير.
لم يقم OpenSSL بتصنيف هذا المسار أو الالتزام بإصلاحه. ملاحظات الإصدار، وسجل التغيير، وصفحة نقاط الضعف لا تذكر شيئًا عن ذلك. طلب السحب يفعل.
