अनियंत्रित-भेजें त्रुटि के लिए लाइव Ethereum संविदा स्कैनिंग। भाग २

"अनियंत्रित-भेजें त्रुटि के लिए लाइव Ethereum संविदा स्कैनिंग" लेख की निरंतरता । भाग 1 ” ।

लगभग एक साल पहले (जब Ethereum अपने "फ्रंटियर" रिलीज़ में था), लोकप्रिय EtherPot लॉटरी अनुबंध [9] भी उसी त्रुटि से पीड़ित था। BTCRelay के एक पुराने संस्करण ने भी यह त्रुटि दिखाई [7] । हालांकि पिछले सुरक्षा ऑडिट में एक खतरे का पता लगाया गया था, एक गलत सुधार पहली बार लागू किया गया था [8] ।

लाइव ब्लॉकहिन पर अनियंत्रित-भेज त्रुटि का पता लगाने

ये त्रुटियाँ कितनी सामान्य हैं? क्या वे चेतावनी सुनते हैं? क्या सर्वोत्तम प्रथाओं को लागू किया जाता है? हम इथेरियम ब्लॉक-चेन, साथ ही etherscrape.com पर पाए गए सॉलिडिटी कोड रिपॉजिटरी से डेटा का विश्लेषण करके इन सवालों का अनुभवजन्य उत्तर देते हैं। ऐसा करने के लिए, हम एक सरल प्रोग्राम विश्लेषण उपकरण विकसित कर रहे हैं जो ब्लॉक-चेन अनुबंध की जांच करता है और यह देखने के लिए कि क्या सबसे प्रभावी सुरक्षा विधियों में से एक का उपयोग किया जाता है, यह जांचने के लिए उपयोग करता है। सूची 2 पहले सुरक्षा तकनीक को दर्शाता है, जैसा कि एथेरियम प्रलेखन में अनुशंसित है, जो एक अपवाद भेजने और फेंकने के रिटर्न मूल्य की जांच करना चाहिए। इस पद्धति के उपयोग का पता लगाने के लिए, हम एक कच्चे सन्निकटन का उपयोग करते हैं: हम सिर्फ यह देखते हैं कि भेजने के वापसी मूल्य को अनदेखा किया गया है या नहीं।

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

यदि इनमें से कोई भी हेयुरिस्टिक संकेतक मौजूद नहीं है, तो हम निष्कर्ष निकालते हैं कि सर्वोत्तम अभ्यास सिफारिशों में से एक का पालन नहीं किया जा रहा है। हम संकलित EVM बाइटकोड के साथ मेल खाते साधारण पैटर्न का उपयोग करके इन अनुमानों को लागू करते हैं। हम यह कैसे करते हैं, इस बारे में अधिक जानकारी परिशिष्ट [12] में मिल सकती है।

कितने अनुबंध असुरक्षित हैं?

आइए सॉलिडिटी सोर्स कोड के इथरस्क्रा रिपॉजिटरी में हेयुरिस्टिक की जांच करके शुरू करें। 20 मार्च 2016 तक, इथरस्क्रे रिले में 361 सॉलिडिटी कॉन्ट्रैक्ट प्रोग्राम थे, जिनमें से 56 में एक स्टेटमेंट था। इन अनुबंध कार्यक्रमों में से, हम मानते हैं कि अधिकांश (कम से कम 36 में से 56) किसी भी रक्षात्मक प्रोग्रामिंग विधियों का उपयोग नहीं करते हैं।

भले ही अनुबंध किसी भी सुरक्षात्मक तकनीकों का उपयोग नहीं करता है, लेकिन इसमें वास्तविक भेद्यता हो सकती है या नहीं। भेद्यता की पुष्टि करने के लिए हमने मैन्युअल रूप से सॉलिडिटी कॉन्ट्रैक्ट्स की जाँच की। हमारे उद्देश्यों के लिए, हम एक अनुबंध को कमजोर मानते हैं यदि इसकी स्थिति बदल सकती है भले ही भेजें कमांड काम न करे (इसलिए हम लिस्टिंग 5 में असुरक्षित कोड को देखेंगे)। हमने पुष्टि की कि अधिकांश कमजोरियां मौजूद हैं, इनमें से 32 में से 32 अनुबंध हैं।

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

function refund(uint _campaignID, uint contributionID) public { ... receiver.send(donation.amountContributed); donation.refunded = true; ... if(c.config != address(0)) WeiFundConfig(c.config).refund(_campaignID, donation.contributor, donation.amountContributed); } 

इस कोड में, रिफंड विधि को लागू करने के लिए एक संदेश वीफंडकोन्फिग (c.config) को भेजा जाता है, लेकिन केवल कुछ शर्तों के तहत। यदि c.config एक शून्य मान है, तो अनुबंध वास्तव में कॉलस्टैक हमले के लिए असुरक्षित है। * जाँच करते समय, हमारे न्यायिक परीक्षण को पारित करने वाले सॉलिडिटी कार्यक्रमों में से कोई भी वास्तव में अनुशंसित सर्वोत्तम कॉलस्टैक परीक्षण अभ्यास को सीधे लागू नहीं करता है। *

