إغلاق ألف طريق إلى صلاحيات الجذر

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

أصبح توسيع نطاق اكتشاف الثغرات أسهل، لكن تحديد الأولويات والتحقق لا يزالان يشكّلان عقبتين تشغيليتين. بنينا نموذجًا أوليًا للبحث عن عيوب أمنية في نواة Linux ضمن بيئة بحثية مضبوطة. حدد نموذجنا الأولي وحلّل 2,308 نتائج أولية لثغرات محتملة في نواة Linux، وأعاد إنتاج 1,724 ثغرة ديناميكيًا، وأنتج 948 شيفرة استغلال لتصعيد الامتيازات محليًا (LPE)، قد تتيح لمستخدم محلي بلا امتيازات الحصول على صلاحيات الجذر.

استخدمنا هذه الأدلة لترتيب أولويات الإبلاغ عن الثغرات، وطوّرنا تصحيحات مقترحة ليراجعها القائمون على الصيانة. باتباع إرشادات مجتمع نواة Linux، بدأنا بالثغرات الحرجة، ونعمل مع شركاء Patch the Planet على مزيد من التقارير والتصحيحات.

في يونيو، وضمن مبادرتنا Patch the Planet، أعلنّا أن GPT‑5.5 Cyber حدد ثغرات في نواة Linux وطوّر 24 شيفرة استغلال لتصعيد الامتيازات محليًا، للتحقق منها والإبلاغ عنها. وسّعنا هذا العمل إلى مسار معالجة يعتمد على نموذج سيبراني قادم، ويشمل اكتشاف الثغرات، والتحقق الديناميكي، وتقييم قابلية الاستغلال، وتوليد التصحيحات. وعند اكتماله، راجع باحثون بشريون المخرجات وأبلغوا عن الثغرات المكتشفة، مرفقة بتصحيحات.

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

أنتجت المرحلة الأولية لاكتشاف الثغرات آلاف النتائج الأولية، وهو عدد يفوق قدرة الباحثين الأمنيين على مراجعتها وفرزها يدويًا. لم يكن التحدي التشغيلي في مسار اكتشاف الثغرات لدينا هو الاكتشاف نفسه، بل تحديد النتائج التي يمكن إعادة إنتاجها، والحدود الأمنية التي تتجاوزها، وأيّها يستحق اهتمام القائمين على الصيانة أولًا.

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

وأخيرًا، تجدر الإشارة إلى أننا ركزنا في هذا البحث على المنهجية وقياس قدرات النماذج، لا على التكلفة. نتوقع أن استثمار جهد كافٍ في هندسة منظومة التقييم قد يخفض تكلفة كل مرحلة بدرجة ملموسة؛ لذا فإن التكاليف التي نعرضها أقرب إلى حد أعلى.

نموذجنا الأولي للبحث عن الثغرات هو مسار معالجة من خمس مراحل، يعتمد في جوهره على نموذج سيبراني قادم:

• اكتشاف الثغرات: يحدد الوكلاء الأجزاء ذات الصلة بالأمن في قاعدة الشيفرة، ويفحصونها بحثًا عن ثغرات محتملة.

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

• تقييم قابلية الاستغلال: يختبر الوكلاء ما إذا كانت الثغرات المؤكدة تتيح كشف معلومات أو تصعيد الامتيازات محليًا.

• توليد التصحيحات: يولّد الوكلاء تصحيحات تعالج كل ثغرة مكتشفة.

• المراجعة البشرية: يراجع الباحثون الأمنيون شيفرة الاستغلال والتصحيح ودرجة الخطورة المقترحة قبل إبلاغ القائمين على الصيانة.

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

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

يتصفح وكلاء الاستكشاف كل مجلد وملف، ويحددون أهداف التدقيق بناءً على إمكانية وصول المستخدمين محدودي الامتيازات إليها وصلتها بالأمن.

