if-forget/cve-2026-52134-libiec61850libiec61850 v1.6 में GOOSE रीप्ले हैंडलिंग को प्रभावित करने वाले CVE-2026-52134 के लिए सार्वजनिक तकनीकी एडवाइज़री और पुनरुत्पादन साक्ष्य।
CVE-2026-52134 असाइन किया जा चुका है। संबंधित CVE रिकॉर्ड का प्रकाशन लंबित है।
src/goose/goose_receiver.cparseGoosePayload()libiec61850 v1.6 में GOOSE सब्सक्राइबर रिसीव पथ, सब्सक्राइबर-दृश्यमान स्थिति को अपडेट करने और पंजीकृत लिसनर कॉलबैक को आमंत्रित करने से पहले कुछ रीप्ले किए गए या पुराने (stale) GOOSE संदेशों को पर्याप्त रूप से अस्वीकार नहीं करता है।
दो नियंत्रित प्रयोग उसी रिसीव पथ में संबंधित व्यवहार प्रदर्शित करते हैं:
stNum रोलबैक: सब्सक्राइबर द्वारा stNum=2 प्रोसेस करने के बाद, पहले कैप्चर किए गए फ्रेम को रीप्ले करने से लिसनर ने पुरानी स्थिति और डेटा फिर से रिपोर्ट किया।stNum=1sqNum रीप्ले: जब समान stNum लेकिन पुराने sqNum वाला पहले कैप्चर किया गया फ्रेम रीप्ले किया गया, तो फ्रेम को अमान्य चिह्नित किया गया, लेकिन लिसनर कॉलबैक फिर भी हुए और रीप्ले किया गया डेटा दृश्यमान रहा।इन्हें दो अलग-अलग CVE के रूप में नहीं, बल्कि एक ही रीप्ले/संदेश-ताज़गी हैंडलिंग समस्या की दो संबंधित टिप्पणियों के रूप में प्रस्तुत किया गया है।
एक हमलावर को निम्न में सक्षम होना चाहिए:
0x88B8 का उपयोग करके ईथरनेट फ्रेम इंजेक्ट करनायह कोई मनमाना इंटरनेट-आधारित रिमोट हमला नहीं है।
प्रासंगिक रिसीव लॉजिक sqNum की जाँच तब करता है जब प्राप्त stNum संग्रहीत stNum के बराबर होता है। परीक्षित कोड पथ, सब्सक्राइबर स्थिति अपडेट होने और लिसनर आमंत्रित होने से पहले किसी निचले stNum को अस्वीकार नहीं करता है।
परीक्षित लाइब्रेरी फ़ाइल को संशोधित नहीं किया गया था। src/goose/goose_receiver.c की मूल और कार्यशील प्रतियों का SHA-256 मान समान था:
c42f2aec80f605c458d0bca524ccb09f2e35f9b83a02f854f95d9444616c075b
veth0 / veth1 पृथक वर्चुअल ईथरनेट जोड़ीtcpdumpपरीक्षण हार्नेस ने नियंत्रित स्थिति संक्रमण उत्पन्न किए और कॉलबैक-दृश्यमान stNum, sqNum, वैधता और डेटा मान मुद्रित किए। कमजोर लाइब्रेरी फ़ाइल को स्वयं संशोधित नहीं किया गया था।
नियंत्रित पब्लिशर ने दो स्थितियाँ भेजीं:
State A: stNum=1, sqNum=0, data=1111
State B: stNum=2, sqNum=0, data=2222
आधार रेखा पैकेट कैप्चर में इस क्रम में दो GOOSE फ्रेम शामिल थे:
Frame 1: stNum=1, sqNum=0
Frame 2: stNum=2, sqNum=0
सब्सक्राइबर आउटपुट में State B से पहले valid=false चिह्नित stNum=1, sqNum=0 के लिए एक सहायक कॉलबैक भी शामिल था। यह सहायक कॉलबैक साक्ष्य में बरकरार रखा गया है, लेकिन रोलबैक निष्कर्ष के आधार के रूप में उपयोग नहीं किया गया है। निर्णायक प्री-रीप्ले स्थिति stNum=2 और डेटा मान 2222 वाला बाद वाला कॉलबैक था।
रीप्ले स्क्रिप्ट ने दो-फ्रेम आधार रेखा कैप्चर लोड किया, फ्रेम 1 का चयन किया, और उसे veth0 के माध्यम से एक बार भेजा।
रीप्ले से ठीक पहले, लिसनर ने रिपोर्ट किया था:
stNum=2, sqNum=0, valid=true, allData={2222}
पुराने फ्रेम को एक बार रीप्ले करने के बाद, लिसनर ने रिपोर्ट किया:
stNum=1, sqNum=0, valid=true, allData={1111}
यह पहले कैप्चर किए गए निचले-stNum फ्रेम को रीप्ले करने के बाद stNum=2 से stNum=1 तक देखे गए सब्सक्राइबर-स्थिति रोलबैक को प्रदर्शित करता है।
उसी पुराने फ्रेम की चार और प्रतियाँ भेजी गईं। सभी चार में stNum=1, sqNum=0 था।
बाद की प्रतियाँ valid=false के रूप में रिपोर्ट की गईं, लेकिन कॉलबैक संख्याएँ बढ़ती रहीं और रीप्ले किया गया डेटा दृश्यमान रहा:
यह द्वितीयक अवलोकन दर्शाता है कि दोहराए गए फ्रेम को अमान्य चिह्नित करने से परीक्षित रिसीव पथ में लिसनर डिलीवरी नहीं रुकी।
एक पहले पुनरुत्पादन में आधिकारिक उदाहरण पब्लिशर और सब्सक्राइबर का उपयोग किया गया था। पब्लिशर ने निम्न के साथ एक सामान्य अनुक्रम उत्पन्न किया:
stNum=1
sqNum=0, 1, 2, 3
फिर पहला कैप्चर किया गया फ्रेम (stNum=1, sqNum=0) तब रीप्ले किया गया जब सब्सक्राइबर पहले ही बाद के अनुक्रम मान को प्रोसेस कर चुका था।
रीप्ले की गई प्रतियाँ अमान्य रिपोर्ट की गईं क्योंकि प्राप्त sqNum=0 संग्रहीत अनुक्रम मान से नया नहीं था। हालाँकि, सब्सक्राइबर रीप्ले किए गए डेटा वाली लिसनर घटनाओं को प्रिंट करता रहा:
यह प्रयोग एक संकीर्ण लेकिन संबंधित अवलोकन का समर्थन करता है:
मूल रीप्ले स्क्रीनशॉट सहायक सामग्री के रूप में बरकरार रखे गए हैं:
उन कच्ची छवियों में असंबंधित Scapy वैकल्पिक-मॉड्यूल आयात चेतावनियाँ हैं। चेतावनियों ने स्क्रिप्ट को कैप्चर किए गए GOOSE फ्रेम रिपोर्ट करने और ट्रांसमिशन पूरा करने से नहीं रोका, लेकिन तकनीकी परिणाम की समीक्षा के लिए ऊपर के स्पष्ट स्क्रीनशॉट बेहतर हैं।
प्रयोग उसी GOOSE रीप्ले/संदेश-ताज़गी समस्या की विभिन्न शाखाओं को प्रदर्शित करते हैं:
| अवलोकन | प्राप्त संदेश | देखा गया परिणाम |
|---|---|---|
निचला-stNum रीप्ले | संग्रहीत stNum=2; प्राप्त पुराना stNum=1 | परीक्षित रन में पुरानी स्थिति और डेटा लिसनर को दिए गए और वैध के रूप में रिपोर्ट किए गए |
गैर-बढ़ता sqNum रीप्ले | समान stNum; प्राप्त पुराना या डुप्लिकेट sqNum | संदेश अमान्य रिपोर्ट किया गया, लेकिन लिसनर कॉलबैक और रीप्ले किए गए डेटा की डिलीवरी जारी रही |
पहला अवलोकन प्राथमिक CVE निष्कर्ष है क्योंकि यह नई स्थिति से पुरानी स्थिति में रोलबैक प्रदर्शित करता है। दूसरा अवलोकन इस बारे में सहायक साक्ष्य है कि अमान्य समान-स्थिति रीप्ले लिसनर पथ से कैसे गुजरते रहते हैं।
प्रदर्शित सॉफ़्टवेयर-स्तरीय प्रभाव है:
stNum से पुराने stNum में जा सकती है।जो एप्लिकेशन स्वतंत्र ताज़गी प्रवर्तन के बिना कॉलबैक डेटा का उपभोग करते हैं, वे पुराने या रीप्ले किए गए मानों को प्रोसेस कर सकते हैं।
डाउनस्ट्रीम प्रभाव सब्सक्राइबर एप्लिकेशन, कॉन्फ़िगरेशन, इंटरलॉकिंग लॉजिक और सुरक्षा लॉजिक पर निर्भर करता है।
इन प्रयोगों में किसी भौतिक सुरक्षा रिले, ट्रिप सर्किट, सर्किट ब्रेकर या उत्पादन सबस्टेशन नेटवर्क का परीक्षण या संचालन नहीं किया गया।
सब्सक्राइबर स्थिति अपडेट करने या लिसनर को आमंत्रित करने से पहले:
stNum अस्वीकार करें जो अंतिम स्वीकृत stNum से पुराना हो।stNum अपरिवर्तित हो, तो गैर-बढ़ते sqNum को अस्वीकार करें।stNum रोलबैक और बार-बार आने वाले sqNum मानों की निगरानी करें।निम्नलिखित छवियाँ उत्पत्ति और पर्यावरण संबंधी जानकारी प्रदान करती हैं। वे पुनरुत्पादन का समर्थन करती हैं, लेकिन मुख्य परिणाम को समझने के लिए व्यक्तिगत रूप से आवश्यक नहीं हैं।
प्रदर्शित परिणाम रीप्ले स्वीकृति और पुरानी-स्थिति डिलीवरी है। यह इस बात पर निर्भर नहीं करता कि परीक्षित तैनाती में क्रिप्टोग्राफिक प्रमाणीकरण सक्षम था या नहीं।
रिपोर्टकर्ता: