american fuzzy lop

मूल रूप से माइकल ज़ेलेव्स्की [email protected] द्वारा विकसित।

यदि आपके पास इस फ़ाइल को पढ़ने का समय नहीं है, तो QuickStartGuide.txt देखें।

1) निर्देशित फ़ज़िंग की चुनौतियाँ

फ़ज़िंग वास्तविक दुनिया के सॉफ़्टवेयर में सुरक्षा समस्याओं की पहचान करने के लिए सबसे शक्तिशाली और सिद्ध रणनीतियों में से एक है; यह सुरक्षा-महत्वपूर्ण सॉफ़्टवेयर में आज तक पाए गए रिमोट कोड निष्पादन और विशेषाधिकार वृद्धि बगों के विशाल बहुमत के लिए ज़िम्मेदार है।

दुर्भाग्य से, फ़ज़िंग अपेक्षाकृत उथली भी है; अंधा, यादृच्छिक उत्परिवर्तन परीक्षण किए गए कोड में कुछ कोड पथों तक पहुँचना बहुत असंभव बना देते हैं, जिससे कुछ कमजोरियाँ इस तकनीक की पहुँच से बाहर रह जाती हैं।

इस समस्या को हल करने के कई प्रयास हुए हैं। प्रारंभिक दृष्टिकोणों में से एक - जिसकी शुरुआत टैविस ऑरमैंडी ने की - कॉर्पस आसवन (corpus distillation) है। यह विधि उम्मीदवार फ़ाइलों के एक विशाल, उच्च-गुणवत्ता वाले कॉर्पस से दिलचस्प सीड्स का एक उपसमुच्चय चुनने के लिए कवरेज सिग्नल पर निर्भर करती है, और फिर उन्हें पारंपरिक तरीकों से फ़ज़ करती है। यह दृष्टिकोण असाधारण रूप से अच्छा काम करता है, लेकिन इसके लिए ऐसे कॉर्पस का आसानी से उपलब्ध होना आवश्यक है। इसके अलावा, ब्लॉक कवरेज माप प्रोग्राम की स्थिति की केवल एक बहुत ही सरल समझ प्रदान करते हैं, और लंबी अवधि में फ़ज़िंग प्रयास का मार्गदर्शन करने के लिए कम उपयोगी होते हैं।

अन्य, अधिक परिष्कृत शोध ने प्रोग्राम फ़्लो विश्लेषण ("concolic execution"), प्रतीकात्मक निष्पादन, या स्थैतिक विश्लेषण जैसी तकनीकों पर ध्यान केंद्रित किया है। ये सभी विधियाँ प्रयोगात्मक सेटिंग्स में अत्यंत आशाजनक हैं, लेकिन व्यावहारिक उपयोगों में विश्वसनीयता और प्रदर्शन समस्याओं से ग्रस्त होती हैं - और वर्तमान में "डम्ब" फ़ज़िंग तकनीकों के लिए एक व्यवहार्य विकल्प प्रदान नहीं करती हैं।

2) afl-fuzz दृष्टिकोण

अमेरिकन फ़ज़ी लोप एक ब्रूट-फोर्स फ़ज़र है जो एक अत्यंत सरल लेकिन ठोस इंस्ट्रुमेंटेशन-निर्देशित आनुवंशिक एल्गोरिदम से युक्त है। यह प्रोग्राम नियंत्रण प्रवाह में सूक्ष्म, स्थानीय-स्तरीय परिवर्तनों को सहजता से पकड़ने के लिए एज कवरेज के एक संशोधित रूप का उपयोग करता है।

थोड़ा सरल करते हुए, समग्र एल्गोरिदम को इस प्रकार संक्षेपित किया जा सकता है:

1. उपयोगकर्ता-आपूर्ति किए गए प्रारंभिक परीक्षण मामलों को कतार में लोड करें,

2. कतार से अगली इनपुट फ़ाइल लें,

3. परीक्षण मामले को सबसे छोटे आकार में छाँटने का प्रयास करें जो प्रोग्राम के मापा व्यवहार को नहीं बदलता,

4. पारंपरिक फ़ज़िंग रणनीतियों की एक संतुलित और अच्छी तरह से शोधित विविधता का उपयोग करके फ़ाइल को बार-बार उत्परिवर्तित करें,

5. यदि उत्पन्न उत्परिवर्तनों में से कोई भी इंस्ट्रुमेंटेशन द्वारा दर्ज एक नया स्टेट ट्रांज़िशन में परिणत हुआ, तो उत्परिवर्तित आउटपुट को कतार में एक नई प्रविष्टि के रूप में जोड़ें।

6. चरण 2 पर जाएँ।

खोजे गए परीक्षण मामलों को भी समय-समय पर हटाया जाता है ताकि उन्हें समाप्त किया जा सके जो नए, उच्च-कवरेज खोजों द्वारा अप्रचलित हो गए हैं; और कई अन्य इंस्ट्रुमेंटेशन-संचालित प्रयास न्यूनीकरण चरणों से गुजरते हैं।

फ़ज़िंग प्रक्रिया के एक पार्श्व परिणाम के रूप में, उपकरण दिलचस्प परीक्षण मामलों का एक छोटा, स्व-निहित कॉर्पस बनाता है। ये अन्य, श्रम- या संसाधन-गहन परीक्षण व्यवस्थाओं को सीड करने के लिए अत्यंत उपयोगी हैं - उदाहरण के लिए, ब्राउज़र, ऑफिस एप्लिकेशन, ग्राफिक्स सुइट्स या क्लोज्ड-सोर्स टूल्स के स्ट्रेस-टेस्टिंग के लिए।

