CVE-2021-47881

dataSIMS Avionics ARINC 4.5.3 (Data Device Corporation) में स्थानीय स्टैक-आधारित बफर ओवरफ्लो

नमस्ते, मैं Kağan Çapar हूँ। फरवरी 2020 में मुझे DDC के dataSIMS एवियोनिक्स डेटाबस सॉफ़्टवेयर में एक स्थानीय स्टैक-आधारित बफर ओवरफ्लो मिला और फरवरी 2021 में Exploit-DB पर एक प्रूफ ऑफ कॉन्सेप्ट प्रकाशित किया। लगभग पाँच साल बाद, जनवरी 2026 में, VulnCheck ने इसे पूर्वव्यापी CVE के रूप में CVE-2021-47881 निर्दिष्ट किया — मुझे इस निर्धारण के बारे में घटना के बाद पता चला, न कि उसके माध्यम से।

यह रिपॉजिटरी उस खोज का अभिलेखीय रिकॉर्ड है: मूल PoC प्रकाशित रूप में संरक्षित, एक बाइट-समान Python 3 पोर्ट, पेलोड का टिप्पणी-सहित विवरण, और प्रकाशित CVE रिकॉर्ड में दो समस्याओं के लिए सुधार।

दायरा, पहले से स्पष्ट। यह एक रिकॉर्ड है, मूल-कारण विश्लेषण नहीं। dataSIMS बंद-स्रोत वाणिज्यिक सॉफ़्टवेयर है, कोई विक्रेता पैच नहीं है, और मैंने इसे किसी वर्तमान रिलीज़ के विरुद्ध दोबारा परीक्षण नहीं किया है। यहाँ जो सत्यापन योग्य है वह सत्यापित और दिखाया गया है; बाकी सब कुछ सीमाएँ में बताया गया है। यदि आप CVE-2026-5201 की गहराई की उम्मीद करके आए हैं, तो पहले वह नोट पढ़ें।

सारांश

प्रभावित घटक dataSIMS 4.5.3 का ARINC 664-1 मॉड्यूल है। यह एक परिणाम फ़ाइल को वापस पढ़ता है, जिसका नाम — इसके मॉड्यूल के बावजूद — milstd1553result.txt है; यह नाम सूट की MIL-STD-1553 वंशावली से लिया गया एक विक्रेता कलाकृति है, यह संकेत नहीं कि कौन सा मॉड्यूल प्रभावित है। उस फ़ाइल का एक अत्यधिक लंबा, हमलावर-आकार का संस्करण प्रदान करने से रीड-बैक पथ में एक निश्चित-आकार के स्टैक बफर का ओवरफ्लो होता है और सहेजा गया रिटर्न पता अधिलेखित हो जाता है। क्रैश EIP पर पूर्ण नियंत्रण के साथ समाप्त होता है:

EIP  42424242        <- 'BBBB' from the payload
ECX  42424242
     C0000005        <- STATUS_ACCESS_VIOLATION

प्रकाशित PoC 1040 बाइट्स का है और EIP अधिलेखन पर रुक जाता है। यह कोड निष्पादन प्राप्त नहीं करता है, और ऐसा करने का कभी इरादा नहीं था — शोषण-क्षमता देखें।

पेलोड की संरचना

पोर्ट चलाकर सत्यापित PoC का फ़ील्ड लेआउट (py poc/poc_py3.py --layout):

EIP ऑफ़सेट 1007 है। यह कोई संख्या नहीं है जो आपको !mona findmsp या pattern_offset.rb से मिलती है — यह पाँच हाथ-ट्यून किए गए फ़ील्डों का योग है। मूल PoC को क्रैश को तब तक चौड़ा करके बनाया गया था जब तक कि रिटर्न पता स्थानांतरित नहीं हो गया, न कि ऑफ़सेट को विश्लेषणात्मक रूप से खोजकर। मैं इसे सजाकर नहीं, बल्कि स्पष्ट रूप से नोट कर रहा हूँ: एक स्वच्छ पुनर्लेखन सहेजे गए रिटर्न पते की वास्तविक दूरी ढूँढेगा और align, imp, और imp2 को पूरी तरह से हटा देगा, क्योंकि उनमें से किसी का कोई अर्थ नहीं है। imp/imp2 फिलर स्ट्रिंग हैं, इम्पोर्ट नहीं।

