نموذج من OpenAI تحقّق من ثغرات وكتب تصحيحات لـ948 ثغرة في نواة Linux خلال تشغيل واحد

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

ما الذي أُعلن عنه تحديدا

قال باحثو الأمن في OpenAI إنهم أنشأوا خط أنابيب مستقلا لاكتشاف الثغرات واستغلالها وإصلاحها. وفي تشغيل واحد باستخدام «نموذج سيبراني قيد الإعداد»، تحقّق النظام، بحسب قولهم، من 948 ثغرة لرفع الصلاحيات محليا (LPE) في نواة Linux وأنشأ تصحيحات لها. وينتقل المنشور بعد ذلك إلى تكلفة التشغيل عبر API، لكن النص ينقطع عند هذه النقطة، ولذلك لا يتوفر لدينا الرقم. كما لم تصدر OpenAI النموذج نفسه حتى الآن.

يشير LPE إلى فئة من العيوب يكون فيها المهاجم قد حصل بالفعل على وصول إلى الجهاز بصفته مستخدما عاديا، ثم تتيح له الثغرة التحول إلى root. وفي البيئات السحابية والحاويات والخوادم متعددة المستخدمين، تمثل هذه الفئة الخطوة الثانية التقليدية في سلسلة الهجوم.

لماذا تكتسب كلمة «الاستغلال» أهمية

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

الجزء الثاني هو التصحيحات. فالعثور على 948 عيبا وإرسال 948 رسالة إلى المشرفين على الصيانة يعني إغراقهم بالعمل. أما التصحيح الجاهز للتشغيل عبر الاختبارات فيخفض تكلفة التحقق.

ما الذي لا يظهر في الصورة

من المهم عدم استكمال التفاصيل بالتخمين. لا يتضمن المنشور بيانات عن عدد الثغرات الفريدة من أصل 948، ولا عدد ما قُبل فعليا في الفرع الرئيسي لنواة Linux، ولا نسبة التصحيحات التي تكسر التوافق، ولا عدد النتائج الإيجابية الكاذبة التي استُبعدت. كما لا توجد تكلفة معلنة. وعبارة «تم التحقق منها وإنشاء تصحيحات لها» لا تعني «أُصلحت في النواة». فهذا تقرير ذاتي صادر عن المختبر، وليس تحققا مستقلا، والمنشور بمنزلة عرض لقدرات نموذج مستقبلي.

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

ما الذي ينبغي فعله عمليا

هناك ثلاث خلاصات للمطورين وفرق الأمن.

أولا. إذا كنتم تشرفون على مشروع مفتوح المصدر أو نسخة داخلية متفرعة من النواة، فاستعدوا لزيادة تدفق التقارير الآلية. اضبطوا مسبقا آلية استقبالها: قالب موحد للتقرير، واشتراط نموذج إثبات مفهوم (PoC) قابل لإعادة الإنتاج، ونظام CI يشغّل التصحيحات المرسلة عبر الاختبارات.

ثانيا. احسبوا الجدوى الاقتصادية. عندما تصبح تكلفة التشغيل معروفة، يمكن مقارنتها بتكلفة عمل مختبر الاختراق وتحديد الفحوص التي ينبغي تشغيلها دوريا. لم تقدم OpenAI الرقم في الجزء الظاهر من المنشور، لذا انتظروا النشر الكامل.

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

حتى الآن، لا يعدو الأمر كونه إعلانا بلا تحقق مستقل. لكن الاتجاه واضح: ينتقل الذكاء الاصطناعي في مجال الأمن من تلميحات من نوع «انظر هنا» إلى دورة كاملة من «اكتشف، أثبت، أصلح». وما يستحق المتابعة هو إصدار النموذج وعدد التصحيحات التي سيقبلها مشرفو نواة Linux في النهاية.