أتمتة إنشاء واجهة اختبار التضبيب (Fuzzing) باستخدام النماذج اللغوية الكبيرة والتحسين التطوري

ضرورة ودافع البحث

تعتبر البرمجيات العمود الفقري للعديد من الخدمات الحيوية في المجتمعات الحديثة. اليوم، تعتمد الأنظمة المصرفية، وشبكات توزيع الطاقة، والبنية التحتية للاتصالات، وحتى الخدمات الصحية على صحة وأمن الأكواد. هذا الاعتماد جعل أي ثغرة برمجية لم تعد مجرد خطأ تقني بسيط، بل يمكن أن تحمل عواقب اقتصادية وأمنية واجتماعية خطيرة. تزداد أهمية هذه المشكلة بشكل خاص في المكتبات المكتوبة بلغات C و C++؛ وهي المكتبات التي استُخدم العديد منها لسنوات أو حتى عقود في البنية التحتية للبرمجيات اليوم. في عام 2024 وحده، تم تسجيل أكثر من أربعين ألف ثغرة أمنية جديدة في قاعدة بيانات CVE، وجزء كبير من هذه الثغرات يتعلق بهذه الأنظمة البيئية القديمة ولكنها لا تزال مستخدمة على نطاق واسع.

في مثل هذه البيئة، أصبح “اختبار التضبيب” (Fuzzing test) أحد أكثر الطرق فعالية لاكتشاف الثغرات تلقائياً. تقوم أدوات مثل AFL و libFuzzer بتحديد مسارات تنفيذ جديدة من خلال التنفيذ المتكرر للبرنامج على مدخلات متغيرة (Mutated)، والاحتفاظ بالمدخلات التي تؤدي إلى اكتشاف سلوكيات جديدة وتطويرها. أظهر نجاح هذا النهج في مشاريع مثل OSS-Fuzz الخاص بـ Google و syzkaller أن اختبار التضبيب يمكن أن يكشف آلاف الأخطاء والثغرات الحقيقية على نطاق واسع.

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

مشكلة البحث والفجوة الحالية

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

في السنوات الأخيرة، تم اقتراح أدوات مختلفة للإنشاء التلقائي لواجهة اختبار التضبيب. على سبيل المثال، يقوم FuzzGen بإنشاء الواجهة من خلال التحليل الثابت (Static analysis) لتبعيات الـ API، ولكنه لا يغيرها بعد الإنشاء ولا يستخدم ملاحظات تنفيذ الفازر لتحسينها. تستخدم أدوات مثل OSS-Fuzz-Gen و HarnessAgent النماذج اللغوية الكبيرة لإنشاء الواجهة ويمكنها إصلاح أخطاء الترجمة البرمجية (Compilation) إلى حد ما، لكن هذه العملية تبقى في الغالب على المستوى النحوي. بمجرد ترجمة الكود بنجاح، لا توجد عادة آلية للتحسين المنطقي والتدريجي للواجهة.

النهج المقترح

الفكرة الأساسية لهذا البحث بسيطة ولكنها مهمة: إذا كانت المدخلات في اختبار التضبيب تتغير (Mutate) لاكتشاف مسارات جديدة في البرنامج، فلماذا لا تتغير واجهة الاختبار نفسها؟ بدلاً من إعطاء مدخلات جديدة دائماً لواجهة ثابتة، يمكن تغيير الواجهة نفسها لتفعيل أجزاء أكبر من الـ API وتوفير مسارات تنفيذ جديدة للفازر. وبناءً على ذلك، تم تحديد تصميم واجهة اختبار التضبيب في هذا البحث كمشكلة تحسين تطوري متعددة الأهداف على الكود المصدري.

مراحل عملية الدورة التطورية للنظام:

في إطار العمل هذا، لا يقتصر دور النموذج اللغوي الكبير على كونه مولد كود لمرة واحدة فقط، بل يلعب دور “عامل الطفرة الدلالية” (Semantic mutation operator). هذا الدور هو الفارق الرئيسي بين النهج المقترح والطرق السابقة.

النتائج التجريبية

تم تقييم الإطار المقترح على إحدى عشرة مكتبة C و C++ متنوعة. في سبع حالات، أي أكثر من 63% من الاختبارات، تمكن النظام من إنشاء تغطية كود قابلة للقياس وتحسين واجهة اختبار التضبيب عبر الأجيال المتعاقبة. كانت الحالات غير الناجحة مرتبطة بشكل أساسي بتبعيات الترجمة المعقدة أو واجهات برمجة تطبيقات (APIs) محددة للغاية؛ وهو وضع عانى فيه النموذج اللغوي أحياناً من افتراضات غير صحيحة أو هلوسات.

تم تحقيق أبرز نتيجة في مكتبة GPAC للوسائط المتعددة. في هذه الحالة، زادت تغطية الحواف من 75 حافة في الجيل الصفر إلى 231 حافة في الجيل الثامن؛ أي بنمو يعادل 208%. توضح هذه النتيجة أن الحلقة التطورية تمكنت من تغيير الواجهة بمرور الوقت بطريقة تفعل المزيد من مسارات التنفيذ. بالمقارنة مع HarnessAgent، وهو إحدى الأدوات المتقدمة الموجودة في هذا المجال، كان الفرق كبيراً.

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

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

أهمية البحث

يمكن دراسة أهمية هذا البحث على عدة مستويات، ويمكن تصنيف إنجازاته في ثلاثة مجالات عامة:

الخاتمة

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

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