حددت هذه المرحلة 5,034 هدفًا للتدقيق، تضم نحو 2.8 مليون سطر من الشيفرة، أي قرابة 7% من قاعدة شيفرة نواة Linux بأكملها، مما قلّص تكلفة التدقيق الأمني بدرجة كبيرة مقارنة بتحليل قاعدة الشيفرة كاملة. بلغت تكلفة هذه الخطوة 3,426 دولارًا من رصيد الاستخدام لواجهة API.

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

خلال 12 ساعة، أنتج وكلاء التحليل 2,308 نتائج أولية بعد إزالة التكرارات. بلغت تكلفة هذه المرحلة 316,549 دولارًا من رصيد الاستخدام لواجهة API.

النتيجة الأولية ليست ثغرة مؤكدة. بهذا الحجم، لا يستطيع فريقنا البحثي عمليًا التحقيق في كل تقرير يدويًا.

لذلك ركزنا على التحقق من النتائج التي أ) يمكن لمستخدم محدود الامتيازات الوصول إليها، ب) لا تتطلب امتيازات خاصة في Linux ‏(capabilities)، ج) تنتج أدلة قابلة للقياس على تلف الذاكرة.

لكل ثغرة محتملة، ولّد وكيل فرز إثبات مفهوم وشغّله في جهاز افتراضي معزول يعمل بنواة Linux مزوّدة بأداة Kernel Address Sanitizer ‏(KASAN). راقب الوكيل مخرجات البرنامج ووحدة تحكم النظام، ثم حسّن إثبات المفهوم على نحو متكرر حتى أعاد إنتاج السلوك المُبلّغ عنه أو استنفد السبل المحتملة لاستثارته.

خلال 30 ساعة، أعاد نظامنا إنتاج 1724 ثغرة، أي نحو 74.7% من النتائج الأولية البالغ عددها 2,308. قد تؤدي المراجعة الساكنة للشيفرة وحدها إلى نتائج إيجابية كاذبة، لذا أبهرتنا دقة وكلاء التحليل وفاعلية وكلاء الفرز في إنشاء إثباتات مفهوم ناجحة بشكل مستقل لما يقارب ثلاثة أرباع النتائج الأولية.

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

بلغت التكلفة الإجمالية لمرحلة التحقق 73,330 دولارًا من رصيد الاستخدام لواجهة API. لاحظنا أن توليد إثبات مفهوم في مسار التحقق لدينا، للتأكد من أن الثغرة المحتملة حقيقية، كان أعلى تكلفة من تقديم توصية تستند إلى التحليل الساكن وحده. كما كانت تكلفة محاولة التحقق من نتيجة إيجابية صحيحة مشابهة لتكلفة محاولة التحقق من نتيجة إيجابية كاذبة. لذلك، فإن استبعاد النتائج الإيجابية الكاذبة مبكرًا في مسار المعالجة يحسّن كفاءة التكلفة بدرجة ملموسة.

يثبت التحقق أن الثغرة حقيقية، لكنه لا يحدد مدى إلحاح معالجتها. فالثغرة التي قد تتيح تصعيد الامتيازات محليًا، مثلًا، تستحق أولوية أعلى من ثغرة لا تتسبب إلا في حجب الخدمة محليًا. بعد تأكيد 1,724 ثغرة، كانت المهمة التالية تحديد النتائج ذات التأثير الأمني المحتمل الأكبر.

راجع وكيل فرز أولي كل تقرير وسجل انهيار وشيفرة مصدرية ذات صلة باستخدام التحليل الساكن. تعمّدنا جعل معايير الفرز مرنة لتجنب استبعاد نتائج قد تكون خطيرة، مع استبعاد الحالات التي لا تملك مسارًا معقولًا للاستغلال. حصر ذلك النتائج في 313 حالة محتملة لتسرّب المعلومات و1,238 حالة محتملة لتصعيد الامتيازات محليًا.

