एथेरियम स्मार्ट कॉन्ट्रैक्ट्स में कमजोरियां। कोड उदाहरण

इस पोस्ट के साथ, मैं Ethereum स्मार्ट कॉन्ट्रैक्ट्स की सुरक्षा पर लेखों की एक श्रृंखला शुरू करता हूं। मुझे लगता है कि यह विषय बहुत प्रासंगिक है, क्योंकि डेवलपर्स की संख्या हिमस्खलन की तरह बढ़ रही है, और "नकली" से बचाने के लिए कोई नहीं है। अलविदा - अनुवाद ...

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

मूल - "अनियंत्रित-भेजें ..." के लिए लाइव एथेरेम कॉन्ट्रैक्ट को स्कैन करना

लेखक: ज़िकई एलेक्स वेन और एंड्रयू मिलर

Ethereum स्मार्ट कॉन्ट्रैक्ट प्रोग्रामिंग को त्रुटि प्रवण [1] कहा जाता है । हाल ही में, हमने देखा कि कई
हाई-एंड स्मार्ट कॉन्ट्रैक्ट जैसे कि किंग ऑफ द ईथर और द डीएओ-1.0 में प्रोग्रामिंग त्रुटियों के कारण कमजोरियां थीं।

मार्च 2015 के बाद से, स्मार्ट कॉन्ट्रैक्ट प्रोग्रामर्स को विशिष्ट प्रोग्रामिंग खतरों से आगाह किया गया है, जो तब हो सकते हैं जब कॉन्ट्रैक्ट एक दूसरे को संदेश भेजते हैं [6] ।

कई प्रोग्रामिंग गाइड सलाह देते हैं कि सामान्य गलतियों से कैसे बचें (श्वेत पत्र Ethereum [3] में और UMD [2] से एक स्वतंत्र गाइड में)। यद्यपि ये खतरे उन्हें समझने के लिए पर्याप्त हैं, लेकिन ऐसी गलती के परिणाम भयानक हैं: पैसा अवरुद्ध, खो या चोरी हो सकता है।

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

अनियंत्रित-भेज त्रुटि क्या है?

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

/*** Listing 1 ***/ if (gameHasEnded && !( prizePaidOut ) ) { winner.send(1000); //    prizePaidOut = True; } 

यहां समस्या यह है कि भेजने का तरीका विफल हो सकता है। यदि यह काम नहीं करता है, तो विजेता को धन प्राप्त नहीं होगा, हालांकि चर पुरस्कारपद भुगतान सही पर सेट किया जाएगा।

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

इस त्रुटि से कैसे बचा जा सकता है?

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

दो वाक्य। यह देखने के लिए कि क्या इसे सफलतापूर्वक पूरा किया गया है, पहले रिटर्न के मूल्य की जांच करें। यदि यह मामला नहीं है, तो राज्य को वापस रोल करने के लिए एक अपवाद फेंक दें।

  /*** Listing 2 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (winner.send(1000)) prizePaidOut = True; else throw; } 

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

 /*** Listing 3 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (winner.send(1000) && loser.send(10)) prizePaidOut = True; else throw; } 

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

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

 /*** Listing 4 ***/ if (gameHasEnded && !( prizePaidOut ) ) { if (callStackIsEmpty()) throw; winner.send(1000) loser.send(10) prizePaidOut = True; } 

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

 /*** Listing 5 ***/ if (gameHasEnded && !( prizePaidOut ) ) { accounts[winner] += 1000 accounts[loser] += 10 prizePaidOut = True; } ... function withdraw(amount) { if (accounts[msg.sender] >= amount) { msg.sender.send(amount); accounts[msg.sender] -= amount; } } 

कई उच्च विकसित स्मार्ट अनुबंध कमजोर हैं। सिंहासन लॉटरी का राजा इस गलती का सबसे प्रसिद्ध मामला है [4] । यह त्रुटि तब तक नहीं देखी गई जब तक कि 200 ईथर (आज की कीमत में 2000 अमेरिकी डॉलर से अधिक) की राशि को लॉटरी का वैध विजेता नहीं मिला। किंग ऑफ द एथर में संबंधित कोड लिस्टिंग 2. में कोड के समान है। सौभाग्य से, इस मामले में, अनुबंध डेवलपर अटके हुए फ़ंक्शन को "मैनुअल ओवरराइड" के रूप में अटका हुआ धन जारी करने के लिए उपयोग करने में सक्षम था। प्रसारण को चुराने के लिए एक कम निपुण प्रशासक एक ही कार्य का उपयोग कर सकता है!

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