Core Lightning يفرض تعتيماً أمنياً طارئاً لمدة 14 يوماً بعد سيل بلاغات ثغرات مولّدة بالذكاء الاصطناعي

طلب مطوّرو Core Lightning (CLN) من مشغّلي العُقد اتخاذ قرار أمني قبل اكتمال تقييم الخطر بشكل نهائي. وفي رسالة بتاريخ 23 أغسطس نُشرت على Stacker News، حثّ الفريق المشغّلين على تثبيت ملفات تنفيذية جديدة تعالج عدة ثغرات مُبلغ عنها. وأبلغ CLN المشغّلين الذين يرفضون الترقية بضرورة تشغيل عُقدهم بوضع عدم الاتصال، مع الإبقاء على التفاصيل التقنية تحت الحظر لمدة أسبوعين. يعتزم الفريق إرفاق توقيعات المطوّرين بالملفات التنفيذية لتمكين المستخدمين من التحقق من المصدر وإمكانية إعادة البناء. وتُظهر وثائق CLN أن عملية الإصدار تعتمد على وسوم موقّعة (signed tags) ومجاميع تحقق موقّعة (signed checksums) وبناءات قابلة لإعادة الإنتاج (reproducible builds)، بما يتيح للمشغّلين التأكد من أن الحزمة خرجت عبر مسار الإصدار المقصود. رغم ذلك، لا يستطيع المشغّلون حالياً فحص الأدلة التي يستند إليها تقييم الخطر لدى CLN، ولا استنتاج آلية الاستغلال من المواد المتاحة علناً. كما لا تتوفر معلومات كافية لتحديد ما إذا كان إعداد عقدة بعينه يواجه الخطر ذاته. ما الذي يمكن التحقق منه الآن، وما الذي يبقى مجهولاً خلال فترة الحظر - أصل البرمجيات: يمكن التحقق من أن الملفات التنفيذية جاءت عبر عملية إصدار CLN المقصودة؛ غير المعروف هو ما إذا كانت الإصلاحات تمس جميع إعدادات العُقد. - صحة الإصدار: الوسوم الموقّعة ومجاميع التحقق الموقّعة متاحة للتحقق؛ غير المعروف هو آليات الثغرات بدقة. - سلامة البناء: البناءات القابلة لإعادة الإنتاج تربط بين الشيفرة المصدرية والملف التنفيذي؛ غير المعروف هو ما إذا كانت الإصدارات الأقدم تكشف مسار هجوم محدداً. - اعتماد القائمين على الصيانة: توقيعات الفريق تؤكد ملكية الإصدار؛ غير المعروف هو شدة كل مشكلة مُبلّغ عنها. - الاستجابة التشغيلية: توصية CLN هي الترقية أو العمل دون اتصال؛ غير المعروف هو ما إذا كان العمل دون اتصال ضرورياً لكل مشغّل. حظر المعلومات يخلق تراتبية مؤقتة بدأت السلسلة تقريباً في 13 أغسطس، عندما أعلن CLN تلقيه عدة بلاغات CVE مولّدة بالذكاء الاصطناعي من مصادر متعددة على مدى نحو 10 أيام. شرع الفريق في التحقق من البلاغات، وانضم مساهمون من مجتمع المصادر المفتوحة، بالتوازي مع بدء المطورين إعداد إصلاحات. وبحلول 23 أغسطس كان الفريق يجهّز ملفات تنفيذية تتضمن إصلاحات لعدد كبير من الثغرات المُبلّغ عنها، كما ذكر أنه سيتوقف عن دعم الإصدارات السابقة، بما فيها 26.04، "نظراً للمخاطر المعروفة". خلال الربع الثاني، شحنت Blockstream إصدارين من CLN: الإصدار 26.04 في أبريل و26.06 في يونيو. وأشار تحديث الربع الثاني إلى إدراج 26.09 ضمن خارطة طريق الربع الثالث. المواد المتاحة لا تقدم دليلاً على استغلال فعلي على نطاق واسع، ولا أساساً لاعتبار جميع البلاغات متساوية في الخطورة. لذلك يواجه المشغّل طبقتين من التحقق: الأولى تخص سلامة "القطعة البرمجية" نفسها (التواقيع، مجاميع التحقق، البناءات القابلة لإعادة الإنتاج). والثانية تخص طبيعة التهديد، إذ ما زالت التفاصيل التقنية غير كافية للحكم على أثر الثغرات أو ما إذا كان العمل دون اتصال مناسباً لكل حالة. الإفصاح المنسّق يوازن بين الشفافية وتقليل ميزة المهاجم قد يتأخر نشر الأدلة بسبب الإفصاح الأمني المنسّق، لأن نشر التفاصيل يغيّر أيضاً مجموعة المعلومات المتاحة للمهاجمين. وتوضح إرشادات CERT للإفصاح المنسّق عن الثغرات أن الهدف هو تقليص أفضلية الخصم خلال المعالجة، مع التمييز بين توفر الرقعة (patch availability) ووصولها فعلياً للمستخدمين (patch deployment). خيارات الإفصاح: الفائدة مقابل المخاطر - الإفصاح الفني الكامل فوراً: يمكّن المشغّلين من تقييم مستقل؛ لكنه قد يكشف مسار الاستغلال قبل تحديث العُقد. - حظر مؤقت مع ملفات تنفيذية موقّعة: يمنح وقتاً للترقية بأمان؛ لكنه يفرض ثقة مؤقتة في تقدير القائمين على الصيانة. - توفر الرقعة دون انتشار واسع: الإصلاح جاهز للمستعدين؛ العُقد غير المحدثة تبقى مكشوفة. - تأخير نشر التفاصيل العامة: يقلل أفضلية المهاجم خلال التحديث؛ قد يخلق شكوكاً أو تردداً. - الإفصاح بعد انتهاء الحظر: يعيد إمكانية التحقق المستقل؛ استمرار الثقة يعتمد على نشر الأدلة بوضوح. قد يساعد الإفصاح التفصيلي مهاجمين مهرة على تحديد المسار الضعيف في البرمجيات الأقدم، ما يضع المشغّلين غير المحدثين أمام خطر مسلح بالمعلومات نفسها التي كانوا يطلبونها للتحقق. في المقابل، تقلص الملفات التنفيذية الموقّعة مساحة الثقة المطلوبة: يمكن للمشغّلين التحقق ممن أنتج الإصدار، ويمكن للبناءات القابلة لإعادة الإنتاج تأكيد العلاقة بين المصدر والملف التنفيذي. تظل البرمجيات في بيتكوين معتمدة جزئياً على الحكم البشري في هذه الطبقة، لأن القائمين على الصيانة هم من يقررون ما إذا كان بلاغ ما يستحق معالجة طارئة، بينما يقرر مهندسو الإصدارات توقيت شحن الإصلاح، وتحدد فرق الأمن مقدار المعلومات التي يمكن مشاركتها قبل أن يتحول الإفصاح إلى خطر إضافي. سيناريوهان: تعزيز الثقة أو تآكلها السيناريو الإيجابي يفترض نجاح العملية بسلاسة: يتحقق المشغّلون من صحة الإصدار ويحدثون إلى نسخة مُرقّعة، ثم تنشر Core Lightning التفاصيل التقنية التي تبرر التحذير. عندها تنتهي الثقة المؤقتة إلى أدلة قابلة للفحص المستقل، ما يعزز الثقة في القائمين على الصيانة ومسار الإصدار. السيناريو السلبي يبدأ بتردد بعض المشغّلين في الترقية دون الاطلاع على نموذج التهديد، فيما قد يختار آخرون العمل دون اتصال. وتوثّق Core Lightning أن هذا الوضع يمنع العقدة من الارتباط بالمنافذ أو إعادة الاتصال بالأقران. وقد يؤدي تأخر التحديثات أو زيادة العُقد غير المتصلة إلى خفض توافر التوجيه في أجزاء من الشبكة. كما قد يتحول طول الفجوة بين التحذير وتقديم الأدلة إلى مشكلة مصداقية. الذكاء الاصطناعي يضغط نافذة "تحقق لاحقاً" يضيف الذكاء الاصطناعي قيداً جديداً على نموذج الإفصاح. فقد عدّلت Google برنامج مكافآت ثغرات برمجيات المصادر المفتوحة في مارس بعد رصد "قفزة هائلة" في التقارير المولّدة بالذكاء الاصطناعي، وأشارت إلى أن كثيراً منها تضمن معلومات غير صحيحة أو مسارات استغلال متخيلة. وبدأت الشركة اشتراط أدلة أقوى لبعض مستويات البلاغات كي تركز فرق الفرز على التهديدات الموثوقة. كيف يتغير الضغط عبر مراحل الإفصاح - استقبال البلاغات: سابقاً كانت الاكتشافات تصل بوتيرة محدودة عبر باحثين؛ الآن يمكن أن تصل دفعات كبيرة مولّدة آلياً. - الفرز (Triage): كان التمييز بين الثغرات والضوضاء تحدياً معتاداً؛ الآن يلزم تصفية الهلوسات والبلاغات الضعيفة بسرعة أكبر. - التحقق: إعادة إنتاج العيوب وترتيبها حسب الشدة؛ قد يرفع الأتمتة الحجم قبل أن يؤكد البشر الخطورة. - تطوير الرقعة: بناء إصلاحات قبل نشر التفاصيل؛ قد تعيد أطراف أخرى اكتشاف العيب خلال الحظر. - طرح التحديث للمستخدمين: التحديث قبل الإفصاح الكامل؛ قد يستخدم المهاجمون الفروقات أو الملفات التنفيذية للبحث أسرع. - الإفصاح النهائي: تصبح الأدلة قابلة للفحص المستقل؛ قد تتقلص فترة "تحقق لاحقاً". تعكس رسائل CLN هذا العبء: تقارير متعددة مولّدة بالذكاء الاصطناعي وصلت من عدة مصادر خلال نحو 10 أيام، وظل على البشر التحقق منها قبل التعامل معها كعِلل أمنية. وكانت Google قد عرضت سابقاً أن فحص العيوب بالذكاء الاصطناعي (AI-generated fuzzing) قادر على كشف ثغرات في مشاريع مصادر مفتوحة ناضجة، بما في ذلك OpenSSL. وفي الوقت نفسه، فإن الأدوات التي تخفض كلفة اكتشاف الثغرات قد تجعل إعادة اكتشافها أسهل بمجرد توفر ملف مُرقّع أو فرق شيفرة أو إشارة تقنية. النتيجة أن القائمين على الصيانة يحتاجون نافذة للتحقق من العيب، ونافذة أخرى لتوزيع الإصلاح قبل انتشار معرفة الاستغلال. وقد يستهلك الذكاء الاصطناعي النافذة الأولى عبر حجم البلاغات، ويضغط الثانية عبر البحث الآلي الأسرع. التشفير يقلل الثقة المطلوبة للتحقق من المعاملات والأرصدة ومخرجات البناء البرمجي، لكن الأمن التشغيلي قد يفرض قدراً من الثقة المؤقتة في تقدير القائمين على الصيانة عندما يؤدي الإفصاح الفوري إلى تحسين موقف المهاجم. ويُفترض أن يغلق إفصاح Core Lightning اللاحق هذه الفجوة. إلى ذلك الحين، فإن من يقوم بالترقية يقبل شكلاً محدوداً من الثقة داخل منظومة صُممت أساساً حول التحقق المستقل. نُشر هذا التقرير أولاً لدى CryptoSlate بعنوان: "Onslaught of AI-found bugs forces Bitcoin's Core Lightning into a secret 14-day emergency lockdown".