CVE-2026-52134: libiec61850 v1.6 में GOOSE रीप्ले और संदेश-ताज़गी हैंडलिंग

स्थिति

CVE-2026-52134 असाइन किया जा चुका है। संबंधित CVE रिकॉर्ड का प्रकाशन लंबित है।

प्रभावित उत्पाद

• विक्रेता: MZ Automation GmbH
• उत्पाद: libiec61850
• परीक्षित संस्करण: 1.6
• अन्य संस्करणों की स्थिति: पुष्टि नहीं
• प्रभावित फ़ाइल: src/goose/goose_receiver.c
• प्रभावित फ़ंक्शन: parseGoosePayload()

सारांश

libiec61850 v1.6 में GOOSE सब्सक्राइबर रिसीव पथ, सब्सक्राइबर-दृश्यमान स्थिति को अपडेट करने और पंजीकृत लिसनर कॉलबैक को आमंत्रित करने से पहले कुछ रीप्ले किए गए या पुराने (stale) GOOSE संदेशों को पर्याप्त रूप से अस्वीकार नहीं करता है।

दो नियंत्रित प्रयोग उसी रिसीव पथ में संबंधित व्यवहार प्रदर्शित करते हैं:

1. निचला-stNum रोलबैक: सब्सक्राइबर द्वारा stNum=2 प्रोसेस करने के बाद, पहले कैप्चर किए गए stNum=1 फ्रेम को रीप्ले करने से लिसनर ने पुरानी स्थिति और डेटा फिर से रिपोर्ट किया।
2. गैर-बढ़ता sqNum रीप्ले: जब समान stNum लेकिन पुराने sqNum वाला पहले कैप्चर किया गया फ्रेम रीप्ले किया गया, तो फ्रेम को अमान्य चिह्नित किया गया, लेकिन लिसनर कॉलबैक फिर भी हुए और रीप्ले किया गया डेटा दृश्यमान रहा।

इन्हें दो अलग-अलग CVE के रूप में नहीं, बल्कि एक ही रीप्ले/संदेश-ताज़गी हैंडलिंग समस्या की दो संबंधित टिप्पणियों के रूप में प्रस्तुत किया गया है।

हमले की पूर्वापेक्षाएँ

एक हमलावर को निम्न में सक्षम होना चाहिए:

• प्रासंगिक IEEE 802.3 लेयर-2 ब्रॉडकास्ट डोमेन या VLAN तक पहुँच प्राप्त करना
• वैध GOOSE ईथरनेट फ्रेम कैप्चर करना
• EtherType 0x88B8 का उपयोग करके ईथरनेट फ्रेम इंजेक्ट करना

यह कोई मनमाना इंटरनेट-आधारित रिमोट हमला नहीं है।

तकनीकी आधार

प्रासंगिक रिसीव लॉजिक sqNum की जाँच तब करता है जब प्राप्त stNum संग्रहीत stNum के बराबर होता है। परीक्षित कोड पथ, सब्सक्राइबर स्थिति अपडेट होने और लिसनर आमंत्रित होने से पहले किसी निचले stNum को अस्वीकार नहीं करता है।

परीक्षित लाइब्रेरी फ़ाइल को संशोधित नहीं किया गया था। src/goose/goose_receiver.c की मूल और कार्यशील प्रतियों का SHA-256 मान समान था:

c42f2aec80f605c458d0bca524ccb09f2e35f9b83a02f854f95d9444616c075b

परीक्षण वातावरण

• Ubuntu 20.04.6 LTS
• libiec61850 v1.6
• Linux veth0 / veth1 पृथक वर्चुअल ईथरनेट जोड़ी
• tcpdump
• TShark
• Python 3 और Scapy
• केवल परीक्षण हार्नेस के रूप में उपयोग किए गए संशोधित उदाहरण पब्लिशर और सब्सक्राइबर

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

प्रयोग A: निचला-stNum रोलबैक

आधार रेखा

नियंत्रित पब्लिशर ने दो स्थितियाँ भेजीं:

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 के रूप में रिपोर्ट की गईं, लेकिन कॉलबैक संख्याएँ बढ़ती रहीं और रीप्ले किया गया डेटा दृश्यमान रहा:

यह द्वितीयक अवलोकन दर्शाता है कि दोहराए गए फ्रेम को अमान्य चिह्नित करने से परीक्षित रिसीव पथ में लिसनर डिलीवरी नहीं रुकी।

प्रयोग B: गैर-बढ़ता sqNum रीप्ले

