स्मार्ट अनुबंधों के स्वचालित ऑडिट के लिए गाइड। भाग 2: धीमा

विश्लेषक: धीरे
विवरण: सॉलिडिटी के लिए ओपन-सोर्स स्टैटिक एनालिसिस फ्रेमवर्क
githib: https://github.com/trailofbits/slither

यह एक स्थिर कोड विश्लेषक है जिसे अजगर में लिखा गया है। वह जानता है कि चर, कॉल, और कमजोरियों की सूची का पता कैसे लगाया जाए। प्रत्येक भेद्यता में विवरण के साथ एक लिंक होता है, और यदि आप सॉलिडिटी के लिए नए हैं, तो यह आपके लिए सभी को जानने के लिए समझ में आता है।

धीरे-धीरे एक अजगर मॉड्यूल के रूप में काम कर सकता है और प्रोग्रामर को अपनी योजना के अनुसार ऑडिटिंग के लिए इंटरफ़ेस प्रदान कर सकता है। एक सरल और उदाहरण है कि जो कुछ भी कर सकता है वह यहाँ देखा जा सकता है ।

हम लेख के अंत में विश्लेषण लिपियों पर वापस लौट आएंगे, लेकिन अभी के लिए:

git clone https://github.com/trailofbits/slither.git cd slither docker build -t slither . 

और हमारे अनुबंध का विश्लेषण करने का प्रयास करें।

हम कंस्ट्रक्टर-एथ-बुकिंग के साथ डायरेक्टरी में जाते हैं और डॉकटर से धीरे चलने की कोशिश करते हैं:

 $ docker run -v $(pwd)/contracts:/slither/contracts slither contracts/flattened.sol 

हमें त्रुटि "स्रोत फ़ाइल के लिए अलग संकलक संस्करण की आवश्यकता होती है", और अब हमें solc=0.4.20 के संस्करण को solc=0.4.20 में solc=0.4.20 । ऐसा करने के लिए, हम खुद के डॉकरीफाइल को सही करते हैं, जैसा कि परिचय में धारा 2 में इंगित किया गया था, अर्थात्। Dockerfile के अंत में कहीं हम लाइन जोड़ते हैं:

 COPY --from=ethereum/solc:0.4.20 /usr/bin/solc /usr/bin 

, छवि का पुनर्निर्माण, भागो, चीयर्स, सब कुछ संकलित।

हम आउटपुट को विभिन्न "प्राग्मा" के बारे में चेतावनी देते हैं और Parameter '_price' of Booking.Booking (flattened.sol#73) is not in mixedCase जैसे गलत चर नामों के बारे में चेतावनी देते हैं Parameter '_price' of Booking.Booking (flattened.sol#73) is not in mixedCase । विश्लेषणकर्ता बहुत सी चेतावनी देते हैं, लेकिन हम असली कीड़े की तलाश कर रहे हैं, और हम ट्रिफ़ल पर ध्यान नहीं देंगे। हम मिश्रित संदेश के बारे में सभी संदेश फ़िल्टर करते हैं, अब यह शैली तक नहीं है:

 $ docker run -v $(pwd)/contracts:/slither/contracts slither contracts/flattened.sol 2>&1 | fgrep -v 'mixedCase' 

सच्चे प्रोग्रामर्स को हरे रंग की याद आती है, सब कुछ लाल दिखाई देता है, और यहाँ झूठे-सकारात्मक के अलावा अनुबंध में पाया गया है:

 Booking.refundWithoutCancellationFee (flattened.sol#243-250) sends eth to arbirary user Dangerous calls: - client.transfer(address(this).balance) (flattened.sol#249) Reference: https://github.com/trailofbits/slither/wiki/Vulnerabilities-Description#functions-that-send-ether-to-arbitrary-destinations INFO:Detectors: Booking.refundWithCancellationFee (flattened.sol#252-259) sends eth to arbirary user Dangerous calls: - owner.transfer(m_cancellationFee) (flattened.sol#257) - client.transfer(address(this).balance) (flattened.sol#258) Reference: https://github.com/trailofbits/slither/wiki/Vulnerabilities-Description#functions-that-send-ether-to-arbitrary-destinations 

अब देखें कि अनुबंध में इस कार्य में क्या गलत है:

  /************************** PRIVATE **********************/ function refundWithoutCancellationFee() private { address client = m_client; m_client = address(0); changeState(State.OFFER); client.transfer(address(this).balance); } function refundWithCancellationFee() private { address client = m_client; m_client = address(0); changeState(State.CANCELED); owner.transfer(m_cancellationFee); client.transfer(address(this).balance); } 

इस मामले में, उदाहरण के लिए, फ़ंक्शन refundWithoutCancellationFee() इस तरह कहा जाता है:

  function rejectPayment() external onlyOwner onlyState(State.PAID) { refundWithoutCancellationFee(); } function refund() external onlyClient onlyState(State.PAID) { refundWithoutCancellationFee(); } 

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

मैंने डबल-चेक किया कि किसी भी प्रसारण के लिए स्लेयर को कोस रहे थे, और फ़ंक्शन बॉडी को सीधे "रिजेक्टपेमेंट (") और "रिफंड ()" में स्थानांतरित कर दिया, चेतावनी गायब हो गई, अर्थात्। धीरे-धीरे एहसास हुआ कि अब प्रसारण बिना पते की जांच के नहीं भेजा जाता है। शानदार शुरुआत!

अब देखते हैं कि स्लेरी चर के आरंभ की निगरानी कैसे करता है, इसके लिए हम दो प्रारंभिकताओं पर टिप्पणी करते हैं:

 - m_fileHash = _fileHash; + // m_fileHash = _fileHash; - m_price = _price; + // m_price = _price; 

पहला बहुत महत्वपूर्ण नहीं है, छिद्रों के संदर्भ में, संसाधनों को बर्बाद करने के अलावा, क्योंकि m_fileHash का कहीं भी उपयोग नहीं किया जाता है, यह केवल अनुबंध बनाते समय ब्लॉकचेन पर संग्रहीत होता है। लेकिन m_price का उपयोग किया जाता है, और धीरे-धीरे सही ढंग से शपथ लेता है कि m_price को कहीं भी आरंभीकृत नहीं किया गया है, हालाँकि इसका उपयोग किया जाता है:

 Booking.m_price (flattened.sol#128) is never initialized. It is used in: - fallback (flattened.sol#144-156) 

अच्छी तरह से यह एक सरल चाल है, जैसा कि अपेक्षित था, सब कुछ ठीक काम किया।

अब हम अनुबंध में हर किसी के लिए रीटर्रेंक को जोड़ देंगे: हम बाहरी कॉल के बाद अनुबंध की स्थिति को बदल देंगे। हम निम्नलिखित परिवर्तन करते हैं:

  function refundWithoutCancellationFee() private { address client = m_client; - m_client = address(0); - changeState(State.OFFER); - client.transfer(address(this).balance); + client.call.value(address(this).balance)(); + m_client = address(0); + changeState(State.OFFER); } 

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

पुनर्व्यवस्थित खोज परिणाम:

 Reentrancy in Booking.refundWithoutCancellationFee (flattened.sol#243-253): External calls: - client.call.value(address(this).balance)() (flattened.sol#245) State variables written after the call(s): - m_client (flattened.sol#246) 

यह ठीक है, कम से कम यह बाहरी कॉल के बाद राज्य चर नहीं देता है, और यह बहुत अच्छा है।

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

अब, मैं ऐसे बदलाव करूँगा जो स्थिर विश्लेषणकर्ताओं के काम की बारीकियों को पूरी तरह से दिखा दें:

 - client.transfer(address(this).balance + for (uint i=0; i < 1; i++) { + client.transfer(address(this).balance - 999999999999999999); + } 

और परिणाम:

 Booking.refundWithoutCancellationFee has external calls inside a loop: - client.transfer(address(this).balance - 999999999999999999) (flattened.sol#252) Reference: https://github.com/trailofbits/slither/wiki/Vulnerabilities-Description/_edit#calls-inside-a-loop 

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

हमने परीक्षण के लिए अपनी स्वयं की स्क्रिप्ट लिखने की संभावना का उल्लेख करने का वादा किया, और --print कुंजी का उपयोग करके अनुबंध के बारे में किसी भी दिलचस्प जानकारी का उत्पादन। इस दृष्टिकोण से, धीमे से CI के लिए एक महान उपकरण है। एक बड़ी अनुबंध प्रणाली के डेवलपर्स सुरक्षा-महत्वपूर्ण चर के नाम जानते हैं: संतुलन, कमीशन आकार, झंडे, और एक परीक्षण स्क्रिप्ट लिख सकते हैं जो कोड में किसी भी बदलाव को रोक देगा, उदाहरण के लिए, एक महत्वपूर्ण चर को अधिलेखित करना, या बाहरी कॉल के बाद राज्य चर बदलना, और इसका अत्यधिक अनुमानित विश्लेषण हुक में उपयोग के लिए एक महान उपकरण है।
स्लेरी का कार्य आपको मूर्खतापूर्ण कीड़े से बचाने, अच्छी तरह से ज्ञात खतरनाक पैटर्न खोजने और डेवलपर को चेतावनी देना है। इस संस्करण में, यह सॉलिडिटी पर एक नौसिखिया डेवलपर के लिए एक उपकरण के रूप में अच्छा है, तुरंत संकेत देता है कि सॉलिडिटी में कोड को सही तरीके से कैसे लिखा जाए।

परिणाम

अपने व्यक्तिगत परीक्षण में, मैं बहुमुखी प्रतिभा, सरलता और उपयोग में आसानी के लिए चार और साथ ही साथ सरल और समझने योग्य परीक्षण लिपियों और CI के लिए अनुकूलनशीलता के लिए डालूँगा।

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

अगले लेख में, हम मिथाइल एनालाइज़र से निपटेंगे, लेकिन यहाँ उन लेखों की सामग्री दी गई है, जो लिखने के लिए तैयार हैं या नीचे हैं:

भाग 1. परिचय। संकलन, चपटा, एकरूपता के संस्करण
भाग 2। यहां (यह लेख)
भाग 3. मिथक
भाग 4. मतिकोर (लेखन की प्रक्रिया में)
भाग 5. इचिदना (लेखन की प्रक्रिया में)