google/aflamerican fuzzy lop - أداة تشويش موجَّهة للأمان
طُوِّر في الأصل بواسطة Michal Zalewski [email protected].
انظر QuickStartGuide.txt إذا لم يكن لديك الوقت لقراءة هذا الملف.
الاختبار العشوائي (Fuzzing) هو أحد أقوى الاستراتيجيات وأكثرها إثباتًا لتحديد المشكلات الأمنية في البرمجيات الواقعية؛ وهو مسؤول عن الغالبية العظمى من ثغرات تنفيذ التعليمات البرمجية عن بُعد وثغرات تصعيد الامتيازات المكتشفة حتى الآن في البرمجيات الحساسة أمنيًا.
لسوء الحظ، فإن الاختبار العشوائي ضحل نسبيًا أيضًا؛ فالطفرات العشوائية العمياء تجعل من غير المرجح للغاية الوصول إلى مسارات برمجية معيّنة في الكود المُختبر، تاركةً بعض الثغرات بعيدة تمامًا عن متناول هذه التقنية.
كانت هناك محاولات عديدة لحل هذه المشكلة. أحد الأساليب المبكرة - التي ابتكرها تافيس أورماندي (Tavis Ormandy) - هو تقطير المجموعة (corpus distillation). تعتمد هذه الطريقة على إشارات التغطية لاختيار مجموعة فرعية من البذور المثيرة للاهتمام من مجموعة ضخمة عالية الجودة من الملفات المرشحة، ثم اختبارها عشوائيًا بالوسائل التقليدية. يعمل هذا النهج بشكل استثنائي، لكنه يتطلب أن تكون هذه المجموعة متاحة بسهولة. بالإضافة إلى ذلك، فإن قياسات تغطية الكتل لا توفر سوى فهمًا مبسطًا للغاية لحالة البرنامج، وتكون أقل فائدة لتوجيه جهود الاختبار العشوائي على المدى الطويل.
أما الأبحاث الأخرى الأكثر تطورًا فقد ركّزت على تقنيات مثل تحليل تدفق البرنامج (التنفيذ المختلط "concolic execution")، والتنفيذ الرمزي (symbolic execution)، أو التحليل الثابت (static analysis). جميع هذه الأساليب واعدة للغاية في البيئات التجريبية، لكنها تميل إلى المعاناة من مشاكل في الموثوقية والأداء في الاستخدامات العملية - ولا تقدم حاليًا بديلًا قابلاً للتطبيق عن تقنيات الاختبار العشوائي "الغبية" (dumb fuzzing).
American Fuzzy Lop هي أداة اختبار عشوائي تعمل بالقوة الغاشمة، مقترنة بخوارزمية جينية موجّهة بأدوات القياس بسيطة للغاية ولكنها صلبة كالصخر. تستخدم شكلاً معدلاً من تغطية الحواف (edge coverage) لالتقاط التغييرات الدقيقة على المستوى المحلي في تدفق تحكم البرنامج بسهولة.
بتبسيط الأمور قليلاً، يمكن تلخيص الخوارزمية العامة على النحو التالي:
قم بتحميل حالات الاختبار الأولية التي يوفرها المستخدم إلى قائمة الانتظار،
خذ ملف الإدخال التالي من قائمة الانتظار،
حاول اقتطاع حالة الاختبار إلى أصغر حجم لا يغيّر السلوك المُقاس للبرنامج،
قم بتغيير الملف بشكل متكرر باستخدام مجموعة متوازنة ومدروسة جيدًا من استراتيجيات الاختبار العشوائي التقليدية،
إذا نتج عن أي من الطفرات المُولّدة انتقال حالة جديد تم تسجيله بواسطة أدوات القياس، أضف المخرجات المطفّرة كإدخال جديد في قائمة الانتظار.
انتقل إلى الخطوة 2.
كما يتم أيضًا استبعاد حالات الاختبار المكتشفة بشكل دوري للتخلص من الحالات التي أصبحت قديمة بسبب الاكتشافات الأحدث ذات التغطية الأعلى؛ وتخضع للعديد من خطوات تقليل الجهد الأخرى الموجّهة بأدوات القياس.
كنتيجة جانبية لعملية الاختبار العشوائي، تنشئ الأداة مجموعة صغيرة مكتفية ذاتيًا من حالات الاختبار المثيرة للاهتمام. هذه الحالات مفيدة للغاية لتغذية أنظمة اختبار أخرى مكلفة من حيث الجهد أو الموارد - على سبيل المثال، لاختبار الإجهاد (stress-testing) للمتصفحات، وتطبيقات المكاتب، وحزم الرسوميات، أو الأدوات مغلقة المصدر.
تم اختبار أداة الاختبار العشوائي بدقة لتقديم أداء فوري يتفوق بكثير على الاختبار العشوائي الأعمى أو أدوات التغطية فقط.
عند توافر الكود المصدري، يمكن حقن أدوات القياس بواسطة أداة مساعدة تعمل كبديل مباشر لـ gcc أو clang في أي عملية بناء قياسية لكود من طرف ثالث.
تأثير أدوات القياس على الأداء متواضع إلى حد ما؛ وبالتزامن مع التحسينات الأخرى التي تنفذها afl-fuzz، يمكن اختبار معظم البرامج عشوائيًا بسرعة مماثلة أو حتى أسرع مما هو ممكن باستخدام الأدوات التقليدية.
قد تختلف الطريقة الصحيحة لإعادة ترجمة البرنامج المستهدف وفقًا لتفاصيل عملية البناء، لكن النهج شبه الشامل سيكون:```shell $ CC=/path/to/afl/afl-gcc ./configure $ make clean all
بالنسبة لبرامج C++، قد ترغب أيضًا في تعيين `CXX=/path/to/afl/afl-g++`.
يمكن استخدام أغلفة clang (afl-clang وafl-clang++) بنفس الطريقة؛
قد يختار مستخدمو clang أيضًا الاستفادة من وضع قياس عالي الأداء،
كما هو موصوف في llvm_mode/README.llvm.
عند اختبار المكتبات، تحتاج إلى إيجاد أو كتابة برنامج بسيط يقرأ
البيانات من stdin أو من ملف ويمررها إلى المكتبة المختبرة. في مثل هذه
الحالة، من الضروري ربط هذا الملف التنفيذي بنسخة ثابتة من
المكتبة المُجهَّزة، أو التأكد من تحميل ملف .so الصحيح في
وقت التشغيل (عادةً عن طريق تعيين `LD_LIBRARY_PATH`). الخيار الأبسط هو بناء
ثابت، وعادةً ما يكون ممكنًا عبر:```shell
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
عند استدعاء make، يؤدي ضبط AFL_HARDEN=1 إلى جعل غلاف المترجم (CC wrapper) يفعّل تلقائيًا خيارات تحصين الكود التي تسهّل اكتشاف أخطاء الذاكرة البسيطة. كما يمكن أن تساعد مكتبة Libdislocator، وهي مكتبة مساعدة مرفقة مع AFL (انظر libdislocator/README.dislocator)، في كشف مشاكل تلف الكومة (heap corruption) أيضًا.
ملاحظة: يُنصح مستخدمو ASAN بمراجعة ملف notes_for_asan.txt للاطلاع على تحذيرات مهمة.
عندما لا يكون الكود المصدري متوفرًا، يوفّر المُختبر (fuzzer) دعمًا تجريبيًا لإضافة أجهزة القياس بسرعة وفورية على الثنائيات ذات الصندوق الأسود (black-box binaries). ويتم ذلك عبر نسخة من QEMU تعمل في وضع "محاكاة فضاء المستخدم" (user space emulation) الأقل شهرة.
QEMU مشروع مستقل عن AFL، لكن يمكنك بسهولة بناء هذه الميزة عبر تنفيذ ما يلي:```shell $ cd qemu_mode $ ./build_qemu_support.sh
للحصول على تعليمات وملاحظات إضافية، راجع qemu_mode/README.qemu.
يكون هذا الوضع أبطأ بنحو 2-5x من التنفيذ الآلي في وقت الترجمة (compile-time instrumentation)، وهو أقل ملاءمة للتوازي، وقد يكون له بعض الخصائص الأخرى.
## 5) اختيار حالات الاختبار الأولية
لكي يعمل المزيل (fuzzer) بشكل صحيح، يتطلب ملف بداية واحدًا أو أكثر يحتوي على مثال جيد لبيانات الإدخال التي يتوقعها التطبيق المستهدف عادةً. هناك قاعدتان أساسيتان:
- اجعل الملفات صغيرة. أقل من 1 كيلوبايت هو المثالي، وإن لم يكن ضروريًا تمامًا.
لمناقشة سبب أهمية الحجم، راجع [perf_tips.txt](https://github.com/google/afl/blob/HEAD/docs/perf_tips.txt).
- استخدم حالات اختبار متعددة فقط إذا كانت مختلفة وظيفيًا عن بعضها البعض.
لا فائدة من استخدام خمسين صورة إجازة مختلفة لاختبار مكتبة صور.
يمكنك العثور على العديد من الأمثلة الجيدة لملفات البداية في المجلد الفرعي testcases/ المرفق مع هذه الأداة.
ملاحظة: إذا كانت لديك مجموعة كبيرة من البيانات المتاحة للفحص، فقد ترغب في استخدام أداة afl-cmin لتحديد مجموعة فرعية من الملفات المختلفة وظيفيًا التي تمر بمسارات برمجية مختلفة في البرنامج الهدف.
## 6) اختبار الملفات الثنائية (Fuzzing binaries)
تتم عملية الاختبار نفسها بواسطة أداة afl-fuzz. يتطلب هذا البرنامج دليلًا للقراءة فقط يحتوي على حالات الاختبار الأولية، ومكانًا منفصلًا لتخزين النتائج، بالإضافة إلى مسار إلى الملف الثنائي المراد اختباره.
بالنسبة للملفات الثنائية الهدف التي تقبل الإدخال مباشرة من stdin، تكون الصيغة المعتادة كما يلي:```shell
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]
بالنسبة للبرامج التي تأخذ المدخلات من ملف، استخدم '@@' لتحديد الموضع في سطر أوامر الهدف حيث يجب وضع اسم ملف الإدخال. ستقوم أداة fuzzer باستبدال هذا نيابة عنك:```shell $ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
يمكنك أيضًا استخدام الخيار -f لكتابة البيانات المتحولة إلى ملف محدد. هذا مفيد إذا كان البرنامج يتوقع امتداد ملف معين أو ما شابه.
يمكن فحص الملفات الثنائية غير المُجهزة (non-instrumented) في وضع QEMU (أضف -Q في سطر الأوامر) أو في وضع المُشوش الأعمى التقليدي (حدد -n).
يمكنك استخدام الخيارين -t و -m لتجاوز المهلة الزمنية الافتراضية وحد الذاكرة للعملية المنفذة؛ من الأمثلة النادرة على الأهداف التي قد تحتاج إلى تعديل هذه الإعدادات: المترجمات (compilers) ومفككات الفيديو (video decoders).
نصائح تحسين أداء التشويش مذكورة في [perf_tips.txt](https://github.com/google/afl/blob/HEAD/docs/perf_tips.txt).
لاحظ أن afl-fuzz يبدأ بتنفيذ سلسلة من خطوات التشويش الحتمية (deterministic fuzzing)، والتي قد تستغرق عدة أيام، لكنها تميل إلى إنتاج حالات اختبار أنيقة. إذا كنت تريد نتائج سريعة وغير دقيقة في الحال - مثل zzuf وغيرها من أدوات التشويش التقليدية - أضف الخيار -d إلى سطر الأوامر.
## 7) تفسير المخرجات
راجع ملف [status_screen.txt](https://github.com/google/afl/blob/HEAD/docs/status_screen.txt) للحصول على معلومات حول كيفية تفسير الإحصائيات المعروضة ومراقبة صحة العملية. تأكد من الاطلاع على هذا الملف خاصة إذا كانت أي عناصر من واجهة المستخدم مظللة باللون الأحمر.
ستستمر عملية التشويش حتى تضغط على Ctrl-C. وعلى الأقل، يجب أن تسمح للأداة بإكمال دورة واحدة من قائمة الانتظار، وهو ما قد يستغرق من بضع ساعات إلى أسبوع أو نحو ذلك.
هناك ثلاثة أدلة فرعية تُنشأ داخل دليل المخرجات ويتم تحديثها في الوقت الفعلي:
- queue/ - حالات اختبار لكل مسار تنفيذ مميز، بالإضافة إلى جميع الملفات الابتدائية التي قدمها المستخدم. هذه هي المجموعة المُصنّعة (synthesized corpus) المذكورة في القسم 2.
قبل استخدام هذه المجموعة لأي أغراض أخرى، يمكنك تقليصها إلى حجم أصغر باستخدام أداة afl-cmin. ستجد الأداة مجموعة فرعية أصغر من الملفات توفر تغطية حواف مكافئة.
- crashes/ - حالات اختبار فريدة تتسبب في تلقي البرنامج المُختبر إشارة قاتلة (مثل SIGSEGV وSIGILL وSIGABRT). يتم تجميع الإدخالات حسب الإشارة المستقبَلة.
- hangs/ - حالات اختبار فريدة تتسبب في انتهاء مهلة البرنامج المُختبر. الحد الزمني الافتراضي قبل تصنيف شيء ما كتعليق (hang) هو أكبر القيمتين: 1 ثانية وقيمة المعامل -t.
يمكن ضبط القيمة بدقة عن طريق تعيين AFL_HANG_TMOUT، لكن هذا نادرًا ما يكون ضروريًا.
تُعتبر حالات الانهيار والتعليق "فريدة" إذا كانت مسارات التنفيذ المرتبطة بها تتضمن أي انتقالات حالة لم تُشاهد في الأعطال المُسجلة سابقًا. إذا كان يمكن الوصول إلى خطأ واحد بطرق متعددة، فسيكون هناك تضخم في العدد في بداية العملية، لكن ينبغي أن يتضاءل ذلك بسرعة.
ترتبط أسماء ملفات حالات الانهيار والتعليق بالعناصر الأصلية غير المُسبِبة للخطأ في قائمة الانتظار. وهذا يساعد في التصحيح (debugging).
عندما لا تتمكن من إعادة إنتاج حالة انهيار وجدتها afl-fuzz، فإن السبب الأرجح هو أنك لا تضع نفس حد الذاكرة الذي تستخدمه الأداة. جرّب:```shell
$ LIMIT_MB=50
$ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
غيّر LIMIT_MB ليطابق المعامل -m المُمرَّر إلى afl-fuzz. على OpenBSD، غيّر أيضًا -Sv إلى -Sd.
يمكن أيضًا استخدام أي دليل مخرجات موجود لاستئناف المهام المتوقفة؛ جرّب:```shell $ ./afl-fuzz -i- -o existing_output_dir [...etc...]
إذا كان لديك gnuplot مثبتًا، يمكنك أيضًا توليد رسوم بيانية جميلة لأي مهمة تشويش نشطة باستخدام afl-plot. للاطلاع على مثال لما يبدو عليه ذلك، انظر [http://lcamtuf.coredump.cx/afl/plot/](http://lcamtuf.coredump.cx/afl/plot/).
## 8) التشويش المتوازي
تستهلك كل نسخة من afl-fuzz نواة واحدة تقريبًا. وهذا يعني أنه على الأنظمة متعددة النوى، تكون الموازاة ضرورية للاستفادة الكاملة من العتاد. للحصول على نصائح حول كيفية تشويش هدف شائع على عدة نوى أو عدة أجهزة مترابطة عبر الشبكة، يُرجى الرجوع إلى [parallel_fuzzing.txt](https://github.com/google/afl/blob/HEAD/docs/parallel_fuzzing.txt).
يوفّر وضع التشويش المتوازي أيضًا طريقة بسيطة لربط AFL بأدوات تشويش أخرى، أو بمحركات التنفيذ الرمزي أو الكونكوليك (concolic)، وما إلى ذلك؛ مرة أخرى، انظر إلى القسم الأخير من [parallel_fuzzing.txt](https://github.com/google/afl/blob/HEAD/docs/parallel_fuzzing.txt) للحصول على نصائح.
## 9) قواميس المُشوِّش
افتراضيًا، يكون محرك التحوير في afl-fuzz محسّنًا لصيغ البيانات المضغوطة - مثل الصور، والوسائط المتعددة، والبيانات المضغوطة، وصيغة التعبيرات النمطية، أو سكربتات الصدفة. وهو أقل ملاءمة إلى حد ما للغات ذات الصيغ المطولة والزائدة عن الحاجة بشكل خاص - ولا سيما HTML أو SQL أو JavaScript.
لتجنب عناء بناء أدوات مدركة لتركيب الجمل (syntax-aware)، يوفّر afl-fuzz طريقة لتزويد عملية التشويش بقاموس اختياري من الكلمات المفتاحية للغة، أو الترويسات السحرية، أو أي رموز مميزة أخرى مرتبطة بنوع البيانات المستهدف - واستخدام ذلك لإعادة بناء القواعد النحوية الأساسية أثناء العمل:
[http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html](http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html)
لاستخدام هذه الميزة، عليك أولاً إنشاء قاموس بأحد الصيغتين المذكورتين في dictionaries/README.dictionaries؛ ثم توجيه المُشوِّش إليه عبر الخيار -x في سطر الأوامر.
(كما تتوفر بالفعل عدة قواميس شائعة في ذلك المجلد الفرعي أيضًا.)
لا توجد طريقة لتقديم أوصاف أكثر هيكلة لتركيب الجملة الأساسي، لكن المُشوِّش سيستنتج على الأرجح بعضًا من ذلك من التغذية الراجعة للأدوات (instrumentation) وحدها. وهذا يعمل فعليًا في الممارسة، على سبيل المثال:
[http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html](http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html)
ملاحظة: حتى في حالة عدم توفير قاموس صريح، سيحاول afl-fuzz استخراج الرموز النحوية الموجودة في مجموعة المدخلات (input corpus) من خلال مراقبة الأدوات (instrumentation) عن كثب أثناء عمليات قلب البايتات الحتمية. ينجح ذلك مع بعض أنواع المحللات والقواعد النحوية، ولكنه ليس بنفس جودة وضع -x تقريبًا.
إذا كان الحصول على قاموس صعبًا حقًا، فهناك خيار آخر يتمثل في ترك AFL يعمل لفترة من الوقت، ثم استخدام مكتبة التقاط الرموز (token capture) التي تأتي كأداة مصاحبة لـ AFL. للاطلاع على ذلك، انظر libtokencap/README.tokencap.
## 10) فرز حالات الانهيار
عادةً ما ينتج عن التجميع المبني على التغطية لحالات الانهيار مجموعة بيانات صغيرة يمكن فرزها بسرعة يدويًا أو عبر سكربت GDB أو Valgrind بسيط جدًا. كما يمكن تتبع كل حالة انهيار إلى حالة الاختبار الأم غير الانهيارية في قائمة الانتظار، مما يسهّل تشخيص الأعطال.
ومع ذلك، من المهم الإقرار بأن بعض حالات الانهيار الناتجة عن التشويش قد يكون من الصعب تقييم قابليتها للاستغلال بسرعة دون قدر كبير من التصحيح وتحليل الكود. للمساعدة في هذه المهمة، يدعم afl-fuzz وضع "استكشاف الانهيار" الفريد جدًا الذي يتم تفعيله عبر الخيار -C.
في هذا الوضع، يأخذ المُشوِّش حالة اختبار واحدة أو أكثر من حالات الانهيار كمدخلات، ويستخدم استراتيجيات التشويش المدفوعة بالتغذية الراجعة لتعداد جميع مسارات الكود التي يمكن الوصول إليها في البرنامج مع إبقائه في حالة الانهيار.
يتم رفض التحويرات التي لا تؤدي إلى انهيار؛ وكذلك أي تغييرات لا تؤثر في مسار التنفيذ.
الناتج هو مجموعة صغيرة من الملفات يمكن فحصها بسرعة كبيرة لمعرفة درجة التحكم التي يمتلكها المهاجم على عنوان الخطأ، أو ما إذا كان من الممكن تجاوز قراءة أولية خارج الحدود - ومعرفة ما يوجد أسفل ذلك.
أوه، شيء آخر: لتصغير حالات الاختبار، جرّب afl-tmin. يمكن تشغيل الأداة بطريقة بسيطة جدًا:```shell
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]
تعمل الأداة مع حالات الاختبار المتعطّلة وغير المتعطّلة على حدٍّ سواء. في وضع التعطّل (crash)، ستقبل بكل سهولة الملفات الثنائية المزوّدة بأدوات قياس (instrumented) وغير المزوّدة بها. أما في الوضع غير المتعطّل، فيعتمد المصغِّر (minimizer) على أدوات قياس AFL القياسية لجعل الملف أبسط دون تغيير مسار التنفيذ.
يقبل المصغِّر الصيغ -m و-t و-f و@@ بطريقة متوافقة مع afl-fuzz.
من الإضافات الحديثة الأخرى إلى AFL أداة afl-analyze. فهي تأخذ ملف إدخال، وتحاول قلب البايتات تسلسليًا، وتراقب سلوك البرنامج المختبر. ثم تقوم بترميز الإدخال بالألوان بناءً على المقاطع التي تبدو حرجة وتلك التي ليست كذلك؛ وعلى الرغم من أنها ليست مضمونة تمامًا، إلا أنها غالبًا ما توفّر رؤى سريعة حول تنسيقات الملفات المعقدة. يمكن العثور على مزيد من المعلومات حول طريقة عملها قرب نهاية technical_details.txt.
الـ fuzzing تقنية رائعة وغير مستغَلة بالقدر الكافي لاكتشاف أخطاء التصميم والتنفيذ غير المتعطِّلة أيضًا. تم العثور على عدد لا بأس به من الأخطاء المثيرة للاهتمام عن طريق تعديل البرامج المستهدفة لاستدعاء abort() عندما، على سبيل المثال:
تنتج مكتبتا أعداد كبيرة (bignum) مخرجات مختلفة عند إعطائهما نفس المدخلات المولَّدة بواسطة المُدقِّق (fuzzer)،
تنتج مكتبة صور مخرجات مختلفة عندما يُطلب منها فك ترميز نفس صورة الإدخال عدة مرات متتالية،
تفشل مكتبة تسلسل / إلغاء تسلسل (serialization / deserialization) في إنتاج مخرجات مستقرة عند إجراء تسلسل وإلغاء تسلسل البيانات المقدَّمة من المُدقِّق بشكل متكرر،
تنتج مكتبة ضغط مخرجًا غير متسق مع ملف الإدخال عندما يُطلب منها ضغط كتلة بيانات معينة ثم فك ضغطها.
عادةً ما يستغرق تنفيذ هذه الفحوصات أو فحوصات مماثلة للتحقق من السلامة وقتًا قصيرًا جدًا؛ إذا كنت المشرف على حزمة معينة، يمكنك جعل هذا الكود شرطيًا باستخدام #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION (وهي علامة مشتركة أيضًا مع libfuzzer) أو #ifdef __AFL_COMPILER (هذه العلامة خاصة بـ AFL فقط).
يُرجى الانتباه إلى أن الـ fuzzing، شأنها شأن العديد من المهام الأخرى المكثفة حسابيًا، قد تُشكّل ضغطًا على عتادك وعلى نظام التشغيل. على وجه الخصوص:
سترتفع حرارة وحدة المعالجة المركزية (CPU) وستحتاج إلى تبريد مناسب. في معظم الحالات، إذا كان التبريد غير كافٍ أو توقف عن العمل بشكل صحيح، فسيتم خفض سرعات المعالج تلقائيًا. ومع ذلك، خاصة عند الـ fuzzing على عتاد أقل ملاءمة (أجهزة محمولة، هواتف ذكية، إلخ)، فليس من المستحيل تمامًا أن يحدث احتراق أو عطل ما.
قد تنتهي البرامج المستهدفة إلى استهلاك غيغابايتات من الذاكرة بشكل غير منتظم أو ملء مساحة القرص بملفات غير مرغوب فيها. يحاول AFL فرض حدود أساسية للذاكرة، لكنه لا يمكنه منع كل خطأ محتمل. الخلاصة هي أنه لا ينبغي لك ممارسة الـ fuzzing على أنظمة لا يكون احتمال فقدان البيانات فيها خطرًا مقبولًا.
تتضمن الـ fuzzing مليارات من عمليات القراءة والكتابة على نظام الملفات. على الأنظمة الحديثة، عادةً ما يتم تخزين ذلك مؤقتًا بشكل كبير، مما يؤدي إلى إدخال/إخراج "فعلي" متواضع نسبيًا - ولكن هناك العديد من العوامل التي قد تغيّر هذه المعادلة. تقع على عاتقك مسؤولية مراقبة المشكلات المحتملة؛ فمع الإدخال/الإخراج الثقيل جدًا، قد ينخفض العمر الافتراضي للعديد من الأقراص الصلبة HDDs وأقراص SSD.
من الطرق الجيدة لمراقبة إدخال/إخراج القرص على Linux استخدام الأمر 'iostat':```shell $ iostat -d 3 -x -k [...optional disk ID...]
## 13) القيود المعروفة ومجالات التحسين
فيما يلي بعض أهم التحذيرات المتعلقة بـ AFL:
- يكتشف AFL الأعطال عن طريق التحقق من أن أول عملية مستنسخة تموت بسبب إشارة (SIGSEGV, SIGABRT, وغيرها). البرامج التي تثبّت معالجات مخصصة لهذه الإشارات قد تحتاج إلى تعليق الكود ذي الصلة. وبالمثل، قد تفلت الأعطال في العمليات الفرعية التي يستنسخها الهدف المُختبَر من الاكتشاف ما لم تضف يدويًا بعض الكود لالتقاط ذلك.
- كما هو الحال مع أي أداة قوة غاشمة أخرى، تقدم أداة التلغيز تغطية محدودة إذا تم استخدام التشفير أو المجاميع الاختبارية أو التوقيعات التشفيرية أو الضغط لتغليف تنسيق البيانات الفعلي المراد اختباره بالكامل.
للتحايل على ذلك، يمكنك تعليق الفحوصات ذات الصلة (انظر experimental/libpng_no_checksum/ للاستلهام)؛ إذا لم يكن ذلك ممكنًا، يمكنك أيضًا كتابة postprocessor، كما هو موضح في experimental/post_library/.
- هناك بعض المفاضلات المؤسفة مع ASAN والملفات الثنائية 64-bit. لا يعود هذا إلى أي خلل محدد في afl-fuzz؛ راجع [notes_for_asan.txt](https://github.com/google/afl/blob/HEAD/docs/notes_for_asan.txt) للحصول على نصائح.
- لا يوجد دعم مباشر لتلغيز خدمات الشبكة، أو الخدمات الخلفية (daemons)، أو التطبيقات التفاعلية التي تتطلب تفاعلًا مع واجهة المستخدم للعمل. قد تحتاج إلى إجراء تغييرات بسيطة في الكود لجعلها تتصرف بطريقة تقليدية أكثر. قد يوفر Preeny خيارًا بسيطًا نسبيًا أيضًا - انظر:
https://github.com/zardus/preeny
يمكن أيضًا العثور على بعض النصائح المفيدة لتعديل الخدمات الشبكية على الرابط:
https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
- لا يُخرج AFL بيانات تغطية قابلة للقراءة البشرية. إذا كنت تريد مراقبة التغطية، استخدم afl-cov من Michael Rash: https://github.com/mrash/afl-cov
- من حين لآخر، تثور الآلات الواعية على مبتكريها. إذا حدث هذا لك، فيرجى مراجعة http://lcamtuf.coredump.cx/prep/.
إلى جانب ذلك، راجع INSTALL للحصول على نصائح خاصة بالمنصة.
## 14) شكر خاص
لم تكن العديد من التحسينات على afl-fuzz ممكنة دون ملاحظات أو تقارير أخطاء أو تصحيحات من:```
Jann Horn Hanno Boeck
Felix Groebert Jakub Wilk
Richard W. M. Jones Alexander Cherepanov
Tom Ritter Hovik Manucharyan
Sebastian Roschke Eberhard Mattes
Padraig Brady Ben Laurie
@dronesec Luca Barbato
Tobias Ospelt Thomas Jarosch
Martin Carpenter Mudge Zatko
Joe Zbiciak Ryan Govostes
Michael Rash William Robinet
Jonathan Gray Filipe Cabecinhas
Nico Weber Jodie Cunningham
Andrew Griffiths Parker Thompson
Jonathan Neuschfer Tyler Nighswander
Ben Nagy Samir Aguiar
Aidan Thornton Aleksandar Nikolich
Sam Hakim Laszlo Szekeres
David A. Wheeler Turo Lamminen
Andreas Stieger Richard Godbee
Louis Dassy teor2345
Alex Moneger Dmitry Vyukov
Keegan McAllister Kostya Serebryany
Richo Healey Martijn Bogaard
rc0r Jonathan Foote
Christian Holler Dominique Pelle
Jacek Wielemborek Leo Barnes
Jeremy Barnes Jeff Trull
Guillaume Endignoux ilovezfs
Daniel Godas-Lopez Franjo Ivancic
Austin Seipp Daniel Komaromy
Daniel Binderman Jonathan Metzman
Vegard Nossum Jan Kneschke
Kurt Roeckx Marcel Bohme
Van-Thuan Pham Abhik Roychoudhury
Joshua J. Drake Toby Hutton
Rene Freingruber Sergey Davidoff
Sami Liedes Craig Young
Andrzej Jackowski Daniel Hodson
شكرًا لك!
أسئلة؟ مخاوف؟ تقارير أخطاء؟ يُرجى استخدام GitHub.
توجد أيضًا قائمة بريدية للمشروع؛ للانضمام، أرسل رسالة إلى [email protected]. أو إذا كنت تفضّل تصفّح الأرشيفات أولاً، جرّب: https://groups.google.com/group/afl-users.