डिकोडर स्टब निष्क्रिय है

buf एक 29-बाइट msfvenom shikata_ga_nai स्टब है। ndisasm -b32 के साथ डिसअसेंबल किया गया:

00000000  DAC1              fcmovb st1              ; junk FPU op (sgn signature)
00000002  D97424F4          fnstenv [esp-0xc]       ; GetPC
00000006  58                pop eax                 ; eax = &stub
00000007  BB0B7E9762        mov ebx,0x62977e0b      ; XOR key
0000000C  33C9              xor ecx,ecx
0000000E  B101              mov cl,0x1              ; <-- ONE 4-byte block
00000010  315819            xor [eax+0x19],ebx      ; decode block at +0x19
00000013  83E8FC            sub eax,-4              ; eax += 4
00000016  035815            add ebx,[eax+0x15]      ; key schedule
00000019  E9                db 0xe9                 ; <-- encoded block, not code
0000001A  8B                db 0x8b
0000001B  7C9C              jl 0xffffffb9

इससे दो बातें निकलती हैं, और दोनों का अर्थ है कि पेलोड कभी नहीं चल सकता:

1. mov cl,0x1 — डिकोड लूप एकल 4-बाइट ब्लॉक के लिए कॉन्फ़िगर किया गया है। इसके पीछे कोई वास्तविक पेलोड नहीं है, केवल वे 4 बाइट्स हैं।
2. \xe2\xf4 (loop) टर्मिनेटर अनुपस्थित है। एक पूर्ण sgn स्टब एन्कोडेड बॉडी से पहले loop के साथ डिकोड लूप समाप्त करता है। यहाँ निष्पादन सीधे add ebx,[eax+0x15] से E9 8B 7C 9C में गिर जाता है — जो उस क्षण भी एन्कोडेड है, और वैसे भी एक मान्य निर्देश अनुक्रम नहीं है।

तो स्टब एक प्लेसहोल्डर है जो पेलोड की पूंछ पर कब्जा करता है। यह उस तरीके से मेल खाता है जिस प्रकार PoC को Exploit-DB पर वर्णित किया गया था, और यही ईमानदार पठन है: यह EIP-नियंत्रण प्रदर्शन है, कार्यशील शोषण नहीं।

शोषण-क्षमता (ईमानदार मूल्यांकन)

इसे उस तरह तौलना जैसे कोई ब्रोकर या विक्रेता तौलेगा, न कि उस तरह जैसे CVSS v3.1 वेक्टर करता है:

• कोई विशेषाधिकार सीमा पार नहीं होती। milstd1553result.txt एक फ़ाइल है जिसे एप्लिकेशन स्वयं उत्पन्न करता है, एक ऐसे स्थान पर जिसे वही उपयोगकर्ता पहले से नियंत्रित करता है। जो हमलावर इसे फिर से लिख सकता है, वह आम तौर पर पहले से ही उस उपयोगकर्ता के रूप में कोड चला सकता है। यह इसे एक सुरक्षा बग की तुलना में कहीं अधिक मजबूती बग बनाता है।
• PoC किसी चीज़ से पहले नहीं आता। 2020-युग के x86 बिल्ड पर EIP का नियंत्रण अपने आप में बहुत कम कहता है। इसे निष्पादन में बदलने के लिए एक DEP/ASLR कहानी चाहिए — एक मॉड्यूल जो /DYNAMICBASE के बिना हो, एक ROP श्रृंखला, या आंशिक अधिलेखन। इनमें से कुछ भी नहीं किया गया, और मैंने यह जाँच नहीं की है कि वर्तमान बिल्ड किन शमनों के साथ आता है।
• यह स्थानीय है, और इसे ऑपरेटर द्वारा फ़ाइल लोड करने की आवश्यकता है। CVSS v4.0 का UI:A वास्तविकता दर्शाता है; v3.1 का UI:N नहीं।

