kagancapar/cve-2021-47881PoC e analisi di uno stack-buffer-overflow locale in dataSIMS Avionics ARINC 664-1 v4.5.3, con dettaglio del payload, script di riproduzione e correzioni al record CVE.
Overflow del buffer locale basato sullo stack in dataSIMS Avionics ARINC 4.5.3 (Data Device Corporation)
Ciao, sono Kağan Çapar. Nel febbraio 2020 ho trovato un overflow del buffer locale basato sullo stack nel software databus avionico dataSIMS di DDC e ho pubblicato una proof of concept su Exploit-DB nel febbraio 2021. Quasi cinque anni dopo, nel gennaio 2026, VulnCheck ha assegnato la CVE-2021-47881 come CVE retroattiva — sono venuto a conoscenza dell'assegnazione solo a posteriori, non da essa.
Questo repository è il record archivistico di quel ritrovamento: la PoC originale conservata così come pubblicata, un porting Python 3 byte-identico, una scomposizione annotata del payload e le correzioni per due problemi nel record CVE pubblicato.
Ambito, fin da subito. Questo è un record, non un'analisi delle cause profonde. dataSIMS è un software commerciale closed-source, non esiste una patch del vendor e non ho ritestato questo exploit contro una release attuale. Ciò che è verificabile qui è verificato e mostrato; tutto il resto è segnalato in Limitazioni. Se sei arrivato qui aspettandoti la profondità di CVE-2026-5201, leggi prima quella nota.
| CVE | CVE-2021-47881 |
| CWE | CWE-121 — Stack-based Buffer Overflow |
| CVSS v4.0 | 6.7 MEDIUM — AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (VulnCheck) |
| CVSS v3.1 | 8.4 HIGH — AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (VulnCheck) |
| Componente interessato | dataSIMS Avionics ARINC 664-1, versione 4.5.3 |
| Vendor | Data Device Corporation |
| CNA | VulnCheck |
| Scoperta | 2020-02-17 |
| PoC pubblicata | 2021-02-19 — EDB-49577 |
| CVE pubblicata | 2026-01-23 (NVD) |
| Patch del vendor | nessuna pubblicata |
| Testato su | Windows 10 Enterprise x64 |
Il componente interessato è il modulo ARINC 664-1 di dataSIMS 4.5.3. Rilegge un file di risultati che — nonostante il modulo a cui appartiene — si chiama milstd1553result.txt; il nome è un artefatto del vendor ereditato dalla discendenza MIL-STD-1553 della suite, non un'indicazione di quale modulo sia interessato. Fornire una versione sovradimensionata e modellata dall'attaccante di quel file fa traboccare un buffer stack a dimensione fissa durante il percorso di rilettura e sovrascrive l'indirizzo di ritorno salvato. Il crash termina con il controllo completo di EIP:
EIP 42424242 <- 'BBBB' from the payload
ECX 42424242
C0000005 <- STATUS_ACCESS_VIOLATION
La PoC pubblicata è di 1040 byte e si ferma alla sovrascrittura di EIP. Non ottiene l'esecuzione di codice, e non è mai stata pensata per questo — vedi Sfruttabilità.
La disposizione dei campi della PoC, verificata eseguendo il porting (py poc/poc_py3.py --layout):
| Campo | Offset | Lunghezza | Contenuto |
|---|---|---|---|
junk | 0 / 0x000 | 600 | riempimento 0x41 |
align | 600 / 0x258 | 8 | "22221111" |
prop | 608 / 0x260 | 380 | riempimento 0x43 |
imp | 988 / 0x3dc | 10 | "bzhrturlu2" |
imp2 | 998 / 0x3e6 | 9 | "aracag" 0x13 "1z" |
overwrite | 1007 / 0x3ef | 4 | 0x42 × 4 → indirizzo di ritorno salvato |
buf | 1011 / 0x3f3 | 29 | stub del decoder shikata_ga_nai |
| totale | 1040 | sha256 530efb5efef917082e40dcf379f5e0a526375724af18aba6f0270f794f96d066 |
L'offset di EIP è 1007. Non è un numero che ottieni da !mona findmsp o pattern_offset.rb — è la somma di cinque campi regolati a mano. La PoC originale è stata costruita allargando un crash finché l'indirizzo di ritorno si spostava, non localizzando l'offset analiticamente. Lo segnalo apertamente, invece di abbellirlo: una riscrittura pulita troverebbe la distanza reale fino all'indirizzo di ritorno salvato ed eliminerebbe del tutto align, imp e imp2, dato che nessuno di essi ha un significato. imp/imp2 sono stringhe filler, non import.
buf è uno stub shikata_ga_nai di 29 byte generato da msfvenom. Disassemblato con 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
Da questo emergono due cose, ed entrambe significano che il payload non potrà mai essere eseguito:
mov cl,0x1 — il ciclo di decodifica è configurato per un singolo blocco di 4 byte. Dietro non c'è un payload reale, solo quei 4 byte.\xe2\xf4 (loop) è assente. Uno stub sgn completo termina il ciclo di decodifica con loop prima del corpo codificato. Qui l'esecuzione cade direttamente da add ebx,[eax+0x15] in E9 8B 7C 9C — che in quel momento è ancora codificato e comunque non è una sequenza di istruzioni valida.Quindi lo stub è un segnaposto che occupa la coda del payload. Questo corrisponde al modo in cui la PoC è stata descritta su Exploit-DB, ed è la lettura onesta: questa è una dimostrazione di controllo di EIP, non un exploit funzionante.
Valutando questo come farebbe un broker o un vendor, anziché come fa il vettore CVSS v3.1:
milstd1553result.txt è un file che l'applicazione stessa produce, in una posizione che lo stesso utente controlla già. Un attaccante che può riscriverlo può in generale già eseguire codice come quell'utente. Questo lo rende un bug di robustezza molto più che un bug di sicurezza.EIP su una build x86 del 2020 dice poco di per sé. Per trasformarlo in esecuzione serve una strategia DEP/ASLR — un modulo senza /DYNAMICBASE, una catena ROP o una sovrascrittura parziale. Niente di tutto questo è stato fatto, e non ho verificato quali mitigazioni includa la build attuale.UI:A di CVSS v4.0 riflette la realtà; il UI:N della v3.1 no.Se qualcuno vuole rendere questo davvero interessante, le superfici produttive non sono affatto questo file: il driver kernel che DDC distribuisce per le sue schede PCIe 1553/664 (gestione degli IOCTL → LPE), qualsiasi parsing di frame ARINC 664/AFDX esposto alla rete e i formati di file di input che la suite consuma da fonti non attendibili. Questi attraversano confini reali. Questo no.
Il record CVE presenta due difetti che vale la pena dichiarare chiaramente, dato che è pubblicato a mio nome.
La designazione del prodotto nel record — "dataSIMS Avionics ARINC 664-1 version 4.5.3" — è corretta. Il componente interessato è il modulo ARINC 664, come indicato nel titolo originale di Exploit-DB.