nccgroup/triforceaflAFL/QEMU फज़िंग, पूर्ण-सिस्टम इम्यूलेशन के साथ।
नया: जो लोग TriforceAFL और TLSF के साथ प्रयोग करना चाहते हैं, उनके लिए Richard Johnson ने एक Dockerfile बनाई है जो दोनों को इंस्टॉल करती है (और आपके लिए Linux कर्नेल भी बनाती है)। यह यहाँ उपलब्ध है https://hub.docker.com/r/moflow/afl-triforce/tags/।
एक और नई बात: afl-tmin अब forkserver के साथ काम करता है!
https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]
यह AFL का एक पैच किया हुआ संस्करण है जो QEMU का उपयोग करके पूर्ण-सिस्टम फ़ज़िंग का समर्थन करता है। शामिल QEMU को अपडेट किया गया है ताकि x86_64 के लिए सिस्टम इम्यूलेटर चलाते समय branch ट्रेसिंग की जा सके। AFL के forkserver को शुरू करने, फ़ज़ सेटिंग्स बनाने, और टेस्ट केस के आरंभ और समाप्ति को चिह्नित करने के लिए अतिरिक्त निर्देश जोड़े गए हैं।
नोट: सभी AFL टूल्स का नए बदलावों के साथ परीक्षण नहीं किया गया है। इन टूल्स का कुछ परीक्षण किया गया है:
निर्माण के लिए:
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
फ़ज़ करने के लिए:
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" विकल्प का उपयोग करते समय के विपरीत, "-QQ" विकल्प का उपयोग करते समय आपको afl-qemu-system-trace की पूरी कमांड लाइन निर्दिष्ट करनी होगी)।
AFL के इस संशोधित संस्करण का उपयोग कैसे करें, इसके अधिक विवरण के लिए, हमारा Linux syscall फ़ज़र देखें: https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.
नए AFL फ़्लैग: -QQ - user-mode (-Q) के बजाय पूर्ण-सिस्टम इम्यूलेशन में qemu का उपयोग करें
नए QEMU फ़्लैग: -aflFile - फ़ज़र इनपुट वाली फ़ाइल का नाम -aflPanicAddr - panic पहचान के लिए कर्नेल panic एड्रेस का पता -aflDmesgAddr - लॉगिंग का पता लगाने और लॉग संदेशों को इंटरसेप्ट करने के लिए dmesg लॉगिंग फ़ंक्शन का Linux कर्नेल एड्रेस
नए QEMU निर्देश: 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) AFL का fork server शुरू करें। इस बिंदु के बाद प्रत्येक टेस्ट एक अलग forked child में चलेगा। यदि enableTicks गैर-शून्य है, तो QEMU child को fork करने के बाद CPU का टाइमर फिर से सक्षम करेगा, अन्यथा इसे सक्षम नहीं किया जाएगा। edi=2 getWork(esi=ptr, edx=sz) ptr[0..sz] को अगले इनपुट टेस्ट केस से भरें। भरा गया वास्तविक आकार लौटाता है (<= sz)। edi=3 startWork(esi=ptr) AFL को ट्रेसिंग शुरू करने के लिए कहें। तर्क एक बफर की ओर इशारा करता है जिसमें दो quadwords हैं जो ट्रेस किए जाने वाले कोड के आरंभ और समाप्ति एड्रेस देते हैं। इस सीमा के बाहर के निर्देश ट्रेस नहीं किए जाते हैं। edi=4 doneWork(esi=exitCode) AFL को बताएं कि टेस्ट केस पूरा हो गया है। यदि panic का पता चलता है, तो AFL टेस्ट केस को तुरंत रोक देगा। अन्यथा यह doneWork कॉल होने तक चलता रहेगा। निर्दिष्ट exitCode AFL को लौटा दिया जाता है। (कोड सभी exit codes में 64 मान OR कर सकता है, हालाँकि वर्तमान में ऐसा नहीं करता, यदि टेस्ट केस के दौरान कोई dmesg लॉग पाया गया हो।)
नया QEMU ब्लॉक ड्राइवर: -drive filename=privmem: यह ब्लॉक ड्राइवर ड्राइव की इमेज को copy-on-write मेमोरी में रखता है ताकि परिवर्तन कभी डिस्क पर सहेजे न जाएँ। एक टेस्ट केस द्वारा किए गए परिवर्तन अन्य टेस्ट केसों से अलग रखे जाते हैं।
Michal Zalewski [email protected] द्वारा लिखित और अनुरक्षित
कॉपीराइट 2013, 2014, 2015, 2016 Google Inc. सर्वाधिकार सुरक्षित। Apache License, Version 2.0 की शर्तों और नियमों के अंतर्गत जारी।
नए संस्करणों और अतिरिक्त जानकारी के लिए देखें: http://lcamtuf.coredump.cx/afl/
अन्य उपयोगकर्ताओं से विचारों का आदान-प्रदान करने या प्रमुख नई सुविधाओं के बारे में सूचित होने के लिए, [email protected] पर मेल भेजें।
** यदि आपके पास इस फ़ाइल को पढ़ने का समय नहीं है तो QuickStartGuide.txt देखें। **
फ़ज़िंग वास्तविक दुनिया के सॉफ़्टवेयर में सुरक्षा समस्याओं की पहचान करने के लिए सबसे शक्तिशाली और सिद्ध रणनीतियों में से एक है; यह आज तक सुरक्षा-महत्वपूर्ण सॉफ़्टवेयर में पाए गए रिमोट कोड एक्ज़ीक्यूशन और प्रिविलेज एस्केलेशन बगों के विशाल बहुमत के लिए ज़िम्मेदार है।
दुर्भाग्य से, फ़ज़िंग अपेक्षाकृत उथली भी है; अंधा, यादृच्छिक उत्परिवर्तन परीक्षण किए जा रहे कोड में कुछ कोड पथों तक पहुँचने की संभावना को बहुत कम कर देते हैं, जिससे कुछ कमज़ोरियाँ इस तकनीक की पहुँच से पूरी तरह बाहर रह जाती हैं।
इस समस्या को हल करने के कई प्रयास हुए हैं। शुरुआती दृष्टिकोणों में से एक
अन्य, अधिक परिष्कृत शोध ने प्रोग्राम फ़्लो विश्लेषण ("concolic execution"), प्रतीकात्मक निष्पादन (symbolic execution), या स्थैतिक विश्लेषण जैसी तकनीकों पर ध्यान केंद्रित किया है। ये सभी विधियाँ प्रयोगात्मक सेटिंग्स में अत्यंत आशाजनक हैं, लेकिन व्यावहारिक उपयोगों में विश्वसनीयता और प्रदर्शन समस्याओं से ग्रस्त होती हैं - और वर्तमान में "डंब" फ़ज़िंग तकनीकों का कोई व्यवहार्य विकल्प प्रदान नहीं करती हैं।
American Fuzzy Lop एक brute-force फ़ज़र है जो एक अत्यंत सरल लेकिन अत्यंत मज़बूत instrumentation-निर्देशित आनुवंशिक एल्गोरिदम से जुड़ा है। यह प्रोग्राम नियंत्रण प्रवाह में सूक्ष्म, स्थानीय-स्तरीय परिवर्तनों को सहजता से पकड़ने के लिए एज कवरेज के एक संशोधित रूप का उपयोग करता है।
थोड़ा सरल करते हुए, समग्र एल्गोरिदम को इस प्रकार संक्षेपित किया जा सकता है:
उपयोगकर्ता-आपूर्ति किए गए प्रारंभिक टेस्ट केसों को क्यू में लोड करें,
क्यू से अगली इनपुट फ़ाइल लें,
टेस्ट केस को सबसे छोटे आकार में trim करने का प्रयास करें जो प्रोग्राम के मापे गए व्यवहार को नहीं बदलता,
पारंपरिक फ़ज़िंग रणनीतियों की एक संतुलित और सुशोधित विविधता का उपयोग करके फ़ाइल को बार-बार उत्परिवर्तित करें,
यदि उत्पन्न उत्परिवर्तनों में से कोई भी instrumentation द्वारा दर्ज की गई नई स्थिति संक्रमण का परिणाम देता है, तो उत्परिवर्तित आउटपुट को क्यू में एक नई प्रविष्टि के रूप में जोड़ें।
चरण 2 पर जाएँ।
खोजे गए टेस्ट केसों को समय-समय पर समाप्त भी किया जाता है ताकि उन्हें हटाया जा सके जो नए, उच्च-कवरेज खोजों द्वारा अप्रचलित हो गए हैं; और कई अन्य instrumentation-संचालित प्रयास न्यूनीकरण चरणों से गुजरते हैं।
फ़ज़िंग प्रक्रिया के एक पार्श्व परिणाम के रूप में, टूल दिलचस्प टेस्ट केसों का एक छोटा, स्व-निहित corpus बनाता है। ये अन्य श्रम- या संसाधन-गहन परीक्षण व्यवस्थाओं को सीड करने के लिए अत्यंत उपयोगी हैं - उदाहरण के लिए, ब्राउज़रों, ऑफ़िस अनुप्रयोगों, ग्राफ़िक्स सुइट्स, या बंद-स्रोत टूल्स का स्ट्रेस-टेस्टिंग करने के लिए।
फ़ज़र का पूरी तरह से परीक्षण किया गया है ताकि वह ब्लाइंड फ़ज़िंग या केवल-कवरेज टूल्स की तुलना में कहीं बेहतर आउट-ऑफ़-द-बॉक्स प्रदर्शन दे।
जब स्रोत कोड उपलब्ध हो, तो इंस्ट्रूमेंटेशन को एक साथी टूल द्वारा इंजेक्ट किया जा सकता है जो तृतीय-पक्ष कोड के लिए किसी भी मानक निर्माण प्रक्रिया में 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
'make' कॉल करते समय AFL_HARDEN=1 सेट करने से CC रैपर स्वचालित रूप से कोड हार्डनिंग विकल्प सक्षम कर देगा जिससे सरल मेमोरी बग का पता लगाना आसान हो जाता है।
पी.एस. ASAN उपयोगकर्ताओं को महत्वपूर्ण चेतावनियों के लिए notes_for_asan.txt फ़ाइल की समीक्षा करने की सलाह दी जाती है।
जब स्रोत कोड उपलब्ध नहीं है, तो फ़ज़र ब्लैक-बॉक्स बाइनरी के तेज़, ऑन-द-फ़्लाई इंस्ट्रूमेंटेशन के लिए प्रायोगिक समर्थन प्रदान करता है। यह QEMU के एक संस्करण के साथ पूरा किया जाता है जो कम-ज्ञात "user space emulation" मोड में चलता है।
QEMU AFL से अलग एक प्रोजेक्ट है, लेकिन आप सुविधाजनक रूप से यह सुविधा इस प्रकार बना सकते हैं:
$ cd qemu_mode $ ./build_qemu_support.sh
अतिरिक्त निर्देशों और चेतावनियों के लिए, qemu_mode/README.qemu देखें।
यह मोड संकलन-समय इंस्ट्रूमेंटेशन से लगभग 2-5 गुना धीमा है, समानांतरीकरण के लिए कम अनुकूल है, और इसकी कुछ अन्य विचित्रताएँ भी हो सकती हैं।
सही ढंग से काम करने के लिए, फ़ज़र को एक या अधिक प्रारंभिक फ़ाइलों की आवश्यकता होती है जिसमें लक्षित अनुप्रयोग द्वारा सामान्य रूप से अपेक्षित इनपुट डेटा का एक अच्छा उदाहरण हो। दो बुनियादी नियम हैं:
फ़ाइलों को छोटा रखें। 1 kB से कम आदर्श है, हालाँकि कड़ाई से आवश्यक नहीं। आकार क्यों मायने रखता है, इसकी चर्चा के लिए perf_tips.txt देखें।
कई टेस्ट केस केवल तभी उपयोग करें जब वे कार्यात्मक रूप से एक-दूसरे से भिन्न हों। एक इमेज लाइब्रेरी को फ़ज़ करने के लिए पचास अलग-अलग छुट्टी वाली तस्वीरों का उपयोग करने का कोई मतलब नहीं है।
आप इस टूल के साथ आने वाली testcases/ उपनिर्देशिका में प्रारंभिक फ़ाइलों के कई अच्छे उदाहरण पा सकते हैं।
पी.एस. यदि स्क्रीनिंग के लिए डेटा का एक बड़ा corpus उपलब्ध है, तो आप 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 फ़ाइल देखें। विशेष रूप से इस फ़ाइल को अवश्य देखें यदि कोई UI तत्व लाल रंग में हाइलाइट किया गया है।
फ़ज़िंग प्रक्रिया तब तक जारी रहेगी जब तक आप Ctrl-C नहीं दबाते। न्यूनतम रूप से, आप फ़ज़र को एक क्यू चक्र पूरा करने देना चाहेंगे, जिसमें कुछ घंटों से लेकर लगभग एक सप्ताह तक का समय लग सकता है।
आउटपुट निर्देशिका के भीतर तीन उपनिर्देशिकाएँ बनाई जाती हैं और वास्तविक समय में अद्यतन की जाती हैं:
queue/ - प्रत्येक विशिष्ट निष्पादन पथ के लिए टेस्ट केस, साथ ही उपयोगकर्ता द्वारा दी गई सभी प्रारंभिक फ़ाइलें। यह खंड 2 में उल्लिखित संश्लेषित corpus है।
इस corpus का किसी अन्य उद्देश्य के लिए उपयोग करने से पहले,
आप afl-cmin टूल का उपयोग करके इसे छोटे आकार में सिकोड़
सकते हैं। यह टूल समतुल्य एज कवरेज प्रदान करने वाली फ़ाइलों
का एक छोटा उपसमुच्चय खोजेगा।
crashes/ - अद्वितीय टेस्ट केस जो परीक्षण किए गए प्रोग्राम को एक घातक सिग्नल (जैसे SIGSEGV, SIGILL, SIGABRT) प्राप्त करने का कारण बनते हैं। प्रविष्टियाँ प्राप्त सिग्नल के आधार पर समूहीकृत होती हैं।
hangs/ - अद्वितीय टेस्ट केस जो परीक्षण किए गए प्रोग्राम को टाइमआउट का कारण बनते हैं। ध्यान दें कि जब डिफ़ॉल्ट (आक्रामक) टाइमआउट सेटिंग्स प्रभाव में होती हैं, तो यह विलंबता स्पाइक्स और अन्य प्राकृतिक घटनाओं के कारण थोड़ा शोर भरा हो सकता है।
क्रैश और हैंग को "अद्वितीय" माना जाता है यदि संबंधित निष्पादन पथों में पहले से दर्ज दोषों में नहीं देखे गए कोई स्थिति संक्रमण शामिल हों। यदि एक ही बग तक कई तरीकों से पहुँचा जा सकता है, तो प्रक्रिया की शुरुआत में कुछ गिनती मुद्रास्फीति होगी, लेकिन यह जल्दी से कम हो जानी चाहिए।
क्रैश और हैंग के फ़ाइल नाम मूल, गैर-दोषपूर्ण क्यू प्रविष्टियों से संबंधित हैं। इससे डिबगिंग में मदद मिलनी चाहिए।
जब आप afl-fuzz द्वारा पाए गए क्रैश को पुन: उत्पन्न नहीं कर सकते, तो सबसे संभावित कारण यह है कि आप टूल द्वारा उपयोग की गई समान मेमोरी सीमा सेट नहीं कर रहे हैं। प्रयास करें:
$ LIMIT_MB=50 $ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
LIMIT_MB को afl-fuzz को दिए गए -m पैरामीटर से मिलान करने के लिए बदलें। 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 विकल्प के माध्यम से फ़ज़र को उसकी ओर इंगित करना होगा।
अंतर्निहित सिंटैक्स का अधिक संरचित विवरण प्रदान करने का कोई तरीका नहीं है, लेकिन फ़ज़र संभवतः अकेले instrumentation फीडबैक के आधार पर इसका कुछ हिस्सा समझ लेगा। यह वास्तव में व्यवहार में काम करता है, उदाहरण के लिए:
http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html
पी.एस. भले ही कोई स्पष्ट शब्दकोश न दिया गया हो, afl-fuzz निर्धारणात्मक बाइट फ़्लिप के दौरान instrumentation को बहुत बारीकी से देखकर इनपुट corpus में मौजूद सिंटैक्स टोकन निकालने का प्रयास करेगा। यह कुछ प्रकार के पार्सर और व्याकरण के लिए काम करता है, लेकिन -x मोड जितना अच्छा नहीं है।
क्रैश का कवरेज-आधारित समूहीकरण आमतौर पर एक छोटा डेटा सेट उत्पन्न करता है जिसे मैन्युअल रूप से या बहुत सरल GDB या Valgrind स्क्रिप्ट के साथ जल्दी से ट्राइएज किया जा सकता है। प्रत्येक क्रैश क्यू में अपने मूल गैर-क्रैशिंग टेस्ट केस से भी जुड़ा होता है, जिससे दोषों का निदान करना आसान हो जाता है।
ऐसा कहने के बाद, यह स्वीकार करना महत्वपूर्ण है कि कुछ फ़ज़िंग क्रैश को बहुत अधिक डिबगिंग और कोड विश्लेषण कार्य के बिना शोषण-क्षमता के लिए जल्दी से मूल्यांकन करना मुश्किल हो सकता है। इस कार्य में सहायता के लिए, afl-fuzz एक बहुत ही अनोखे "क्रैश एक्सप्लोरेशन" मोड का समर्थन करता है जो -C फ़्लैग से सक्षम होता है।
इस मोड में, फ़ज़र एक या अधिक क्रैशिंग टेस्ट केसों को इनपुट के रूप में लेता है, और अपनी फीडबैक-संचालित फ़ज़िंग रणनीतियों का उपयोग करके प्रोग्राम को क्रैशिंग स्थिति में रखते हुए उन सभी कोड पथों को बहुत तेज़ी से गिनता है जिन तक पहुँचा जा सकता है।
जो उत्परिवर्तन क्रैश का परिणाम नहीं देते, उन्हें अस्वीकार कर दिया जाता है; ऐसे किसी भी परिवर्तन को भी अस्वीकार कर दिया जाता है जो निष्पादन पथ को प्रभावित नहीं करता।
आउटपुट फ़ाइलों का एक छोटा corpus है जिसे बहुत तेज़ी से जाँचा जा सकता है कि हमलावर का दोषपूर्ण एड्रेस पर किस हद तक नियंत्रण है, या क्या प्रारंभिक आउट-ऑफ़-बाउंड्स रीड से आगे निकलना संभव है - और देखें कि नीचे क्या है।
ओह, एक और बात: टेस्ट केस न्यूनीकरण के लिए, afl-tmin आज़माएँ। टूल को बहुत ही सरल तरीके से संचालित किया जा सकता है:
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]
यह टूल क्रैशिंग और गैर-क्रैशिंग दोनों तरह के टेस्ट केसों के साथ काम करता है। क्रैश मोड में, यह इंस्ट्रूमेंटेड और गैर-इंस्ट्रूमेंटेड दोनों बाइनरी स्वीकार करेगा। गैर-क्रैशिंग मोड में, मिनिमाइज़र निष्पादन पथ को बदले बिना फ़ाइल को सरल बनाने के लिए मानक AFL इंस्ट्रूमेंटेशन पर निर्भर करता है।
मिनिमाइज़र afl-fuzz के अनुकूल तरीके से -m, -t, -f और @@ सिंटैक्स स्वीकार करता है।
AFL में एक और हालिया जोड़ afl-analyze टूल है। यह एक इनपुट फ़ाइल लेता है, क्रमिक रूप से बाइट्स फ़्लिप करने का प्रयास करता है, और परीक्षण किए गए प्रोग्राम के व्यवहार का निरीक्षण करता है। फिर यह इनपुट को इस आधार पर रंग-कोडित करता है कि कौन से अनुभाग महत्वपूर्ण प्रतीत होते हैं, और कौन से नहीं; हालाँकि यह बुलेटप्रूफ नहीं है, यह अक्सर जटिल फ़ाइल प्रारूपों में त्वरित अंतर्दृष्टि प्रदान कर सकता है। इसके संचालन के बारे में अधिक जानकारी technical_details.txt के अंत के पास पाई जा सकती है।
कृपया ध्यान रखें कि, कई अन्य कम्प्यूटेशनल-गहन कार्यों के समान, फ़ज़िंग आपके हार्डवेयर और OS पर दबाव डाल सकती है। विशेष रूप से:
आपका CPU गर्म हो जाएगा और उसे पर्याप्त कूलिंग की आवश्यकता होगी। अधिकांश मामलों में, यदि कूलिंग अपर्याप्त है या ठीक से काम करना बंद कर देती है, तो CPU की गति स्वचालित रूप से थ्रॉटल हो जाएगी। फिर भी, विशेष रूप से कम उपयुक्त हार्डवेयर (लैपटॉप, स्मार्टफ़ोन, आदि) पर फ़ज़िंग करते समय, किसी चीज़ के फटने की संभावना पूरी तरह से असंभव नहीं है।
लक्षित प्रोग्राम अंततः अनियमित रूप से गीगाबाइट्स मेमोरी हड़प सकते हैं या डिस्क स्थान को जंक फ़ाइलों से भर सकते हैं। AFL बुनियादी मेमोरी सीमाओं को लागू करने का प्रयास करता है, लेकिन हर संभव दुर्घटना को नहीं रोक सकता। मूल बात यह है कि आपको उन प्रणालियों पर फ़ज़िंग नहीं करनी चाहिए जहाँ डेटा हानि की संभावना एक स्वीकार्य जोखिम नहीं है।- फ़ज़िंग में फ़ाइलसिस्टम पर अरबों रीड और राइट शामिल हैं। आधुनिक सिस्टमों पर, यह आमतौर पर भारी कैश किया जाएगा, जिसके परिणामस्वरूप काफी मामूली "भौतिक" I/O - लेकिन कई कारक हैं जो इस समीकरण को बदल सकते हैं। संभावित परेशानी की निगरानी करना आपकी ज़िम्मेदारी है; बहुत भारी I/O के साथ, कई HDD और SSD की आयु कम हो सकती है।
लिनक्स पर डिस्क I/O की निगरानी करने का एक अच्छा तरीका 'iostat' कमांड है:
$ iostat -d 3 -x -k [...optional disk ID...]
AFL के लिए कुछ सबसे महत्वपूर्ण चेतावनियाँ यहाँ दी गई हैं:
AFL पहली स्पॉन की गई प्रक्रिया के सिग्नल (SIGSEGV, SIGABRT, आदि) के कारण मरने की जाँच करके दोषों का पता लगाता है। जो प्रोग्राम इन सिग्नलों के लिए कस्टम हैंडलर स्थापित करते हैं, उनमें प्रासंगिक कोड को कमेंट आउट करने की आवश्यकता हो सकती है। इसी तरह, फ़ज़ किए गए लक्ष्य द्वारा स्पॉन की गई चाइल्ड प्रक्रियाओं में दोषों का पता लगाना मुश्किल हो सकता है जब तक आप उन्हें पकड़ने के लिए मैन्युअल रूप से कुछ कोड नहीं जोड़ते।
किसी भी अन्य ब्रूट-फोर्स टूल की तरह, फ़ज़र सीमित कवरेज प्रदान करता है यदि एन्क्रिप्शन, चेकसम, क्रिप्टोग्राफ़िक हस्ताक्षर, या कम्प्रेशन का उपयोग किया जाता है ताकि परीक्षण किए जाने वाले वास्तविक डेटा प्रारूप को पूरी तरह से लपेटा जा सके।
इससे निपटने के लिए, आप प्रासंगिक जाँचों को कमेंट आउट कर सकते हैं (देखें experimental/libpng_no_checksum/ प्रेरणा के लिए); यदि यह संभव नहीं है, आप एक पोस्टप्रोसेसर भी लिख सकते हैं, जैसा कि experimental/post_library/ में समझाया गया है।
ASAN और 64-बिट बाइनरी के साथ कुछ दुर्भाग्यपूर्ण ट्रेड-ऑफ हैं। यह afl-fuzz की किसी विशिष्ट गलती के कारण नहीं है; सुझावों के लिए notes_for_asan.txt देखें।
नेटवर्क सेवाओं, बैकग्राउंड डेमॉन, या इंटरैक्टिव ऐप्स जिन्हें काम करने के लिए UI इंटरैक्शन की आवश्यकता होती है, उन्हें फ़ज़ करने के लिए कोई सीधा समर्थन नहीं है। उन्हें अधिक पारंपरिक तरीके से व्यवहार करने के लिए आपको सरल कोड परिवर्तन करने की आवश्यकता हो सकती है। Preeny भी अपेक्षाकृत सरल विकल्प प्रदान कर सकता है - देखें: https://github.com/zardus/preeny
नेटवर्क-आधारित सेवाओं को संशोधित करने के लिए कुछ उपयोगी सुझाव भी यहाँ मिल सकते हैं: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
AFL मानव-पठनीय कवरेज डेटा आउटपुट नहीं करता है। यदि आप कवरेज की निगरानी करना चाहते हैं, तो Michael Rash से afl-cov का उपयोग करें: 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 की आवश्यकता नहीं है।