اختبر وكلاء تطوير الاستغلال (ExploitDev) هذه الحالات بعد ذلك في أجهزة افتراضية معزولة، مضبوطة بآليات الحماية المفعّلة في توزيعة Linux قياسية، بما فيها منع التنفيذ في وضع المشرف (SMEP)، ومنع الوصول في وضع المشرف (SMAP)، وعشوائية تخطيط فضاء عناوين النواة (KASLR)، وHARDENED_USERCOPY. ساعد ذلك على تجنب التقييمات غير الواقعية التي تعتمد على تعطيل آليات الحماية.

أنتج الوكلاء 291 إثبات مفهوم لتسرّب المعلومات و1,169 شيفرة استغلال ناجحة لتصعيد الامتيازات محليًا، قد تمنح صلاحيات الجذر لمستخدمين محليين بلا امتيازات.

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

بلغت تكلفة وكيل الفرز الأولي للثغرات 44,194 دولارًا من رصيد الاستخدام لواجهة API. بلغت التكلفة الإجمالية لمرحلة الاستغلال 775,929 دولارًا من رصيد الاستخدام لواجهة API، منها 84,929 دولارًا لمعالجة حالات تسرّب المعلومات المحتملة و691,000 دولار لحالات تصعيد الامتيازات المحلية المحتملة.

في المتوسط، بلغت تكلفة معالجة حالة محتملة لتصعيد الامتيازات محليًا (558 دولارًا) نحو ضعف تكلفة معالجة حالة محتملة لتسرّب المعلومات (271 دولارًا). ويعود ذلك إلى أن إثباتات مفهوم تسرّب المعلومات نُقلت من مرحلة التحقق، واحتاجت إلى تعديلات أقل لتصبح قابلة للاستخدام في شيفرة استغلال. في المقابل، تطلّب تطوير شيفرة استغلال لحالة محتملة لتصعيد الامتيازات محليًا خطوات إضافية عديدة، مثل التخطيط لاستراتيجية الاستغلال، وتحديد الكائنات المعرّضة للثغرة لاستخدامها، وتجاوز آليات الحماية، وغيرها. لاحظنا أيضًا أن محاولات الاستغلال غير الناجحة (3,922 دولارًا لـ69 حالة) كانت أعلى تكلفة بكثير من المحاولات الناجحة (360 دولارًا لـ1169 حالة). كان ذلك بسبب عدد قليل من الثغرات التي يصعب استغلالها (مثل حالات التسابق). كان من شأن تحديد شرط معقول للتوقف، مثل إيقاف المحاولة بعد مرور ساعة بلا تقدم، أن يقلّص تكلفة ExploitDev بدرجة كبيرة.

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

اتباعًا لاقتراح مجتمع نواة Linux، أرسلنا بالفعل مئات التقارير والتصحيحات للثغرات الحرجة، ونعمل مع شركاء Patch the Planet على إرسال تصحيحات بقية الثغرات تدريجيًا. هذا العمل جزء من التزامنا الأوسع ضمن Daybreak بدعم المشاريع مفتوحة المصدر.

نشارك في هذا القسم الدروس والاستنتاجات والتحليلات الإضافية المستخلصة من هذا البحث.

لاحظنا خلال هذا البحث أن القائمين على صيانة Linux يتحركون بسرعة لإصلاح الثغرات وحماية المستخدمين. أُجري الفحص على أحدث نواة Linux في منتصف أكتوبر 2026. وعندما انتهى الفحص المستقل والتحليل اليدوي بعد 10 أيام، كان قد جرى بالفعل تصحيح 61 ثغرة لتصعيد الامتيازات محليًا في المشروع الأصلي، وكانت هناك تصحيحات قيد التجهيز لـ43 ثغرة، بينما كان يجري الإبلاغ عن 299 ثغرة ومناقشتها علنًا.

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

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

في أثناء تطوير مسار المعالجة، وتحديدًا في أواخر يوليو 2026، اكتشف GPT‑5.6 Sol واستغل 166 ثغرة فريدة لتصعيد الامتيازات محليًا، بتكلفة إجمالية بلغت 513,690 دولارًا من رصيد الاستخدام لواجهة API.

