الخلاصة

  • أصلح Debian في مايو/أيار 2008 تغييراً خاصاً بحزمة OpenSSL جعل مولّد الأرقام العشوائية قابلاً للتوقع. حمى التحديث المفاتيح التي ستُنشأ لاحقاً، لكنه لم يغيّر مفاتيح SSH وOpenVPN وDNSSEC وX.509 التي وُلدت منذ سبتمبر/أيلول 2006 وانتقلت إلى أنظمة أخرى.
  • احتاج الإصلاح الفعلي إلى سلسلة قرارات موزعة: إثبات منشأ الاعتماد، رفض العائلات الضعيفة المعروفة، إنشاء بديل بعشوائية سليمة، توثيق توزيع البديل، حذف التفويض القديم أو إلغاء الشهادة، ثم اختبار أن كل جهة اعتماد مهمة ترفض المفتاح السابق.

أصلح التحديث المستقبل وترك الماضي في مكانه

عندما نشر Debian التنبيه DSA-1571-1 في 13 مايو/أيار 2008، كان الوصف المباشر هو أن مولّد الأرقام العشوائية في حزمة OpenSSL الخاصة به قابل للتوقع. بعد تثبيت الحزمة الجديدة، صار الاستدعاء التالي للمولّد سليماً. أما المفتاح الذي أُنشئ في اليوم السابق فلم تتغير بتاته.

لم يكن المفتاح الضعيف ملفاً تالفاً بالضرورة. كان يُقرأ بصورة طبيعية، وتتطابق فيه الأجزاء العامة والخاصة، وتنجح به براهين SSH. وقد تحمل شهادة X.509 توقيعاً صحيحاً من مُصدرها وتبقى داخل مدة الصلاحية. موضع الخلل كان في تاريخ سري لا يظهر في البنية: اختيار المفتاح الخاص من فضاء أصغر كثيراً مما توحي به الخوارزمية.

لهذا أوصى DSA-1571-1 بإعادة إنشاء كل المادة المشفرة التي وُلّدت بواسطة الإصدارات المتأثرة ابتداءً من 0.9.8c-1. وميّز مفاتيح DSA: حتى المفتاح القوي عند الإنشاء يمكن أن ينكشف إذا استُخدم على نظام متأثر لتوقيع يعتمد على قيمة عشوائية سرية قابلة للتوقع.

رسم Ubuntu حدود الحادث بحسب رحلة المفتاح، لا اسم نظام التشغيل. الأنظمة المبنية على Debian حملت المولّد المعيب مباشرة. لكن نظاماً سليماً من عائلة أخرى يمكن أن يستورد مفتاحاً ضعيفاً ويمنحه سلطة دخول. كان للخلل موطن برمجي، أما الاعتماد فكان قابلاً للنقل.

فضاء صغير خلف مظهر تشفيري كبير

بدأ سجل Debian رقم 363516 في أبريل/نيسان 2006 بملاحظات Valgrind حول قراءة ذاكرة غير مهيأة في مولّد OpenSSL. ناقش السجل معالجة الضوضاء التشخيصية. وأوضح لاحقاً أن التغيير الهش دخل مسار البناء الفعلي مع 0.9.8c-1 عندما نُقل ملف md_rand.c المعدّل إلى الموضع المستخدم في التجميع.

تشرح وثيقة SSLkeys النتيجة التشغيلية. اعتمد المولّد المكسور عملياً على رقم العملية. ومع 32,767 مساراً محتملاً في كل واحدة من ثلاث فئات معمارية، يصف النموذج 98,301 مسار. ولأنواع وأطوال شائعة، أمكن إعداد مفاتيح مرشحة مسبقاً ومطابقة المفتاح العام المرصود بنصفه الخاص.

ليس 98,301 إحصاءً لكل المفاتيح الضعيفة أو الهجمات. تختلف طريقة استدعاء التطبيقات للمكتبة، والأطوال والخوارزميات والمعماريات، ولم تغط القوائم السوداء كل حالة. لكنه يثبت انقلاباً اقتصادياً: يُنشر المفتاح العام لأن اشتقاق الخاص منه يفترض أن يكون غير عملي؛ هنا ساعد العام على تحديد عنصر من كتالوج قابل للحساب.

احتفظ المفتاح بمظهر الندرة، بعدما فقد الندرة الحقيقية التي تستند إليها سلطته.

أوقف Debian القبول بإجراء منفصل

بعد وقت قصير من التنبيه، عطّل مشروع Debian تسجيل الدخول بمفاتيح SSH العامة على أنظمته. احتاجت عمليات النقل والبناء والإدارة المعتمدة على المفاتيح إلى إثبات سلامة الاعتماد أو استبداله.

هذا الإجراء يثبت الفصل بين المسارين. لو كان تحديث المكتبة يُلغي المفاتيح القديمة، لما احتاج المشروع إلى إغلاق بوابته. أصلح Debian المصدر، ثم استخدم سلطته المحلية كجهة اعتماد لرفض الماضي.

في اليوم التالي، أضاف DSA-1576-1 حزمتَي openssh-blacklist وssh-vulnkey. استطاع الخادم رفض مفاتيح المستخدم الضعيفة المعروفة حيث يمكن كشفها، وأمكن إعادة توليد مفاتيح المضيف بموافقة المدير. إلا أن الثقة تحركت في اتجاهين مختلفين.

عند تغيير مفتاح المضيف، يرى العميل تحذير تغير هوية الطرف البعيد. الإصلاح المشروع والهجوم الوسيط يبدوان متشابهين في تلك اللحظة. لذلك يجب التحقق من البصمة الجديدة عبر قناة موثوقة مستقلة، لا تعطيل التحذير جماعياً.

أما مفتاح المستخدم الجديد فيجب إدخال جزءه العام في كل خادم وحذف السطر القديم من كل authorized_keys. إضافة البديل من دون إزالة السابق تخلق طريقين للدخول ولا تنهي سلطة السر القابل للتخمين.

كانت الحزمة والقائمة السوداء والمفتاح البديل وقناة التحقق وسطر التفويض لدى مالكين مختلفين. لا يستطيع أي عنصر أن يدّعي أنه أنهى السلسلة كلها.

القائمة السوداء حق رفض محلي محدود

أتاح صغر فضاء المرشحين دفاعاً غير معتاد: تعداد المفاتيح العامة الضعيفة المعروفة ثم مقارنة الاعتماد المقدم بها. تحولت الأدلة المنشورة إلى قاعدة رفض قابلة للتنفيذ.

لكن نشر القائمة لم يغلق باباً عن بعد. تعمل فقط عندما تثبت الحزمة المناسبة، ويفهم المحلل الصيغة، ويكون نوع المفتاح وطوله مغطى، وينفذ التطبيق فرع الرفض. قال Debian إن الرفض يتم «حيثما أمكن». وأوضح Ubuntu أن نتيجة Unknown (no blacklist information) لا تعني أن المفتاح آمن؛ تعني أن corpus الحالي لا يملك حكماً.

كشف DSA-1576-2 حدود الأداة الأولى. كان يمكن أن تتجاهل أسطر authorized_keys التي تبدأ بخيارات، مثل أمر مفروض أو منع تحويل المنافذ. يستمر الخادم في قبول المفتاح، بينما لا يراه التقرير. ثم وسّع Ubuntu لاحقاً تغطية شهادات X.509 وطلبات التوقيع والمعاملات الخام وأطوال RSA إضافية.

بقيت القائمة مفيدة: يستطيع نظام لم يتأثر مولّده قط أن يرفض مفتاحاً ضعيفاً مستورداً، ويمنع إعادته مستقبلاً. لكن قوة النتيجة لا تتجاوز المحلل والقائمة والصيغة المغطاة. التطابق سبب كافٍ للرفض؛ غيابه ليس شهادة أمان.

سبب واحد وطرق تقاعد متعددة

ذكر CERT مفاتيح SSH وOpenVPN وDNSSEC وX.509. جمعتها عشوائية معيبة ولم يجمعها زر إلغاء واحد.

في SSH للمستخدم، توجد السلطة في ملفات التفويض البعيدة؛ والإغلاق يثبت عندما يفشل المفتاح القديم في كل خادم مهم. في هوية مضيف SSH، توجد الثقة في known_hosts لدى العملاء وفي توثيق البصمة الجديدة.

في OpenVPN، يجب استبدال السر المشترك عند كل الأطراف بالتنسيق. وفي النمط القائم على الشهادات، يلزم إصدار جديد ورفض القديم. شدد USN-612-3 على العثور على المفاتيح التي أُنشئت لأنظمة أخرى واستبدالها هناك.

في X.509، لا يمحو إنشاء مفتاح وشهادة جديدين الشهادة السابقة. ينشر المُصدر حالة الإلغاء، وينشر الخادم السلسلة الجديدة، ويحصل العميل على حالة حديثة. يحدد RFC 5280 معالجة الشهادات وقوائم الإلغاء، لكنه لا يجعل كل عميل مثبت يستشيرها فوراً.

في DNSSEC، قد يكون المفتاح دخل تفويضات موقعة وحالات مخبأة. وفي الأتمتة، قد يعيش في صورة أو نسخة احتياطية أو جهاز أو نظام شريك. حذف الملف من آلة الإنشاء لا يغير قرار أي جهة اعتماد بعيدة.

كانت وحدة الإصلاح هي نسب الاعتماد: أين أُنشئ، أين نُسخ، أي سلطة يمثل، من يقبله، ومن يستطيع رفضه.

صحة رياضية بلا أساس شرعي

يتحقق SSH من امتلاك السر المقابل للمفتاح العام. لا يتحقق من أن الشخص الشرعي وحده يعرف السر. من أعاد حساب المفتاح الخاص الضعيف يستطيع إنتاج برهان صحيح رياضياً.

بقيت الصحة الفنية بعدما انهار أساس الشرعية التشغيلية.

تصلح ملاحظات Lu Heng المنشورة عن أولوية الكود العامل كعدسة تحليلية، لا كمصدر لتسلسل Debian التاريخي. التنبيه والتصحيح والقائمة السوداء وحالة الشهادة معلومات وقواعد. يصبح الرفض فعلياً عندما ينفذه خادم SSH أو طرف VPN أو عميل PKI. تحكم Debian في حزمه وأنظمته، لا في كل ملف تفويض سافر إليه مفتاح.

وفي المقابل، لا يخرج نظام لم يكن مولّده هشاً من الحادث إن كان يقبل مفتاحاً مستورداً. تقع السيطرة العملية عند نقطة الاعتماد المحلية، ومعها مسؤولية الإبقاء على حق رفض قابل للتحقق.

أربعة سجلات لإغلاق الحادث

يسجل دفتر الإنشاء التاريخ والحزمة والمكتبة والتطبيق والمعمارية والخوارزمية والطول. ويسجل دفتر التوزيع النسخ الخاصة والشهادات والخوادم وauthorized_keys وknown_hosts وأطراف VPN والصور والنسخ الاحتياطية والشركاء.

يربط دفتر الاستبدال البصمة القديمة بالجديدة وقناة توثيقها والمسؤول والموعد. ويثبت دفتر الرفض أن المفتاح القديم يفشل، والشهادة القديمة تُرفض عند العملاء المختبرين، وكل استثناء محدود وله تاريخ نهاية.

تقيس نسبة التصحيح بداية العمل. يقيس رصيد السلطة القديمة نهايته.

حدود الأدلة

لا تقدم المصادر الرسمية عدداً كاملاً للمفاتيح الضعيفة أو الاستغلالات. 98,301 نموذج محدود. لا تثبت Unknown سلامة ولا ضعفاً. قد تغيّر النسخ الاحتياطية أو الساعة الخاطئة تاريخ الملف. استخدم GnuPG وGnuTLS مصادر أخرى. اختلف التجديد الآلي لمفتاح المضيف حسب الحزمة واختيار المدير. لا يثبت إصدار شهادة جديدة أن جميع العملاء راجعوا الإلغاء.

النتيجة المدعومة أدق: حمى المولّد المصحح المستقبل، وبقيت الاعتمادات القديمة ذات سلطة حتى رفضتها كل نقطة قبول.

المصادر