Four Ways to Forge a Bundle My Own Verifier Calls Clean: Refusal-Site Mutation Testing of an Evidence-Bundle Verifier

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

وضع باحث يدعى إريك هيل (Erik Hill) نصب عينيه فحص أحد هؤلاء المدققين، وهو برنامج مصمم للتحقق من حزم الأدلة لنظام يعمل دون اتصال بالإنترنت. أراد معرفة سؤال محدد ومثير للقلق: كم مرة يقول هذا البرنامج "نجح" بينما لم يتحقق من أي شيء بالفعل؟ ولمعرفة ذلك، لم يبحث فقط عن الأخطاء البرمجية؛ بل بنى أداة لكسر المدقق الخاص به بشكل منهجي. أخذ كل سطر كود في البرنامج كان من المفترض أن يرفض حزمة سيئة، وقام، واحدًا تلو الآخر، بإيقاف تشغيلهم. ثم راقب ليرى ما إذا كانت مجموعة الاختبارات الخاصة بالبرنامج ستلاحظ ذلك. إذا استمرت الاختبارات في النجاح بعد إزالة سطر الرفض، فهذا يعني أن سطر الرفض كان عبئًا زائدًا—لم يكن يقوم بأي عمل فعلي. كانت النتائج مذهلة. في بداية الدراسة، كان ثلثا نقاط الرفض في المدقق غير مرئية للاختبارات. كان من الممكن تجريد البرنامج من معظم قدرته على قول "لا"، ومع ذلك سيظل يبلغ عن درجة مثالية. كان الأمر كما لو أن حارس أمن تم تدريبه على التحقق من الأشياء المسروقة، لكن التدريبات لم تتضمن أبدًا وجود عنصر مسروق، لذا لم يتعلم الحارس أبدًا كيف يبحث عنه.

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

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

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

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

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

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