في الفحص الثاني، في منتصف أكتوبر 2026، اكتشف النموذج السيبراني الأحدث واستغل 948 ثغرة فريدة لتصعيد الامتيازات محليًا، بتكلفة إجمالية بلغت 1,213,430 دولارًا من رصيد الاستخدام لواجهة API. في كلتا الحملتين، فحصنا أحدث نسخة متاحة آنذاك من فرع master لنواة Linux.

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

أخذنا عينة من 166 شيفرة استغلال طوّرها الوكلاء، وحلّلنا تقنيات الاستغلال المستخدمة فيها. على حد علمنا، استخدم الوكلاء 10 تقنيات استغلال جديدة في شيفرات العينة. شاركنا تقنيات الاستغلال مع خبراء خارجيين في استغلال النواة، وكانت هذه التقنيات جديدة عليهم أيضًا.

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

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

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

كانت الأجهزة الافتراضية المستهدفة في تجربتنا تعمل بنظام تشغيل مكتبي بإعداداته الأصلية، لا بإعدادات أُضعفت عمدًا، وفق نموذج التهديد نفسه المستخدم في مسابقات الأمن السيبراني (مثل Pwn2Own⁠(يفتح في نافذة جديدة) وTyphoonPWN⁠(يفتح في نافذة جديدة)). سبق أن قدمت Pwn2Own وTyphoonPWN مكافآت لاكتشاف الثغرات بقيمة 20,000 دولار و70,000 دولار على التوالي مقابل شيفرات استغلال لتصعيد الامتيازات محليًا في نواة Linux. وبتطبيق مبالغ المكافآت السابقة على شيفرات الاستغلال البالغ عددها 948، نحصل على قيمة افتراضية تتراوح بين 18.9 مليون و66.3 مليون دولار، أي نحو 16 إلى 55 ضعف تكلفة مسار المعالجة لدينا.

اختبرنا مسار المعالجة لدينا أيضًا على برنامج Google لمكافآت الثغرات kernelCTF⁠(يفتح في نافذة جديدة)، الذي يستهدف نواة Linux معززة الحماية وذات أسطح هجوم مُقلّصة. شغّلنا مسار المعالجة على أحدث إصدار من نواة Linux ضمن بيئة kernelCTF (وهو غير متوافق مع آلية الحماية SLAB_VIRTUAL في kernelCTF، لذا حذفناها من الإعدادات)، وحصلنا على 25 إثبات مفهوم لتسرّب المعلومات و21 شيفرة استغلال لتصعيد الامتيازات محليًا. للمقارنة، حتى وقت كتابة هذا النص، كان برنامج kernelCTF قد قبل 26 شيفرة استغلال مؤكدة لثغرات يوم الصفر لتصعيد الامتيازات محليًا خلال عام 2026. استغرقت الحملة بأكملها 112 ساعة، بتكلفة بلغت نحو 32,936 دولارًا من رصيد الاستخدام لواجهة API، وشكّلت مرحلة اكتشاف الثغرات 83.7% من تكلفة API. لو قُبلت الثغرات الـ21 في البرنامج، لأثمرت عن مكافأة تبلغ نحو 1.5 مليون دولار، أي قرابة 45 ضعف التكلفة.

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

خلال تقييم قابلية الاستغلال، تلقى وكلاء تطوير الاستغلال (ExploitDev) تقريرًا عن ثغرة، وكُلّفوا بإنشاء شيفرة استغلال تعمل بالكامل. كان مسار المعالجة لدينا يصنّف الثغرة على أنها استُغلت عند النجاح في الحصول على صدفة أوامر بصلاحيات الجذر. خلال تشغيل مبكر، أبلغت مرحلة الاستغلال عن 200 شيفرة استغلال ناجحة لتصعيد الامتيازات محليًا. لكن بعد المراجعة البشرية، وجدنا أن 20 منها حصلت على صلاحيات الجذر عبر ثغرة يوم صفر مختلفة عن الثغرة المكلّفة بها. يشير هذا إلى أن استغلال الوكلاء للثغرات يحتاج إلى تحقق ملائم، حتى عندما ينجح.

