جديد: لمن يرغبون في تجربة TriforceAFL و TLSF، أنشأ ريتشارد جونسون ملف Dockerfile يقوم بتثبيت كلاهما (بل ويبني لك نواة Linux أيضًا). وهو متاح هنا https://hub.docker.com/r/moflow/afl-triforce/tags/.

جديد أيضًا: afl-tmin يعمل الآن مع خادم التفرع!

https://github.com/nccgroup/TriforceAFL جيسي هيرتز [email protected] تيم نيوشام [email protected]

هذه نسخة مُرقّعة من AFL تدعم التضمين على مستوى النظام الكامل باستخدام QEMU. تم تحديث QEMU المرفق للسماح بتتبع الفروع عند تشغيل محاكي نظام لمعمارية x86_64. تمت إضافة تعليمات إضافية لبدء خادم التفرع الخاص بـ AFL، وضبط إعدادات التضمين، وتحديد بداية ونهاية حالات الاختبار.

ملاحظة: لم يتم اختبار جميع أدوات AFL مع التغييرات الجديدة. هذه الأدوات خضعت لبعض الاختبارات:

afl-fuzz - معدل لدعم -QQ
afl-showmap - معدل لدعم -QQ وخادم التفرع (مع المعالجة بالدفعات)
afl-cmin - معدل لدعم -QQ واستخدام خادم التفرع، لم يعد الإدخال عبر stdin مدعومًا
afl-analyze - معدل لدعم -QQ
afl-tmin - معدل لدعم -QQ، لكنه لا يدعم خادم التفرع!

للبناء:

make

للحصول على خريطة تغطية:

echo hello > /tmp/hello ./afl-showmap -o coverage.txt -QQ --
./afl-qemu-system-trace -kernel ../bzImage
-initrd ../initramfs.cpio.gz -m 1G -nographic
-append "console=ttyS0" -aflFile /tmp/hello cat coverage.txt

للتضمين:

figure out what addrs to use below...

egrep ' (panic|log_store)$' ../mykern/kallsyms ffffffff8108e570 t log_store ffffffff8181064b T panic

mkdir inputs echo hello > inputs/hello ./afl-fuzz -i inputs -o outputs -QQ --
afl-qemu-system-trace -kernel bzImage -initrd root.cpio.gz
-m 1G -nographic -append "console=ttyS0"
-aflPanicAddr ffffffff8181064b -aflDmesgAddr ffffffff8108e570
-aflFile @@

(ملاحظة: بخلاف استخدام الخيار "-Q"، يجب عليك تحديد سطر الأوامر الكامل لـ afl-qemu-system-trace عند استخدام الخيار "-QQ").

لمزيد من التفاصيل حول كيفية استخدام هذه النسخة المعدلة من AFL، انظر مضمِّن استدعاءات نظام Linux الخاص بنا على https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.

خيارات AFL الجديدة: -QQ - استخدام qemu في محاكاة النظام الكامل بدلاً من وضع المستخدم (-Q)

خيارات QEMU الجديدة: -aflFile - اسم الملف الذي يحتوي على مدخلات المضمِّن -aflPanicAddr - عنوان لموقع انهيار النواة لاكتشاف الانهيار -aflDmesgAddr - عنوان نواة Linux لدالة تسجيل dmesg لاكتشاف التسجيل واعتراض رسائل السجل

