Riepilogo

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:

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à.

Anatomia del payload

La disposizione dei campi della PoC, verificata eseguendo il porting (py poc/poc_py3.py --layout):

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.

Lo stub del decoder è inerte

buf è uno stub shikata_ga_nai di 29 byte generato da msfvenom. Disassemblato con ndisasm -b32:

Da questo emergono due cose, ed entrambe significano che il payload non potrà mai essere eseguito:

1. 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.
2. Il terminatore \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.

Sfruttabilità (valutazione onesta)

Valutando questo come farebbe un broker o un vendor, anziché come fa il vettore CVSS v3.1:

• Nessun confine di privilegio viene superato. 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.
• La PoC non precede nulla. Il controllo di 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.
• È locale e richiede che l'operatore carichi il file. Il 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.

Correzioni al record pubblicato

Il record CVE presenta due difetti che vale la pena dichiarare chiaramente, dato che è pubblicato a mio nome.

1. Il prodotto del vendor citato è quello sbagliato

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.

Il difetto è il riferimento al vendor che il CNA ha allegato. NVD cita BU-69414, che è la pagina del prodotto software MIL-STD-1553 di DDC — uno stack databus diverso da quello interessato da questo ritrovamento. ARINC 664 è AFDX (Ethernet commutata profilata, ARINC 664 Part 7); MIL-STD-1553 è un bus command/response a doppia ridondanza da 1 Mbps. Sono standard non correlati.

La causa probabile della citazione errata è il nome del file di risultati. dataSIMS chiama il file di risultati del modulo ARINC 664 milstd1553result.txt — un residuo della discendenza MIL-STD-1553 della suite. Chiunque legga la descrizione della CVE e cerchi una pagina prodotto corrispondente seguirà quella stringa fino alla linea 1553, che è ciò che sembra essere accaduto. Il nome del file non è una prova del modulo interessato, e un record che punta alla pagina del prodotto 1553 manda i difensori ad auditare il componente sbagliato.

2. I due vettori CVSS si escludono a vicenda

Entrambi i vettori provengono da VulnCheck e si contraddicono a vicenda sui due aspetti che contano:

Non possono essere entrambi giusti. Il vettore v4.0 è quello difendibile: la PoC dimostra un crash, non una divulgazione o una perdita di integrità. Il punteggio v3.1 di 8.4 sopravvaluta il ritrovamento, e preferisco dirlo qui piuttosto che trarne beneficio.

Riproduzione

Qui non serve il software target — la PoC scrive solo il file malformato. Per innescare l'overflow serve dataSIMS 4.5.3, un software commerciale con licenza che questo repository non distribuisce.

Quindi carica il file con la build interessata sotto un debugger e osserva la sovrascrittura di EIP. poc/49577.py è il sorgente Python 2 originale, archiviato alla lettera; non verrà eseguito su Python 3.

Note sulla conversione Python 2 → 3

Il porting produce un file byte-identico di 1040 byte (sha256 530efb5e…). Tre cose hanno dovuto cambiare, e una cosa che sembra un bug non lo è:

• print len(win32) è un'istruzione in Python 2, un SyntaxError in Python 3.
• L'originale concatena campi str con uno shellcode bytes. Python 2 lo permetteva perché str era bytes; Python 3 solleva TypeError.
• open(..., "w") deve diventare "wb". In modalità testo Python 3 codificherebbe in UTF-8 ogni byte ≥ 0x80 nello stub — 0xda → 0xc3 0x9a — corrompendo silenziosamente il payload e cambiandone la lunghezza.
• imp2 = "\x61\x72\x61\x63\x61\x67\x131\x7a" non è una stranezza legata alla versione. \x accetta esattamente due cifre esadecimali sia in Python 2 che in Python 3, quindi \x131 è 0x13 seguito dal carattere 1. Il campo è di 9 byte in entrambi. Sembra solo scritto male.

Limitazioni

Dichiarate esplicitamente così nessuno deve indovinare cosa è stato fatto e cosa no:

• Nessuna analisi delle cause profonde. Binario closed-source; la funzione che trabocca non è stata identificata.
• Nessuna patch, nessun advisory del vendor e nessuna registrazione di divulgazione coordinata — il ritrovamento del 2020 è andato direttamente su Exploit-DB.
• Non ritestato su alcuna release successiva alla 4.5.3 e non testato contro le mitigazioni Windows attuali.
• Nessuna esecuzione di codice funzionante. La sovrascrittura di EIP è l'intero risultato.
• La CVE è stata assegnata retroattivamente nel 2026 da un CNA di terze parti, cinque anni dopo la pubblicazione, senza contattarmi.

Cronologia

Riferimenti

• 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/

Crediti

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

Approfondimenti: English · Türkçe