फ़ज़र का पूरी तरह से परीक्षण किया गया है ताकि यह ब्लाइंड फ़ज़िंग या केवल-कवरेज टूल्स से कहीं बेहतर आउट-ऑफ-द-बॉक्स प्रदर्शन प्रदान करे।

3) AFL के साथ उपयोग के लिए प्रोग्रामों का इंस्ट्रुमेंटेशन

जब स्रोत कोड उपलब्ध होता है, तो इंस्ट्रुमेंटेशन को एक साथी उपकरण द्वारा इंजेक्ट किया जा सकता है जो तृतीय-पक्ष कोड के लिए किसी भी मानक बिल्ड प्रक्रिया में 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

AFL_HARDEN=1 सेट करके 'make' कॉल करने पर CC रैपर स्वचालित रूप से कोड हार्डनिंग विकल्प सक्षम करेगा जिससे साधारण मेमोरी बग्स का पता लगाना आसान हो जाता है। Libdislocator, AFL के साथ शामिल एक सहायक लाइब्रेरी (देखें libdislocator/README.dislocator) हीप करप्शन समस्याओं को उजागर करने में भी मदद कर सकती है।

पी.एस. ASAN उपयोगकर्ताओं को सलाह दी जाती है कि वे महत्वपूर्ण चेतावनियों के लिए notes_for_asan.txt फ़ाइल देखें।

4) केवल-बाइनरी ऐप्स का इंस्ट्रुमेंटेशन

जब सोर्स कोड उपलब्ध नहीं होता, तो फ़ज़र ब्लैक-बॉक्स बाइनरीज़ के तेज़, ऑन-द-फ्लाई इंस्ट्रुमेंटेशन के लिए प्रायोगिक समर्थन प्रदान करता है। यह QEMU के एक संस्करण के साथ पूरा किया जाता है जो कम-ज्ञात "यूज़र स्पेस एमुलेशन" मोड में चलता है।

QEMU, AFL से अलग एक प्रोजेक्ट है, लेकिन आप आसानी से इस सुविधा को निम्न प्रकार से बना सकते हैं:```shell $ cd qemu_mode $ ./build_qemu_support.sh

For additional instructions and caveats, see qemu_mode/README.qemu.

The mode is approximately 2-5x slower than compile-time instrumentation, is
less conducive to parallelization, and may have some other quirks.

## 5) प्रारंभिक परीक्षण मामले चुनना

सही ढंग से काम करने के लिए, फ़ज़र को एक या अधिक प्रारंभिक फ़ाइल की आवश्यकता होती है जो
लक्षित एप्लिकेशन द्वारा सामान्य रूप से अपेक्षित इनपुट डेटा का एक अच्छा उदाहरण शामिल करती है।
दो बुनियादी नियम हैं:

  - फ़ाइलों को छोटा रखें। 1 kB से कम आदर्श है, हालांकि यह सख्त रूप से आवश्यक नहीं है।
    आकार क्यों मायने रखता है, इस चर्चा के लिए, [perf_tips.txt](https://github.com/google/afl/blob/master/docs/perf_tips.txt) देखें।

  - एकाधिक परीक्षण मामलों का उपयोग केवल तभी करें जब वे कार्यात्मक रूप से
    एक-दूसरे से भिन्न हों। पचास अलग-अलग छुट्टियों की तस्वीरों का उपयोग किसी इमेज लाइब्रेरी को
    फ़ज़ करने के लिए कोई मतलब नहीं है।

आप इस टूल के साथ आने वाली testcases/ उपनिर्देशिका में प्रारंभिक फ़ाइलों के कई अच्छे उदाहरण
पा सकते हैं।

PS. यदि स्क्रीनिंग के लिए डेटा का एक बड़ा कॉर्पस उपलब्ध है, तो आप
afl-cmin उपयोगिता का उपयोग करके कार्यात्मक रूप से भिन्न फ़ाइलों का एक उपसमुच्चय पहचानना चाह सकते हैं जो
लक्षित बाइनरी में विभिन्न कोड पथों का अभ्यास करते हैं।

## 6) बाइनरी फ़ज़िंग

फ़ज़िंग प्रक्रिया स्वयं afl-fuzz उपयोगिता द्वारा संचालित होती है। यह प्रोग्राम
प्रारंभिक परीक्षण मामलों के साथ एक केवल-पठनीय निर्देशिका, निष्कर्षों को संग्रहीत करने के लिए एक अलग स्थान,
और परीक्षण के लिए बाइनरी का एक पथ की आवश्यकता होती है।

उन लक्षित बाइनरी के लिए जो सीधे stdin से इनपुट स्वीकार करते हैं, सामान्य सिंटैक्स है:```shell
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]

फ़ाइल से इनपुट लेने वाले प्रोग्रामों के लिए, '@@' का उपयोग उस स्थान को चिह्नित करने के लिए करें जहाँ लक्ष्य की कमांड लाइन में इनपुट फ़ाइल का नाम रखा जाना चाहिए। फ़ज़र आपके लिए इसे प्रतिस्थापित कर देगा:```shell $ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@

आप म्यूटेटेड डेटा को किसी विशेष फ़ाइल में लिखवाने के लिए -f विकल्प का भी उपयोग कर सकते हैं,
यह तब उपयोगी है जब प्रोग्राम किसी विशेष फ़ाइल एक्सटेंशन या ऐसी ही चीज़ की अपेक्षा करता है।