تعليمات QEMU الجديدة: 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) بدء خادم التفرع الخاص بـ AFL. بعد هذه النقطة، سيتم تشغيل كل اختبار في عملية فرعية منفصلة. إذا كانت enableTicks غير صفرية، سيعيد QEMU تمكين مؤقت وحدة المعالجة المركزية بعد تفرع عملية فرعية، وإلا فلن يتم تمكينه. edi=2 getWork(esi=ptr, edx=sz) ملء ptr[0..sz] بحالة الاختبار التالية. يُرجع الحجم الفعلي الممتلئ (<= sz). edi=3 startWork(esi=ptr) إخبار AFL ببدء التتبع. تشير الوسيطة إلى مخزن مؤقت يحتوي على قيمتين 64-بت تحددان عنوان البداية والنهاية للكود المراد تتبعه. التعليمات خارج هذا النطاق لا يتم تتبعها. edi=4 doneWork(esi=exitCode) إخبار AFL بأن حالة الاختبار اكتملت. إذا تم اكتشاف انهيار، سيوقف AFL حالة الاختبار فورًا. وإلا فسيستمر حتى يتم استدعاء doneWork. يُرجع كود الخروج المحدد إلى AFL. (يمكن للكود، لكنه لا يقوم بذلك حاليًا، أن يدمج القيمة 64 عبر عملية OR في جميع أكواد الخروج إذا تم اكتشاف أي سجلات dmesg أثناء حالة الاختبار.)

محرك كتلة QEMU الجديد: -drive filename=privmem: يحتفظ محرك الكتلة هذا بصورة محرك التخزين في ذاكرة نسخ-عند-الكتابة بحيث لا يتم حفظ التغييرات على القرص أبدًا. التغييرات التي يجريها أحد حالات الاختبار معزولة عن حالات الاختبار الأخرى.

================== american fuzzy lop

كتبه ويصونه ميشال زاليفسكي [email protected]

للإصدارات الجديدة والمعلومات الإضافية، تفضل بزيارة: http://lcamtuf.coredump.cx/afl/

لمقارنة الملاحظات مع المستخدمين الآخرين أو الحصول على إشعارات حول الميزات الرئيسية الجديدة، أرسل بريدًا إلى [email protected].

** انظر QuickStartGuide.txt إذا لم يكن لديك وقت لقراءة هذا الملف. **

تحديات التضمين الموجه

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

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

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

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

نهج afl-fuzz

American Fuzzy Lop هو مضمِّن يعمل بالقوة الغاشمة، مقترنًا بخوارزمية جينية بسيطة للغاية لكنها صلبة كالصخر، وموجهة بالقياس الآلي. يستخدم شكلاً معدلاً من تغطية الحواف لالتقاط التغييرات الدقيقة والمحلية النطاق في تدفق تحكم البرنامج دون عناء.

لتبسيط الأمور قليلاً، يمكن تلخيص الخوارزمية برمتها على النحو التالي:

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

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

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

تم اختبار المضمِّن بدقة لتقديم أداء خارج الصندوق متفوق بكثير على التضمين الأعمى أو الأدوات القائمة على التغطية فقط.

تجهيز البرامج بالقياس الآلي للاستخدام مع AFL

عندما يكون الكود المصدري متاحًا، يمكن حقن القياس الآلي بواسطة أداة مصاحبة تعمل كبديل مباشر لـ gcc أو clang في أي عملية بناء قياسية لكود طرف ثالث.

للقياس الآلي تأثير أداء متواضع إلى حد ما؛ وبالاقتران مع التحسينات الأخرى المنفذة بواسطة afl-fuzz، يمكن تضمين معظم البرامج بسرعة مماثلة أو حتى أسرع مما هو ممكن مع الأدوات التقليدية.

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

$ 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). الخيار الأبسط هو البناء الثابت، وهو ممكن عادةً عبر:

$ CC=/path/to/afl/afl-gcc ./configure --disable-shared

سيؤدي تعيين AFL_HARDEN=1 عند استدعاء 'make' إلى جعل غلاف CC يقوم تلقائيًا بتمكين خيارات تقوية الكود التي تسهل اكتشاف أخطاء الذاكرة البسيطة.

ملاحظة: يُنصح مستخدمو ASAN بمراجعة ملف notes_for_asan.txt للاطلاع على تحذيرات مهمة.

تجهيز التطبيقات الثنائية فقط بالقياس الآلي

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

QEMU مشروع منفصل عن AFL، لكن يمكنك بسهولة بناء الميزة عن طريق:

$ cd qemu_mode $ ./build_qemu_support.sh