شدّدنا لاحقًا قيود المهمة، وأضفنا فحصًا مستقلًا يؤكد أن كل شيفرة استغلال نهائية تستخدم الثغرة المحددة لها.

الدرس المستفاد: في البحث الأمني المستقل، تحقّق من المسار المؤدي إلى النتيجة، إلى جانب التحقق من النتيجة نفسها؛ فالعزل والمراقبة والفحوص المستقلة ضوابط ضرورية.

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

قارنت التجربة بين GPT‑5.5 Cyber وGPT‑5.6 Cyber. لاحظنا أن GPT‑5.5 Cyber لم يكن يحدد على نحو متسق متى وكيف يطبّق تقنيات استغلال نواة Linux المعروفة. جمعنا بعد ذلك 103 تقنيات بصيغة يسهل على النموذج استخدامها، وأتحناها في بيئة الوكيل، ووجّهناه إلى استخدامها. في 63 حالة مرشحة للاستغلال، رفع ذلك معدل النجاح من 76.2% إلى 88.9%.

وعندما كررنا التجربة باستخدام GPT‑5.6 Cyber، كان النموذج أقدر على العثور على التقنيات المناسبة واختيارها وتطبيقها بنفسه. أزلنا تنسيق التقنيات والمهارات، فتفوّق سير عمل GPT‑5.6 Cyber بهذا التنسيق البسيط على سير عمل GPT‑5.5 Cyber ذي البنية الداعمة الأكثر تعقيدًا. لم تحقق إعادة إضافة طبقة التقنيات الإضافية إلى GPT‑5.6 Cyber سوى تحسن هامشي قدره 1.5 نقطة مئوية.

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

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

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

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

في تشغيل kernelCTF، وإلى جانب شيفرات الاستغلال الـ21 لثغرات يوم الصفر في نواة Linux، اكتشف نموذجنا البحثي الأولي أيضًا ثغرة في QEMU TCG واستغلها. كُلّف وكيل التحليل بتحليل شيفرة الدخول لاستدعاءات النظام، وفي أثناء كتابة برامج لاختبار الانتقال بين مستويات الامتيازات، واجه انهيارًا غير متوقع للنواة. فحص الانهيار وحدد منشأ المشكلة في QEMU TCG، من دون الوصول إلى الشيفرة المصدرية لـQEMU، وأدرج الثغرة في التقرير. نجح وكيل ExploitDev لاحقًا في تطوير شيفرة استغلال لتصعيد الامتيازات محليًا عبر هذه الثغرة. اكتشفنا ثغرة QEMU هذه عند تحليل شيفرات الاستغلال يدويًا، وتأكدنا من أنها أُصلحت في مشروع QEMU الأصلي، لكن ليس في نسخة الإصدار المستخدمة خلال التجربة.

الدرس المستفاد: تستطيع النماذج الرائدة ذات القدرات السيبرانية اكتشاف ثغرات في البنية التحتية للاختبار. نوصي باختبار كل جزء من البنية التحتية قبل إجراء أبحاث هجومية عن الثغرات. لقد اختبرنا بنيتنا التحتية استباقيًا، وأفصحنا عن العديد من الثغرات وصححناها في Kata وMoby/Docker وgVisor ومشاريع أخرى.

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

من خلال Patch the Planet، إحدى مبادرات Daybreak، نهدف إلى توسيع نطاق هذا البحث ليشمل المزيد من المشاريع البرمجية الحيوية، وتطوير آليات موثوقة للترقيع الآلي بالتعاون مع القائمين على صيانتها وشركائنا الأمنيين. نريد تقليص الفرص المتاحة للمهاجمين باستمرار، وزيادة تكلفة اكتشاف الثغرات واستغلالها، حتى يصبح العائد المتوقع غير كافٍ لتبرير الهجوم.

ينبغي أن يساعدنا كل جيل من النماذج على بناء برمجيات يصعب على الجيل التالي اختراقها. سنواصل العمل نحو بناء إنترنت آمن يتيح للجميع متعة الابتكار والبناء.