लाइटनिंग बग का शोषण करना नैतिक विकल्प था

यह शिनोबी का एक राय संपादकीय है, जो बिटकॉइन स्पेस में एक स्व-सिखाया शिक्षक और तकनीक-उन्मुख बिटकॉइन पॉडकास्ट होस्ट है।

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

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

यह वास्तव में इस बिंदु को घर ले जाता है कि कोड का कोई भी टुकड़ा जिसका उद्देश्य बिटकॉइन डेटा को पार्स और मान्य करना है, उसे यह सुनिश्चित करने के लिए भारी ऑडिट किया जाना चाहिए कि यह बिटकॉइन कोर क्या करेगा इसके अनुरूप है। इससे कोई फर्क नहीं पड़ता कि वह कोड नोड कार्यान्वयन के लिए सर्वसम्मति इंजन है या लाइटनिंग नोड के लिए कोड पासिंग लेनदेन का एक टुकड़ा है। यह दूसरा बग था सचमुच पिछले महीने से ठीक ऊपर कोडबेस में. इसकी खोज लाइटनिंग लैब्स में किसी ने भी नहीं की थी। बुरक के 11-में-998 मल्टीसिग लेनदेन द्वारा मूल बग ट्रिगर होने के दो दिन बाद, एजे टाउन्स ने 999 अक्टूबर को इसकी सूचना दी। इसे हटाए जाने से पहले 10 घंटे के लिए जीथब पर सार्वजनिक रूप से पोस्ट किया गया था। फिर एलएनडी की अगली रिलीज में समस्या को चुपचाप ठीक करने के इरादे से एक सुधार किया गया, लेकिन जारी नहीं किया गया।

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

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

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

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

जब बिटकॉइन पर लेयर 2 सॉफ़्टवेयर में इस तरह की कमजोरियों की बात आती है तो यह कुछ बड़े मुद्दे सामने लाता है। सबसे पहले, सुरक्षा बग के लिए इन कोडबेस का ऑडिट कितनी गंभीरता से किया जाता है और नई सुविधाओं के एकीकरण की तुलना में इसे कैसे प्राथमिकता दी जाती है। मुझे लगता है कि यह बहुत स्पष्ट है कि सुरक्षा को हमेशा प्राथमिकता नहीं दी जाती है, क्योंकि यह दूसरा बग उस कोडबेस के अनुरक्षकों द्वारा भी नहीं पाया गया था जहां यह मौजूद था, भले ही यह वस्तुतः पिछले महीने खोजे गए प्रारंभिक बग के ठीक बगल में था। उपयोगकर्ताओं के धन को जोखिम में डालने वाले एक बड़े बग के बाद, क्या उस कोडबेस का कोई आंतरिक ऑडिट नहीं किया गया था? इसे खोजने के लिए प्रोजेक्ट के बाहर से किसी को लेना पड़ा? यह अधिक उपयोगकर्ताओं को आकर्षित करने के लिए नई सुविधाओं के निर्माण की तुलना में उपयोगकर्ताओं के धन की सुरक्षा को प्राथमिकता नहीं दर्शाता है। दूसरा, यह तथ्य कि यह समस्या पहले से ही रस्ट बिटकॉइन में पैच कर दी गई थी, इस तरह के बग के संबंध में विभिन्न कोडबेस के अनुरक्षकों के बीच संचार की कमी को दर्शाता है। यह काफी समझ में आने योग्य है, क्योंकि पूरी तरह से अलग कोडबेस होने से कोई भी व्यक्ति जिसे एक में बग मिला हो, वह तुरंत यह नहीं सोचता है, "मुझे पूरी तरह से अलग प्रोग्रामिंग भाषाओं में समान सॉफ़्टवेयर लिखने वाली अन्य टीमों से संपर्क करना चाहिए ताकि उन्हें इस तरह के बग की संभावना के बारे में चेतावनी दी जा सके।" आपको विंडोज़ में कोई बग नहीं मिलता है और आप तुरंत लिनक्स कर्नेल अनुरक्षकों को बग की रिपोर्ट करने के बारे में सोचते हैं। हालाँकि, वैश्विक नेटवर्क पर वितरित आम सहमति के लिए एक प्रोटोकॉल के रूप में बिटकॉइन एक बहुत अलग जानवर है; जब बिटकॉइन सॉफ्टवेयर में कमजोरियों की बात आती है तो शायद बिटकॉइन डेवलपर्स को इसी तरह से सोचना शुरू करना चाहिए। विशेष रूप से जब सर्वसम्मति से संबंधित डेटा को पार्स करने और व्याख्या करने की बात आती है।

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

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

डेवलपर्स और उपयोगकर्ताओं को इस तरह की घटनाओं को दोबारा होने से रोकने के लिए प्रक्रियाओं में सुधार करने पर ध्यान केंद्रित करना चाहिए, न कि गर्म आलू की तरह दोषारोपण का खेल खेलना चाहिए।

यह शिनोबी की अतिथि पोस्ट है। व्यक्त की गई राय पूरी तरह से उनकी अपनी हैं और जरूरी नहीं कि वे बीटीसी इंक या बिटकॉइन पत्रिका को प्रतिबिंबित करें।