للحصول على تعليمات وتحذيرات إضافية، انظر qemu_mode/README.qemu.

هذا الوضع أبطأ بحوالي 2-5x من القياس الآلي في وقت الترجمة، وهو أقل ملاءمة للتوازي، وقد يكون له بعض الخصائص الغريبة الأخرى.

اختيار حالات الاختبار الأولية

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

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

يمكنك العثور على العديد من الأمثلة الجيدة لملفات البداية في الدليل الفرعي testcases/ المرفق مع هذه الأداة.

ملاحظة: إذا كانت مجموعة كبيرة من البيانات متاحة للفرز، فقد ترغب في استخدام أداة afl-cmin لتحديد مجموعة فرعية من الملفات المتميزة وظيفيًا والتي تمر عبر مسارات كود مختلفة في الثنائي الهدف.

تضمين الثنائيات

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

بالنسبة للثنائيات الهدف التي تقبل الإدخال مباشرة من stdin، تكون الصيغة المعتادة:

$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]

بالنسبة للبرامج التي تأخذ الإدخال من ملف، استخدم '@@' لتحديد الموقع في سطر أوامر الهدف حيث يجب وضع اسم ملف الإدخال. سيقوم المضمِّن بالاستبدال نيابة عنك:

$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@

يمكنك أيضًا استخدام الخيار -f لكتابة البيانات المطورة في ملف محدد. هذا مفيد إذا كان البرنامج يتوقع امتداد ملف معين أو ما شابه ذلك.

يمكن تضمين الثنائيات غير المزودة بالقياس الآلي في وضع QEMU (أضف -Q في سطر الأوامر) أو في وضع التضمين الأعمى التقليدي (حدد -n).

يمكنك استخدام -t و -m لتجاوز المهلة وحد الذاكرة الافتراضيين للعملية المنفذة؛ الأمثلة النادرة للأهداف التي قد تحتاج إلى تعديل هذه الإعدادات تشمل المترجمات ومفككات الفيديو.

تتم مناقشة نصائح تحسين أداء التضمين في perf_tips.txt.

لاحظ أن afl-fuzz يبدأ بتنفيذ مجموعة من خطوات التضمين الحتمية، والتي قد تستغرق عدة أيام. إذا كنت تريد نتائج سريعة وغير منقحة فورًا، على غرار zzuf أو honggfuzz، أضف الخيار -d إلى سطر الأوامر.

تفسير المخرجات

انظر ملف status_screen.txt للحصول على معلومات حول كيفية تفسير الإحصائيات المعروضة ومراقبة صحة العملية. تأكد من استشارة هذا الملف خاصة إذا تم تمييز أي عناصر من واجهة المستخدم باللون الأحمر.

ستستمر عملية التضمين حتى تضغط على Ctrl-C. على الأقل، يجب أن تسمح للمضمِّن بإكمال دورة قائمة انتظار واحدة، والتي قد تستغرق ما بين بضع ساعات وأسبوع أو نحو ذلك.

هناك ثلاثة أدلة فرعية يتم إنشاؤها داخل دليل المخرجات وتحديثها في الوقت الفعلي:

queue/ - حالات الاختبار لكل مسار تنفيذ مميز، بالإضافة إلى جميع ملفات البداية المقدمة من المستخدم. هذه هي المجموعة المُصنَّعة المذكورة في القسم 2.

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

crashes/ - حالات اختبار فريدة تتسبب في تلقي البرنامج المختبر إشارة قاتلة (مثل SIGSEGV، SIGILL، SIGABRT). يتم تجميع الإدخالات حسب الإشارة المستلمة.
hangs/ - حالات اختبار فريدة تتسبب في انتهاء مهلة البرنامج المختبر. لاحظ أنه عند تفعيل إعدادات المهلة الافتراضية (العدوانية)، يمكن أن يكون هذا مزعجًا قليلاً بسبب ارتفاعات زمن الاستجابة والظواهر الطبيعية الأخرى.

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

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