यदि कोई इसे वास्तव में दिलचस्प बनाना चाहता है, तो उत्पादक सतहें यह फ़ाइल बिल्कुल नहीं हैं: DDC अपने 1553/664 PCIe कार्डों के लिए जो कर्नेल ड्राइवर भेजता है (IOCTL हैंडलिंग → LPE), कोई भी नेटवर्क-सामना करने वाला ARINC 664/AFDX फ्रेम पार्सिंग, और सूट द्वारा अविश्वसनीय स्रोतों से उपभोग किए जाने वाले इनपुट फ़ाइल प्रारूप। वे वास्तविक सीमाएँ पार करते हैं। यह नहीं।

प्रकाशित रिकॉर्ड में सुधार

CVE रिकॉर्ड में दो त्रुटियाँ हैं जिन्हें स्पष्ट रूप से बताना उचित है, क्योंकि यह मेरे नाम के तहत प्रकाशित है।

1. उद्धृत विक्रेता उत्पाद गलत है

रिकॉर्ड का उत्पाद पदनाम — "dataSIMS Avionics ARINC 664-1 version 4.5.3" — सही है। प्रभावित घटक ARINC 664 मॉड्यूल है, जैसा कि मेरे मूल Exploit-DB शीर्षक में बताया गया है।

दोष CNA द्वारा संलग्न विक्रेता संदर्भ है। NVD BU-69414 उद्धृत करता है, जो DDC का MIL-STD-1553 सॉफ़्टवेयर उत्पाद पृष्ठ है — इस खोज से प्रभावित स्टैक से भिन्न एक डेटाबस स्टैक। ARINC 664 AFDX है (प्रोफाइल्ड स्विच्ड ईथरनेट, ARINC 664 भाग 7); MIL-STD-1553 एक 1 Mbps दोहरा-अनावश्यक कमांड/प्रतिक्रिया बस है। वे असंबंधित मानक हैं।

गलत उद्धरण का संभावित कारण परिणाम फ़ाइल का नाम है। dataSIMS ARINC 664 मॉड्यूल की परिणाम फ़ाइल का नाम milstd1553result.txt रखता है — जो सूट की MIL-STD-1553 वंशावली से बचा हुआ है। कोई भी व्यक्ति CVE विवरण पढ़कर और मिलते-जुलते विक्रेता उत्पाद पृष्ठ की ओर बढ़ते हुए उस स्ट्रिंग का अनुसरण करके सीधे 1553 श्रेणी में पहुँचेगा, और ऐसा ही हुआ प्रतीत होता है। फ़ाइल का नाम प्रभावित मॉड्यूल का प्रमाण नहीं है, और एक रिकॉर्ड जो 1553 उत्पाद पृष्ठ की ओर इशारा करता है, रक्षकों को गलत घटक का ऑडिट करने भेजता है।

2. दोनों CVSS वेक्टर परस्पर अनन्य हैं

दोनों वेक्टर VulnCheck से आते हैं, और वे दो महत्वपूर्ण चीज़ों पर एक-दूसरे का खंडन करते हैं:

वे दोनों सही नहीं हो सकते। v4.0 वेक्टर बचाव योग्य है: PoC एक क्रैश प्रदर्शित करता है, न कि प्रकटीकरण या अखंडता हानि। v3.1 का 8.4 स्कोर खोज को अतिरंजित करता है, और मैं इससे लाभ उठाने के बजाय यहाँ यह कहना पसंद करूँगा।

पुनरुत्पादन