फिर हम अपना ध्यान जीवित ब्लॉक-चेन एथेरियम पर तैयार किए गए अनुबंधों की ओर देते हैं। हमने दिनांक २० मार्च, २०१६ को छवि देखी (समय टिकट: ११3४२४३)। इस स्नैपशॉट में कुल 13645 ब्लॉक चेन हैं, जो जाहिरा तौर पर सॉलिडिटी कंपाइलर द्वारा उत्पन्न की जाती हैं, जिनमें से केवल 1618 (11.8%) में सेंड कमांड शामिल है।

इनमें से, विशाल बहुमत किसी भी रक्षात्मक प्रोग्रामिंग तकनीकों का उपयोग नहीं करता है।

TheDAO में पुनरावर्ती दौड़ समस्या के बारे में क्या? इन दिनों सबसे रोमांचक स्मार्ट अनुबंध, TheDAO [11] , एक पूरी तरह से अलग त्रुटि से ग्रस्त है, जो यह है कि यह "पुन: उपयोग के लिए सुरक्षित नहीं है" [13] । यह असुरक्षित प्रोग्रामिंग का एक और (जुड़ा हुआ, लेकिन विशिष्ट) प्रकार है, जो पिछली सुरक्षा जांच [6] में भी अपेक्षित था, लेकिन, पहले की तरह, यह संभावना है कि आज कई अनुबंध असुरक्षित हैं। भविष्य का काम एक ऐसा उपकरण बनाना था जो इस तरह की त्रुटि का भी पता लगा सके।

यह सब कहां गलत हुआ?

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

2015 की एक रिपोर्ट [6] ने Ethereum डेवलपर्स के लिए यह सिफारिश की: "

वर्तमान में, प्रलेखन में प्रस्तुत प्रोग्रामिंग उदाहरण सुरक्षित अनुबंध लिखने और गैस तंत्र समस्या को हल करने के लिए सर्वोत्तम प्रथाओं का प्रसार करने के लिए अपर्याप्त हैं। C ++ परिचयात्मक ट्यूटोरियल अक्सर छोड़ देते हैं
पठनीयता के लिए त्रुटि जाँच, जिसके कारण कई सुरक्षा त्रुटियां हुईं। एथेरियम के उदाहरणों में सबसे अच्छी आदतें सिखाई जानी चाहिए। अनुशंसा: सुरक्षा अनुबंधों की सावधानीपूर्वक प्रोग्रामिंग के और भी अधिक उदाहरण प्रदान करें। "

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

हमारा मानना ​​है कि यह अवलोकन समस्या का दस्तावेजीकरण करने के लिए पर्याप्त नहीं है। यह केवल अपूर्ण शमन प्रदान करता है और खतरे के केवल एक संस्करण का वर्णन करता है, संभवतः इसकी डिग्री के बारे में पाठक को भ्रमित करता है।

• अद्यतन:
  सॉलिडिटी डॉक्यूमेंटेशन की अपर्याप्तता को पीटर वेसेन्स द्वारा विस्तार से चित्रित किया गया था। [16]

  
  

इसके अलावा, चेतावनी को अक्सर नजरअंदाज कर दिया जाता है। इसलिए, हम मानते हैं कि अतिरिक्त निवारक उपाय आवश्यक हैं।

Etherscrape कैसे मदद कर सकता है?

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

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

अनुशंसित पढ़ना

• [१] चरण-दर-चरण एक सुरक्षित स्मार्ट अनुबंध बनाना
  
• [२] UMD प्रोग्रामर गाइड टू एथेरम एंड सर्प (धारा ५.१४)
  
• [३] आधिकारिक एथेरियम सॉलिडिटी डॉक्स
  
• [४] इथर के राजा: पोस्टमार्टम जांच
  
• [५] कॉन्ट्रैक्ट सिक्योरिटी पर स्वेंडे
  
• [६] एथेरियम का कम से कम प्राधिकरण ऑडिट
  
• [ Rel ] बीटीसी रिले ऑडिट १
  
• [ Rel ] बीटीसी रिले ऑडिट २
  
• [९] इथरपॉट सिक्योरिटी बग रिपोर्ट
  
• [१०] रेंटेंट कॉन्ट्रैक्ट्स
  
• [११] डीएओ (विकेंद्रीकृत स्वायत्त संगठन)
  
• [१२] परिशिष्ट ए: हम ब्लॉकचेन का विश्लेषण कैसे करते हैं, इस पर विवरण
  
• [१३] डीएओ पर एक अस्थायी अधिस्थगन के लिए एक कॉल
  
• [१४] परिशिष्ट बी: कमजोर ठोस संविदा
  
• [१५] परिशिष्ट C: कमजोर ब्लॉकचेन संविदा
  
• [१६] एथेरियम ग्रोइंग
  वॉलेट: सेंड w / थ्रो इज़ डेंजरस