عندما لا تستطيع إعادة إنتاج انهيار وجده afl-fuzz، فإن السبب الأكثر احتمالاً هو أنك لا تضع نفس حد الذاكرة الذي تستخدمه الأداة. جرب:

$ LIMIT_MB=50 $ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )

غيّر LIMIT_MB ليطابق المعامل -m الممرر إلى afl-fuzz. على OpenBSD، غيّر أيضًا -Sv إلى -Sd.

يمكن أيضًا استخدام أي دليل مخرجات موجود لاستئناف المهام المتقطعة؛ جرب:

$ ./afl-fuzz -i- -o existing_output_dir [...etc...]

إذا كان gnuplot مثبتًا لديك، يمكنك أيضًا إنشاء بعض الرسوم البيانية الجميلة لأي مهمة تضمين نشطة باستخدام afl-plot. لمعرفة شكلها، انظر http://lcamtuf.coredump.cx/afl/plot/.

التضمين المتوازي

كل مثيل من afl-fuzz يستهلك نواة واحدة تقريبًا. هذا يعني أنه على الأنظمة متعددة النوى، يكون التوازي ضروريًا لاستغلال العتاد بالكامل. للحصول على نصائح حول كيفية تضمين هدف مشترك على نوى متعددة أو أجهزة متعددة متصلة بالشبكة، يرجى الرجوع إلى parallel_fuzzing.txt.

قواميس المضمِّن

بشكل افتراضي، يكون محرك الطفرات في afl-fuzz محسنًا لتنسيقات البيانات المدمجة - مثل الصور، والوسائط المتعددة، والبيانات المضغوطة، وصيغ التعبيرات النمطية، أو سكربتات الصدفة. وهو أقل ملاءمة إلى حد ما للغات ذات الصياغة المطولة والمكررة بشكل خاص - ولا سيما HTML و SQL و JavaScript.

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

http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html

لاستخدام هذه الميزة، تحتاج أولاً إلى إنشاء قاموس بأحد التنسيقين اللذين تمت مناقشتهما في testcases/README.testcases؛ ثم توجيه المضمِّن إليه عبر الخيار -x في سطر الأوامر.

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

http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html

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

فرز حالات الانهيار

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

بعد قول ذلك، من المهم الاعتراف بأن بعض حالات الانهيار الناتجة عن التضمين قد يكون من الصعب تقييم قابليتها للاستغلال بسرعة دون قدر كبير من أعمال التصحيح وتحليل الكود. للمساعدة في هذه المهمة، يدعم afl-fuzz وضعًا فريدًا جدًا "لاستكشاف الانهيار" يتم تفعيله بالخيار -C.

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

الطفرات التي لا تؤدي إلى انهيار يتم رفضها؛ وكذلك أي تغييرات لا تؤثر على مسار التنفيذ.

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

أوه، شيء آخر: لتقليل حجم حالات الاختبار، جرب afl-tmin. يمكن تشغيل الأداة بطريقة بسيطة جدًا:

$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]

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

يقبل المقلل صيغ -m و -t و -f و @@ بطريقة متوافقة مع afl-fuzz.

إضافة حديثة أخرى إلى AFL هي أداة afl-analyze. تأخذ ملف إدخال، وتحاول قلب البايتات بالتتابع، وتراقب سلوك البرنامج المختبر. ثم تقوم بترميز لوني للإدخال بناءً على الأقسام التي تبدو حرجة والتي ليست كذلك؛ ورغم أنها ليست مضمونة تمامًا، إلا أنها غالبًا ما تقدم رؤى سريعة حول تنسيقات الملفات المعقدة. يمكن العثور على مزيد من المعلومات حول تشغيلها قرب نهاية ملف technical_details.txt.

مخاطر المنطق السليم

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