यहाँ किसी चीज़ के लिए लक्षित सॉफ़्टवेयर की आवश्यकता नहीं है — PoC केवल दूषित फ़ाइल लिखता है। ओवरफ्लो को ट्रिगर करने के लिए dataSIMS 4.5.3 की आवश्यकता होती है, जो लाइसेंस प्राप्त वाणिज्यिक सॉफ़्टवेयर है जिसे यह रिपॉजिटरी वितरित नहीं करता है।

# print the field map, write nothing
py poc/poc_py3.py --layout

# write the 1040-byte payload
py poc/poc_py3.py -o milstd1553result.txt

फिर प्रभावित बिल्ड के साथ फ़ाइल को डिबगर के अंतर्गत लोड करें और EIP अधिलेखन का निरीक्षण करें। poc/49577.py मूल Python 2 स्रोत है, जो शब्दशः संग्रहीत है; यह Python 3 पर नहीं चलेगा।

Python 2 → 3 नोट्स

पोर्ट एक बाइट-समान 1040-बाइट फ़ाइल उत्पन्न करता है (sha256 530efb5e…)। तीन चीज़ों को बदलना पड़ा, और एक चीज़ जो बग लगती है वह बग नहीं है:

• print len(win32) Python 2 में एक स्टेटमेंट है, Python 3 में SyntaxError है।
• मूल str फ़ील्डों को bytes शेलकोड के साथ संयोजित करता है। Python 2 ने इसे अनुमति दी क्योंकि str बाइट्स ही था; Python 3 TypeError उठाता है।
• open(..., "w") को "wb" बनना चाहिए। टेक्स्ट मोड में Python 3 स्टब में प्रत्येक बाइट ≥ 0x80 को UTF-8 एन्कोड करेगा — 0xda → 0xc3 0x9a — चुपचाप पेलोड को दूषित कर देगा और उसकी लंबाई बदल देगा।
• imp2 = "\x61\x72\x61\x63\x61\x67\x131\x7a" नहीं है एक संस्करण-निर्भर विचित्रता। Python 2 और 3 दोनों में \x ठीक दो हेक्स अंक लेता है, इसलिए है और उसके बाद वर्ण । यह फ़ील्ड दोनों में 9 बाइट्स है। यह बस अजीब पढ़ा जाता है।

सीमाएँ

स्पष्ट रूप से बताया गया है ताकि किसी को अनुमान न लगाना पड़े कि क्या किया गया और क्या नहीं:

• कोई मूल-कारण विश्लेषण नहीं। बंद-स्रोत बाइनरी; अतिप्रवाहित होने वाले फ़ंक्शन की पहचान नहीं की गई है।
• कोई पैच नहीं, कोई विक्रेता सलाह नहीं, और कोई समन्वित प्रकटीकरण रिकॉर्ड नहीं — 2020 की खोज सीधे Exploit-DB पर गई।
• 4.5.3 के बाद किसी भी रिलीज़ पर दोबारा परीक्षण नहीं किया गया, और वर्तमान Windows शमनों के विरुद्ध परीक्षण नहीं किया गया।
• कोई कार्यशील कोड निष्पादन नहीं। EIP अधिलेखन ही पूरा परिणाम है।
• CVE को 2026 में एक तृतीय-पक्ष CNA द्वारा प्रकाशन के पाँच साल बाद, मुझसे संपर्क किए बिना पूर्वव्यापी रूप से निर्दिष्ट किया गया था।

समयरेखा

संदर्भ

• https://nvd.nist.gov/vuln/detail/CVE-2021-47881
• https://www.cve.org/CVERecord?id=CVE-2021-47881
• https://www.vulncheck.com/advisories/datasims-avionics-arinc-local-buffer-overflow
• https://www.exploit-db.com/exploits/49577
• https://www.ddc-web.com/

श्रेय

Kağan Çapar — GitHub · Exploit-DB · LinkedIn · X

लेख: English · Türkçe