TL;DR
- Teku 26.10.3 और Besu 26.10.2 ने ईमुध्रा-संबंधित प्रमाणपत्र जड़ों के लिए विश्वास हटा दिया है, क्योंकि दुर्भावनापूर्ण मध्यवर्ती कुंजियों के प्रकट होने से कुछ HTTPS-आधारित वैलिडेटर कॉन्फ़िगरेशन अपरूपण के जोखिम में आ गए हैं।
- डिफ़ॉल्ट Teku मेननेट नोड्स अप्रभावित रहे, और कोई दुरुपयोग की रिपोर्ट नहीं की गई है, जबकि जोखिम HTTPS के माध्यम से बाहरी सेवाओं से जुड़ने वाले वैलिडेटर्स पर निर्भर करता था।
- डॉकर उपयोगकर्ताओं को क्लाइंट इमेजेस अपडेट करने चाहिए, जबकि स्टैंडअलोन ऑपरेटर्स को अलग से जावा को पैच करना होगा; जावा 26 उपयोगकर्ताओं को समर्थित जावा 25 बिल्ड्स पर स्थानांतरित करना होगा।
Teku और Besu ने सुरक्षा अपडेट जारी किए, जिसके परिणामस्वरूप eMudhra सर्टिफिकेट-अथॉरिटी की कुंजियाँ दुरुपयोग के कारण ईथेरियम नोड कॉन्फ़िगरेशन झूठे HTTPS कनेक्शन के लिए उजागर हो गए। Teku के रिलीज़ नोट्स 26.10.3 संस्करण की सिफारिश करते हैं, जो डॉकर इमेज से चार प्रभावित सर्टिफिकेट रूट्स के लिए विश्वास हटा देता है, जबकि Besu ने 26.10.2 संस्करण जारी किया। ये अपडेट ईथेरियम के समझौता नियमों में कोई खामी के बजाय सॉफ्टवेयर-वितरण स्तर पर सर्टिफिकेट विश्वास को संबोधित करते हैं। डिफ़ॉल्ट Teku मेननेट नोड प्रभावित नहीं हुए, जिससे घटना Ethereum प्रोटोकॉल में वल्नरेबिलिटी से अलग रही।
सुरक्षित प्रमाणपत्र कुंजियों के दुरुपयोग से छल का खतरा उत्पन्न हुआ
शोधकर्ताओं ने पाया कि आठ eMudhra इंटरमीडिएट सर्टिफिकेट प्राधिकरणों के निजी कुंजियाँ अपर्याप्त यादृच्छिकता के कारण पुनः प्राप्त की जा सकती हैं। हालाँकि सर्टिफिकेटों को रद्द कर दिया गया था, लेकिन जावा डिफ़ॉल्ट रूप से पुनर्कृति की जाँच नहीं करता है, जिससे रनटाइम झूठे सर्टिफिकेट स्वीकार करने में सक्षम होते हैं। इसलिए, एक हमलावर जो एक नोड और एक HTTPS सेवा के बीच स्थित हो, तो कमजोर कॉन्फ़िगरेशन के अंतर्गत उस एंडपॉइंट का अपना प्रतिनिधित्व कर सकता है। यह घटना यह स्पष्ट करती है कि Ethereum client diversity and operational security समझौता कोड से परे क्यों विस्तारित है।

सबसे अधिक जोखिम वाले परिदृश्यों में वैलिडेटर्स HTTPS के माध्यम से बाहरी सेवाओं से जुड़ना शामिल था। एक झूठी एंडपॉइंट ब्लॉक-बिल्डिंग जानकारी को बदल सकती थी, शुल्क प्राप्तकर्ताओं को पुनः निर्देशित कर सकती थी, या एक अवैध बाहरी साइनर के माध्यम से हस्ताक्षर प्राप्त कर सकती थी। टेकू ने कहा कि एक हमलावर एक दूरस्थ बीकन नोड का उपयोग करने वाले वैलिडेटर क्लाइंट को ऐसा ब्लॉक प्रस्तावित करने के लिए प्रेरित कर सकता है जिसमें शुल्क हमलावर के पते पर भेजे जाते हैं। जोखिम नेटवर्क स्थिति और दूरस्थ-सेवा कॉन्फ़िगरेशन पर निर्भर करता था, केवल टेकू या बेसू चलाने पर नहीं। कोई दुरुपयोग की रिपोर्ट नहीं की गई है।
Teku 26.10.3 Docker इमेज में emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 और AAA Certificate Services के लिए विश्वास हटा देता है। Besu का अपडेट इसी दृष्टिकोण को लागू करता है। जो ऑपरेटर सीधे बाइनरी चला रहे हैं, उन्हें Java को अलग से अपडेट करना होगा क्योंकि क्लाइंट अपग्रेड होस्ट रनटाइम के सर्टिफिकेट स्टोर को प्रतिस्थापित नहीं करते हैं। इसलिए, Docker और स्टैंडअलोन डिप्लॉयमेंट के लिए अलग-अलग उपचार रास्ते की आवश्यकता होती है। Ethereum validator इंफ्रास्ट्रक्चर घटनाओं के बाद यह अंतर महत्वपूर्ण हो गया है, जिसने दिखाया कि प्रोटोकॉल के बाहर की निर्भरताएँ स्टेकिंग संचालन को कैसे प्रभावित कर सकती हैं।
Java 26 एक जटिलता पैदा करता है क्योंकि इसका जीवनकाल समाप्त हो चुका है और इसे आवश्यक पैच वाला बिल्ड नहीं मिलेगा, जिसका अर्थ है कि प्रभावित संचालकों को Java 25 पर स्थानांतरित होना होगा। पीयर-टू-पीयर ईथेरियम नेटवर्किंग को प्रकट नहीं किया गया क्योंकि यह इन सर्टिफिकेट अथॉरिटीज़ पर निर्भर नहीं करती है। सुधार एक तीसरे पक्ष के ट्रस्ट-स्टोर जोखिम को कम करते हैं बिना किसी लाइव मेननेट दुरुपयोग को ठीक किए या ईथेरियम के प्रोटोकॉल में कोई बदलाव किए। यह घटना अन्य सुरक्षा कार्यों, जिसमें Glamsterdam डिपॉज़िट-रूटिंग सुधार शामिल है, के साथ आती है, जो यह स्पष्ट करती है कि वैलिडेटर सुरक्षा प्रोटोकॉल कोड और समर्थन बुनियादी ढांचे पर कैसे निर्भर करती है।