ستسخن وحدة المعالجة المركزية لديك وستحتاج إلى تبريد مناسب. في معظم الحالات، إذا كان التبريد غير كافٍ أو توقف عن العمل بشكل صحيح، فسيتم خفض سرعات وحدة المعالجة المركزية تلقائيًا. ومع ذلك، خاصة عند التضمين على عتاد أقل ملاءمة (أجهزة كمبيوتر محمولة، هواتف ذكية، إلخ)، فليس من المستحيل تمامًا أن ينفجر شيء ما.
قد تنتهي البرامج المستهدفة إلى استهلاك غيغابايتات من الذاكرة بشكل غير منتظم أو ملء مساحة القرص بملفات غير مرغوب فيها. يحاول AFL فرض حدود ذاكرة أساسية، لكنه لا يستطيع منع كل حادث محتمل. الخلاصة هي أنه لا ينبغي لك التضمين على أنظمة يكون فيها احتمال فقدان البيانات خطرًا غير مقبول.- يتضمّن الـ Fuzzing مليارات من عمليات القراءة والكتابة على نظام الملفات. وعلى الأنظمة الحديثة، سيكون هذا عادةً مخزَّنًا مؤقتًا بشكل كبير، مما يؤدي إلى إدخال/إخراج "فعلي" متواضع إلى حد ما - ولكن هناك العديد من العوامل التي قد تغيّر هذه المعادلة. تقع على عاتقك مسؤولية مراقبة المشاكل المحتملة؛ فمع الإدخال/الإخراج الثقيل جدًا، قد ينخفض العمر الافتراضي للعديد من أقراص HDD وأقراص SSD.

من الطرق الجيدة لمراقبة إدخال/إخراج القرص على Linux استخدام الأمر 'iostat':

$ iostat -d 3 -x -k [...optional disk ID...]

القيود المعروفة ومجالات التحسين

فيما يلي بعض من أهم الملاحظات التحذيرية الخاصة بـ AFL:

يكتشف AFL الأعطال من خلال التحقق من موت أول عملية مستنسخة بسبب إشارة (SIGSEGV، SIGABRT، إلخ). البرامج التي تثبّت معالجات مخصصة لهذه الإشارات قد تحتاج إلى تعليق الكود ذي الصلة. وبالمثل، فإن الأعطال في العمليات الفرعية التي يولدها الهدف المُشوَّش قد تتفادى الاكتشاف ما لم تقم يدويًا بإضافة بعض التعليمات البرمجية لالتقاط ذلك.
كما هو الحال مع أي أداة أخرى من أدوات القوة الغاشمة، يوفّر المُشوِّش (fuzzer) تغطية محدودة إذا تم استخدام التشفير أو المجاميع الاختبارية (checksums) أو التوقيعات التشفيرية أو الضغط لتغليف تنسيق البيانات الفعلي المراد اختباره بالكامل.

للتغلب على ذلك، يمكنك تعليق الفحوصات ذات الصلة (انظر experimental/libpng_no_checksum/ للإلهام)؛ إذا لم يكن ذلك ممكنًا، يمكنك أيضًا كتابة معالج لاحق (postprocessor)، كما هو موضح في experimental/post_library/.
هناك بعض المفاضلات غير المواتية مع ASAN والملفات الثنائية 64-بت. هذا ليس بسبب أي خطأ محدد في afl-fuzz؛ راجع 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

بعد هذا، راجع INSTALL للحصول على نصائح خاصة بكل منصة.

شكر خاص

العديد من التحسينات على 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

شكرًا لكم!

الاتصال

أسئلة؟ استفسارات؟ تقارير أخطاء؟ يمكن عادةً الوصول إلى المؤلف عبر [email protected].

توجد أيضًا قائمة بريدية للمشروع؛ للانضمام، أرسل بريدًا إلى [email protected]. أو، إذا كنت تفضّل تصفح الأرشيفات أولاً، جرّب:

https://groups.google.com/group/afl-users

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

https://cla.developers.google.com/clas

نعتذر عن الإزعاج. بالطبع، لا يُطلب أي اتفاقية ترخيص مساهم (CLA) لطلبات الميزات أو تقارير الأخطاء.

TriforceAFL

الأكثر شعبية

figure out what addrs to use below...

================== american fuzzy lop