एक पहले पुनरुत्पादन में आधिकारिक उदाहरण पब्लिशर और सब्सक्राइबर का उपयोग किया गया था। पब्लिशर ने निम्न के साथ एक सामान्य अनुक्रम उत्पन्न किया:

stNum=1
sqNum=0, 1, 2, 3

फिर पहला कैप्चर किया गया फ्रेम (stNum=1, sqNum=0) तब रीप्ले किया गया जब सब्सक्राइबर पहले ही बाद के अनुक्रम मान को प्रोसेस कर चुका था।

रीप्ले की गई प्रतियाँ अमान्य रिपोर्ट की गईं क्योंकि प्राप्त sqNum=0 संग्रहीत अनुक्रम मान से नया नहीं था। हालाँकि, सब्सक्राइबर रीप्ले किए गए डेटा वाली लिसनर घटनाओं को प्रिंट करता रहा:

यह प्रयोग एक संकीर्ण लेकिन संबंधित अवलोकन का समर्थन करता है:

• समान-स्थिति रीप्ले का पता वैधता फ्लैग के माध्यम से चला।
• परीक्षित उदाहरण में पता लगने से रीप्ले किए गए संदेश की कॉलबैक डिलीवरी नहीं रुकी।

मूल रीप्ले स्क्रीनशॉट सहायक सामग्री के रूप में बरकरार रखे गए हैं:

• 12-original-sqnum-replay-command-raw.png
• 13-original-sqnum-replay-terminal-raw.png

उन कच्ची छवियों में असंबंधित Scapy वैकल्पिक-मॉड्यूल आयात चेतावनियाँ हैं। चेतावनियों ने स्क्रिप्ट को कैप्चर किए गए GOOSE फ्रेम रिपोर्ट करने और ट्रांसमिशन पूरा करने से नहीं रोका, लेकिन तकनीकी परिणाम की समीक्षा के लिए ऊपर के स्पष्ट स्क्रीनशॉट बेहतर हैं।

दोनों प्रयोगों के बीच संबंध

प्रयोग उसी GOOSE रीप्ले/संदेश-ताज़गी समस्या की विभिन्न शाखाओं को प्रदर्शित करते हैं:

अवलोकन	प्राप्त संदेश	देखा गया परिणाम
निचला-stNum रीप्ले	संग्रहीत stNum=2; प्राप्त पुराना stNum=1	परीक्षित रन में पुरानी स्थिति और डेटा लिसनर को दिए गए और वैध के रूप में रिपोर्ट किए गए
गैर-बढ़ता sqNum रीप्ले	समान stNum; प्राप्त पुराना या डुप्लिकेट sqNum	संदेश अमान्य रिपोर्ट किया गया, लेकिन लिसनर कॉलबैक और रीप्ले किए गए डेटा की डिलीवरी जारी रही

पहला अवलोकन प्राथमिक CVE निष्कर्ष है क्योंकि यह नई स्थिति से पुरानी स्थिति में रोलबैक प्रदर्शित करता है। दूसरा अवलोकन इस बारे में सहायक साक्ष्य है कि अमान्य समान-स्थिति रीप्ले लिसनर पथ से कैसे गुजरते रहते हैं।

देखा गया प्रभाव

प्रदर्शित सॉफ़्टवेयर-स्तरीय प्रभाव है:

• एक नई स्थिति पहले ही प्रोसेस हो जाने के बाद भी पहले स्वीकृत GOOSE स्थिति लिसनर को दी जा सकती है।
• सब्सक्राइबर-दृश्यमान स्थिति नए stNum से पुराने stNum में जा सकती है।
• बार-बार आने वाले पुराने फ्रेम लिसनर गतिविधि उत्पन्न करते रह सकते हैं, भले ही बाद की प्रतियाँ अमान्य रिपोर्ट की जाएँ।

जो एप्लिकेशन स्वतंत्र ताज़गी प्रवर्तन के बिना कॉलबैक डेटा का उपभोग करते हैं, वे पुराने या रीप्ले किए गए मानों को प्रोसेस कर सकते हैं।

डाउनस्ट्रीम प्रभाव सब्सक्राइबर एप्लिकेशन, कॉन्फ़िगरेशन, इंटरलॉकिंग लॉजिक और सुरक्षा लॉजिक पर निर्भर करता है।

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

सुझावित निवारण दिशा

सब्सक्राइबर स्थिति अपडेट करने या लिसनर को आमंत्रित करने से पहले: