पूर्णांक के लिए खोज करने के लिए Clang Static विश्लेषक के लिए एक प्लगइन बनाना

लेख लेखक: 0x64rem

प्रविष्टि

डेढ़ साल पहले, मुझे विश्वविद्यालय में थीसिस के हिस्से के रूप में अपने फेजर को महसूस करने का विचार था। मैंने नियंत्रण प्रवाह ग्राफ़, डेटा प्रवाह ग्राफ़, प्रतीकात्मक निष्पादन आदि के बारे में सामग्रियों का अध्ययन करना शुरू किया। इसके बाद टूल्स की तलाश में आया, विभिन्न पुस्तकालयों का एक नमूना (Angr, Triton, Pin, Z3)। अंत में कुछ भी ठोस नहीं हुआ, इस गर्मी तक मैं डिजिटल सुरक्षा समर ऑफ हैक 2019 कार्यक्रम में गया, जहां मुझे परियोजना के लिए एक थीम के रूप में क्लैंग स्टेटिक विश्लेषक के विस्तार की पेशकश की गई। ऐसा लग रहा था कि यह विषय मुझे अपने सैद्धांतिक ज्ञान को समतल पर रखने में मदद करेगा, कुछ को लागू करना शुरू करेगा और अनुभवी आकाओं से सिफारिशें प्राप्त करेगा। आगे, मैं आपको बताऊंगा कि प्लग-इन लिखने की प्रक्रिया कैसे हुई और इंटर्नशिप महीने के दौरान मेरे विचारों के पाठ्यक्रम का वर्णन करें।

क्लैंग स्टैटिक एनालाइजर

विकास के लिए, क्लैंग इंटरैक्शन के लिए तीन इंटरफ़ेस विकल्प प्रदान करता है:

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

चूंकि हम क्लैंग स्टेटिक एनालाइज़र की क्षमताओं का विस्तार करने जा रहे हैं, इसलिए हम प्लगइन के कार्यान्वयन का चयन करते हैं। आप C ++ या Python में प्लगइन के लिए कोड लिख सकते हैं।

उत्तरार्द्ध के लिए, बाइंडर्स हैं जो आपको स्रोत कोड को पार्स करने की अनुमति देते हैं, परिणामस्वरूप सार सिंटैक्स ट्री के नोड्स पर पुनरावृति करते हैं, नोड्स के गुणों तक भी पहुंच रखते हैं और नोड को स्रोत कोड की पंक्ति में मैप कर सकते हैं। ऐसा सेट एक साधारण चेकर के लिए उपयुक्त है। अधिक विवरण के लिए llvm रिपॉजिटरी देखें।

मेरे कार्य को कोड के विस्तृत विश्लेषण की आवश्यकता है, इसलिए C ++ को विकास के लिए चुना गया था। अगला उपकरण का एक परिचय है।

क्लैंग स्टैक एनालाइज़र (इसके बाद CSA) प्रतीकात्मक निष्पादन के आधार पर C / C ++ / Objective-C कोड के स्थैतिक विश्लेषण के लिए एक उपकरण है। एनालाइजर को Clang फ्रंटएंड के माध्यम से -c1 और -analyze झंडे को बिल्ड कमांड में, या एक अलग स्कैन-बिल्ड बिनार के माध्यम से बुलाया जा सकता है। विश्लेषण के अलावा, CSA विज़ुअल HTML रिपोर्ट तैयार करना संभव बनाता है।

# ,      clang' clang -cc1 --help #  CSA  №1 clang++ -cc1 -x c++ -load path/to/Checker.so -analyze -analyzer-checker=test.Me -analyzer-config $BUILD_OPTIONS Checker.cpp 

  #  CSA  №2 scan-build -load-plugin path/to/Checker.so -enable-checker test.Me $BUILD_COMMAND 

  #       DivideZero clang++ -cc1 -analyze -analyzer-checker=core.DivideZero -o reports div-by-zero-test.cpp 

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

• Stmt - इसमें बाइनरी ऑपरेशन शामिल हैं।

  
  

• Decl - चर की घोषणा।

  
  

• Expr - भावों के बाएँ, दाएँ भाग, उनके प्रकार को संग्रहीत करता है।

  
  

• ASTContext - पेड़, वर्तमान नोड के बारे में जानकारी।

  
  

• स्रोत प्रबंधक - वास्तविक कोड के बारे में जानकारी जो पेड़ के हिस्से से मेल खाती है।

  
  

• RecursiveASTVisitor, ASTMatcher - एक पेड़ को पार करने के लिए कक्षाएं।

  
  

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

  
  

इंटेगर ओवरफ्लो सर्च

प्लगइन को लागू करना शुरू करने के लिए, आपको उस कार्य को चुनना होगा जिसे वह हल करेगा। इस मामले के लिए, llvm वेबसाइट संभावित चेकर्स की सूची प्रदान करती है ; आप मौजूदा स्थिर या अल्फा चेकर्स को भी संशोधित कर सकते हैं। उपलब्ध चेकर्स के कोड की समीक्षा करने में, यह स्पष्ट हो गया कि लिबक्लांग के अधिक सफल विकास के लिए अपने चेकर को खरोंच से लिखना बेहतर है, इसलिए पसंद को अवास्तविक विचारों की सूची से बनाया गया था। परिणामस्वरूप, पूर्णांक ओवरफ़्लो का पता लगाने के लिए एक चेकर बनाने के लिए विकल्प चुना गया था। इस भेद्यता को रोकने के लिए क्लैंग के पास पहले से ही कार्यशीलता है (झंडे-पट्टापर्व, -fwrapv और जैसे इसके उपयोग के लिए संकेत दिए गए हैं), यह संकलक में बनाया गया है, और इस तरह के निकास को चेतावनी में डाला जाता है, और यह अक्सर वहां नहीं होता है। यूबीएसएन अभी भी है , लेकिन ये सैनिटाइज़र हैं, हर कोई उनका उपयोग नहीं करता है, और यह विधि रनटाइम पर समस्याओं की पहचान करने के बारे में है, और सीएसए प्लग-इन समय पर काम करता है, सूत्रों का विश्लेषण करता है।

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

C ++ में, एक अंकगणितीय तुलना ऑपरेशन के दौरान, पूर्णांक मान एक ही प्रकार के लिए डाले जाते हैं, बिट गहराई के संदर्भ में अधिक बार। और ऐसे भूत हर जगह और लगातार होते हैं, वे स्पष्ट या निहित हो सकते हैं। कई नियम हैं जिनके द्वारा भूत होते हैं [1]:

• एक हस्ताक्षरित से एक प्रकार से परिवर्तित होकर हस्ताक्षरित, लेकिन बड़ा बिट: बस उच्च क्रम जोड़ें।
• हस्ताक्षरित पूर्णांक को समान क्षमता के अहस्ताक्षरित पूर्णांक में परिवर्तित करना: ऋणात्मक को धनात्मक में बदल दिया जाता है और एक नया अर्थ ग्रहण करता है। DirectFB में एक समान त्रुटि का एक उदाहरण CVE-2014-2977 है ।
• एक हस्ताक्षरित पूर्णांक को एक बड़ी बिट क्षमता के अहस्ताक्षरित पूर्णांक में परिवर्तित करना: सबसे पहले, थोड़ी क्षमता का विस्तार होगा, फिर यदि संख्या नकारात्मक है, तो यह गलत तरीके से मूल्य बदल देगा। उदाहरण के लिए: 0xff (-1) 0xffffffff हो जाता है।
• एक ही बिट क्षमता के संकेत के साथ एक अहस्ताक्षरित पूर्णांक: एक संख्या उच्च बिट के मूल्य के आधार पर मूल्य को बदल सकती है।
• एक पूर्णांक के साथ एक अहस्ताक्षरित पूर्णांक जिसमें अधिक क्षमता का संकेत होता है: पहले, एक अहस्ताक्षरित संख्या की क्षमता बढ़ जाती है, फिर एक हस्ताक्षरित रूपांतरण।
• नीचे रूपांतरण: बिट्स को केवल काट दिया जाता है। यह अहस्ताक्षरित मानों को और अधिक नकारात्मक बना सकता है। PHP में इस तरह की भेद्यता का एक उदाहरण।

यानी भेद्यता के लिए ट्रिगर असुरक्षित उपयोगकर्ता इनपुट, गलत अंकगणित, गलत प्रकार का रूपांतरण हो सकता है जो अनुकूलन के दौरान प्रोग्रामर या कंपाइलर के कारण होता है। समय बम विकल्प भी संभव है, जब कोड का एक टुकड़ा संकलक के एक संस्करण के साथ हानिरहित होता है, लेकिन एक नए अनुकूलन एल्गोरिथ्म की रिहाई के साथ "विस्फोट" होता है और अप्रत्याशित व्यवहार का कारण बनता है। इतिहास में, SafeInt वर्ग (बहुत विडंबनापूर्ण) [5, 6.5.2] के साथ इस तरह का मामला पहले भी आ चुका है।

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

• CVE-2019-3560 - Fizz में पूर्णांक अतिप्रवाह (फेसबुक के लिए TLS को लागू करने वाला एक प्रोजेक्ट) एक तंग नेटवर्क पैकेट का उपयोग करके DoS भेद्यता का फायदा उठा सकता है।
• CVE-2018-14618 - पासवर्ड लंबाई के कारण पूर्णांक अतिप्रवाह के कारण कर्ल में बफर अतिप्रवाह।
• CVE-2018-6092 - 32-बिट सिस्टम पर, क्रोम के लिए WebAssembly में एक भेद्यता RCE को एक विशेष HTML पृष्ठ के माध्यम से कार्यान्वित करने की अनुमति देता है।

पहिया को सुदृढ़ नहीं करने के लिए, CppCheck स्थैतिक विश्लेषक में पूर्णांक ओवरफ़्लो का पता लगाने के लिए कोड पर विचार किया गया था। उनका दृष्टिकोण इस प्रकार है:

1. निर्धारित करें कि क्या कोई अभिव्यक्ति बाइनरी ऑपरेटर है।
2. यदि हाँ, तो यह देखने के लिए जांचें कि क्या दोनों तर्क पूर्णांक प्रकार के हैं।
3. प्रकारों का आकार निर्धारित करें।
4. गणना के माध्यम से जांचें कि क्या मूल्य इसकी अधिकतम या न्यूनतम सीमा से आगे जा सकता है।
   लेकिन इस स्तर पर इसने स्पष्टता नहीं दी। यह बहुत सी अलग-अलग कहानियों का पता लगाता है, और इससे सूचनाओं का व्यवस्थितकरण अधिक कठिन हो जाता है। इसके स्थान पर हर चीज ने CWE की सूची में जगह बनाई। कुल मिलाकर, साइट पर 9 प्रकार के पूर्णांक ओवरफ़्लो आबंटित हैं:
   
   • 190 - पूर्णांक oveflow
   • 191 - पूर्णांक अंडरफ़्लो
   • 192 - पूर्णांक जमाव त्रुटि
   • 193 - ऑफ-बाय-वन
   • 194 - अनपेक्षित साइन एक्सटेंशन
   • 195 - अनसाइन्टेड कनवर्ज़न एरर पर हस्ताक्षर किए
   • 196 - हस्ताक्षरित रूपांतरण त्रुटि को अनसाइन किया गया
   • 197 - न्यूमेरिक ट्रंकेशन एरर
   • 198 - गलत बाइट ऑर्डर का उपयोग

हम प्रत्येक विकल्प के कारण पर विचार करते हैं और समझते हैं कि ओवरफ्लो गलत स्पष्ट / निहित जातियों के साथ होता है। और क्योंकि अमूर्त सिंटैक्स ट्री की संरचना में किसी भी जाति को प्रदर्शित किया जाता है, हम विश्लेषण के लिए एएसटी का उपयोग करेंगे। नीचे दिए गए चित्र (छवि 3) में, यह देखा जा सकता है कि पेड़ में डाली जाने वाली कोई भी कार्रवाई एक अलग नोड है, और, पेड़ के चारों ओर घूमते हुए, हम परिवर्तन के साथ तालिका के आधार पर सभी प्रकार के रूपांतरणों की जांच कर सकते हैं जो त्रुटि का कारण हो सकता है।

विशेष रूप से, एल्गोरिथ्म इस तरह से लगता है: हम कास्ट के चारों ओर जाते हैं और इंटीग्रलकैस्ट (पूर्णांक रूपांतरण) को देखते हैं। यदि आप एक उपयुक्त नोड पाते हैं, तो बाइनरी ऑपरेशन या डेक्ले (चर घोषणा) के वंशज को देखें। पहले मामले में, आपको साइन और बिट गहराई की जांच करने की आवश्यकता है जो बाइनरी ऑपरेशन का उपयोग करता है। दूसरे मामले में, केवल घोषणा के प्रकार की तुलना करें।

चेकर कार्यान्वयन

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

यदि आप अपने चेकर को अपने क्लैंग असेंबली में जोड़ना चाहते हैं, तो आपको निम्न करने की आवश्यकता है:

1. लगभग निम्नलिखित सामग्री के साथ स्वयं परीक्षक को लिखें:

   
   

    namespace { class SuperChecker : public Checker<check::PreStmt<BinaryOperator>> { //       ,    .       struct CheckerOpts { //       string FlagOne; int FlagTwo; }; CheckerOpts Opts; //cool code }; } void ento::registerSuperChecker(CheckerManager &mgr) { auto checker = mgr.registerChecker<SuperChecker>(); //       ,   4    //       ,  stand-alone    . AnalyzerOptions &AnOpts = mgr.getAnalyzerOptions(); SuperChecker::CheckerOpts &ChOpts = checker->Opts; ChOpts.FlagOne = AnOpts.getCheckerStringOption("Inp1", "", checker); ChOpts.FlagTwo = AnOpts.getCheckerIntegerOption("Inp2", 0, checker); // getCheckerIntegerOption:  ,  ,   } 

   
   

2. फिर, CMakeLists.txt के स्रोत कोड में, आपको CMakeLists.txt और Checkers.td फ़ाइलों को बदलने की आवश्यकता होगी। यहाँ ${llvm-source-path}/clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt आसपास रहते हैं ${llvm-source-path}/clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
   और यहाँ ${llvm-source-path}/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td ।
   पहले में, आपको बस कोड के साथ फ़ाइल नाम जोड़ना होगा, दूसरे में आपको एक संरचनात्मक विवरण जोड़ना होगा:

   
   

     #Checkers.td def SuperChecker : Checker<"SuperChecker">, HelpText<"test checker">, Documentation<HasDocumentation>; 

   
   

यदि यह स्पष्ट नहीं है, तो Checkers.td फ़ाइल में इस बात के पर्याप्त उदाहरण हैं कि कैसे और क्या करना है।

सबसे अधिक संभावना है कि आप क्लैंग का पुनर्निर्माण नहीं करना चाहेंगे, और आप लाइब्रेरी असेंबली (इसलिए / डीएल) के साथ विकल्प का सहारा लेंगे। फिर चेकर के कोड में कुछ इस तरह होना चाहिए:

 namespace { class SuperChecker : public Checker<check::PreStmt<BinaryOperator>> { //       ,    .       struct CheckerOpts { string FlagOne; int FlagTwo; }; CheckerOpts Opts; //cool code }; } void initializationFunction(CheckerManager &mgr){ SuperChecker *checker = mgr.registerChecker<SuperChecker>(); //       ,   4    AnalyzerOptions &AnOpts = mgr.getAnalyzerOptions(); TestChecker::CheckerOpts &ChOpts = checker->Opts; ChOpts.FlagOne = AnOpts.getCheckerStringOption("Inp1", "", checker); ChOpts.FlagTwo = AnOpts.getCheckerIntegerOption("Inp2", 0, checker); // getCheckerIntegerOption:  ,  ,   } extern "C" void clang_registerCheckers (CheckerRegistry &registry) { registry.addChecker(&initializationFunction, "test.Me", "SuperChecker description", "doc_link"); } extern "C" const char clang_analyzerAPIVersionString [] = "8.0.1"; 

अगला, अपना कोड इकट्ठा करें, आप अपनी खुद की स्क्रिप्ट को विधानसभा के लिए लिख सकते हैं, लेकिन अगर आपको इसके साथ कोई समस्या है (जैसा कि लेखक के पास :) था), तो आप क्लैग सोर्स कोड में मेकफाइल का उपयोग कर सकते हैं और एक अजीब तरीके से clangStaticAnalyzerCerers कमांड बना सकते हैं।

अगला, परीक्षक को कॉल करें:

• अंतर्निहित चेकर्स के लिए

  
  

   clang++ -cc1 -analyze -analyzer-checker=core.DivideZero test.cpp 

  
  

• बाहरी के लिए

  
  

   clang++ -cc1 -load ${PATH_TO_CHECKER}/SuperChecker.so -analyze -analyzer-checker=test.Me -analyzer-config test.Me:UsrInp1="foo" test.Me:Inp1="bar" -analyzer-config test.Me:Inp2=123 test.cpp 

  
  

  इस स्तर पर, हमारे पास पहले से ही कुछ प्रकार के परिणाम (छवि 4) हैं, लेकिन लिखित कोड केवल संभावित ओवरफ्लो का पता लगा सकता है। और इसका मतलब है कि बड़ी संख्या में झूठी सकारात्मकता।

  
  

इसे ठीक करने के लिए, हम कर सकते हैं:

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

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

• पहले, इसे पूरा करने में बहुत समय लगता है। एक पेड़ में घूमना, आपकी ज़रूरत की हर चीज़ को खोजना और गिनना काफी समय लेगा, ऐसे कोड के साथ एक बड़ी परियोजना का विश्लेषण करना मुश्किल हो सकता है। कोड में पेड़ पर चलने के लिए, हम clang::RecursiveASTVisitor वर्ग का उपयोग करेंगे, जो एक पुनरावर्ती गहराई खोज करता है। इस दृष्टिकोण के समय का एक अनुमान होगा , जहां V शीर्ष रेखाओं का समूह है, और E ग्राफ़ के किनारों का समूह है।
• दूसरा - आप निश्चित रूप से स्टोर कर सकते हैं, लेकिन हम नहीं जानते कि हमें क्या चाहिए और क्या नहीं होगा। इसके अलावा, पेड़ खुद को संरचना करते हैं, जिसे हम विश्लेषण में उपयोग करते हैं, बहुत अधिक स्मृति की आवश्यकता होती है, इसलिए कुछ अन्य पर ऐसे संसाधनों को खर्च करना एक बुरा विचार है।
• तीसरा एक अच्छा विचार है, इस पद्धति के लिए आप पर्याप्त शोध और उदाहरण पा सकते हैं। लेकिन सीएसए में कोई तैयार दागी नहीं है। एक चेकर है , जिसे बाद में स्रोतों में अल्फा चेकर्स (Alpha.security.taint.TaintPropagation) की सूची में जोड़ा गया था, यह फ़ाइल GenericTaintChecker.cpp में वर्णित है। चेकर अच्छा है, लेकिन केवल सी से ज्ञात असुरक्षित I / O फ़ंक्शन के लिए उपयुक्त है, यह केवल "निशान" चर हैं जो खतरनाक कार्यों के तर्क या परिणाम थे। वर्णित विकल्पों के अलावा, यह "वितरण" मॉडल को सही ढंग से बहाल करने के लिए, वैश्विक चर, वर्ग फ़ील्ड आदि पर विचार करने के लायक है।

इंटर्नशिप के लिए शेष समय GenericTaintChecker.cpp पढ़ने और अपनी आवश्यकताओं को पूरा करने के लिए इसे रीमेक करने की कोशिश में बिताया गया था। यह अवधि के अंत तक सफलतापूर्वक काम नहीं करता था, लेकिन यह डीएसईसी में प्रशिक्षण के दायरे से पहले ही शोधन के लिए एक कार्य बन गया। इसके अलावा विकास के दौरान यह स्पष्ट हो गया कि खतरनाक कार्यों की पहचान करना एक अलग काम है, न कि परियोजना में हमेशा खतरनाक स्थान कुछ मानक कार्यों से आते हैं, इसलिए एक झंडे को परीक्षक को जोड़ा गया था ताकि उन कार्यों की सूची को इंगित किया जा सके जिन्हें "जहर" / "चिह्नित" माना जाएगा। दागी विश्लेषण के दौरान।
इसके अतिरिक्त, यह निर्धारित करने के लिए एक चेक जोड़ा गया था कि क्या चर थोड़ा क्षेत्र है। मानक CSA टूल द्वारा, आकार प्रकार द्वारा निर्धारित किया जाता है, और यदि हम थोड़ा क्षेत्र के साथ काम करते हैं, तो इसके आकार में पूरे क्षेत्र के बिट प्रकार का मूल्य होगा, न कि चर घोषणा में निर्दिष्ट बिट्स की संख्या।

परिणाम क्या है?

फिलहाल, एक साधारण परीक्षक लागू किया गया है जो केवल संभावित पूर्णांक ओवरफ्लो को चेतावनी दे सकता है। दागी विश्लेषण के लिए एक संशोधित वर्ग, जिसमें अभी भी बहुत काम करना है। उसके बाद, आपको ओवरफ्लो को निर्धारित करने के लिए एसएमटी का उपयोग करने की आवश्यकता है। इसके लिए, जेड 3 एसएमटी सॉल्वर उपयुक्त है, जिसे 5.0.0 संस्करण में क्लैंग असेंबली में जोड़ा गया था ( नोट्स जारी करके)। सॉल्वर का उपयोग करने के लिए, यह आवश्यक है कि CLANG_ANALYZER_BUILD_Z3=ON को CLANG_ANALYZER_BUILD_Z3=ON विकल्प के साथ बनाया जाए, और जब CSA प्लग-इन को सीधे कहा जाता है, -Xanalyzer -analyzer-constraints=z3 झंडे प्रसारित होते हैं।

गिटहब परिणाम रिपोजिटरी

संदर्भ:

1. हावर्ड एम।, लेब्लांक डी।, वीगा जे। "द 24 सिन्स ऑफ़ कंप्यूटर सिक्योरिटी"

   
   

2. 24 घंटे में एक परीक्षक कैसे लिखें

   
   

3. क्लैंग स्टैटिक एनालाइज़र: ए चेकर डेवलपर गाइड

   
   

4. सीएसए चेकर विकास मैनुअल

   
   

5. डिट्ज़ डब्ल्यू एट अल। C / C ++ में पूर्णांक ओवरफ़्लो को समझना