kagancapar/cve-2021-47881PoC und Analyse eines lokalen Stack-Buffer-Overflows in dataSIMS Avionics ARINC 664-1 v4.5.3, mit Payload-Aufschlüsselung, Reproduktionsskript und Korrekturen der CVE-Einträge.
Lokaler stack-basierter Pufferüberlauf in dataSIMS Avionics ARINC 4.5.3 (Data Device Corporation)
Hallo, ich bin Kağan Çapar. Im Februar 2020 fand ich einen lokalen stack-basierten Pufferüberlauf in DDCs dataSIMS-Avionik-Datenbussoftware und veröffentlichte im Februar 2021 einen Proof of Concept auf Exploit-DB. Fast fünf Jahre später, im Januar 2026, vergab VulnCheck dafür CVE-2021-47881 als retroaktive CVE — ich erfuhr von der Vergabe erst im Nachhinein, nicht von ihm.
Dieses Repository ist das Archivdokument für diesen Fund: der ursprüngliche PoC, unverändert wie veröffentlicht, ein byte-identischer Python-3-Port, eine kommentierte Aufschlüsselung des Payloads sowie Korrekturen für zwei Probleme im veröffentlichten CVE-Eintrag.
Umfang, vorab. Dies ist ein Archivdokument, keine Root-Cause-Analyse. dataSIMS ist proprietäre kommerzielle Software, es gibt keinen Hersteller-Patch, und ich habe dies nicht gegen eine aktuelle Version erneut getestet. Was hier verifizierbar ist, wird verifiziert und gezeigt; alles andere wird in Einschränkungen benannt. Wenn du hierhergekommen bist und die Tiefe von CVE-2026-5201 erwartest, lies zuerst diese Notiz.
| CVE | CVE-2021-47881 |
| CWE | CWE-121 — Stack-basierter Pufferüberlauf |
| CVSS v4.0 | 6.7 MITTEL — 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 HOCH — AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (VulnCheck) |
| Betroffen | dataSIMS Avionics ARINC 664-1, Version 4.5.3 |
| Hersteller | Data Device Corporation |
| CNA | VulnCheck |
| Entdeckt | 2020-02-17 |
| PoC veröffentlicht | 2021-02-19 — EDB-49577 |
| CVE veröffentlicht | 2026-01-23 (NVD) |
| Hersteller-Patch | keiner veröffentlicht |
| Getestet auf | Windows 10 Enterprise x64 |
Die betroffene Komponente ist das ARINC 664-1-Modul von dataSIMS 4.5.3. Es liest eine Ergebnisdatei zurück, die — trotz des Moduls, zu dem sie gehört — milstd1553result.txt heißt; der Name ist ein Hersteller-Artefakt, das aus der MIL-STD-1553-Linie der Suite übernommen wurde, kein Hinweis darauf, welches Modul betroffen ist. Die Zuführung einer überlangen, angreifergeformten Version dieser Datei lässt einen Stack-Puffer fester Größe während des Rücklesepfads überlaufen und überschreibt die gespeicherte Rücksprungadresse. Der Absturz landet mit voller Kontrolle über EIP:
EIP 42424242 <- 'BBBB' from the payload
ECX 42424242
C0000005 <- STATUS_ACCESS_VIOLATION
Der veröffentlichte PoC ist 1040 Bytes lang und endet beim EIP-Überschreiben. Er erreicht keine Codeausführung und war nie dafür gedacht — siehe Ausnutzbarkeit.
Der Feldaufbau des PoC, verifiziert durch Ausführen des Ports (py poc/poc_py3.py --layout):
| Feld | Offset | Länge | Inhalt |
|---|---|---|---|
junk | 0 / 0x000 | 600 | 0x41 Füllmaterial |
align | 600 / 0x258 | 8 | "22221111" |
prop | 608 / 0x260 | 380 | 0x43 Füllmaterial |
imp | 988 / 0x3dc | 10 | "bzhrturlu2" |
imp2 | 998 / 0x3e6 | 9 | "aracag" 0x13 "1z" |
overwrite | 1007 / 0x3ef | 4 | 0x42 × 4 → gespeicherte Rücksprungadresse |
buf | 1011 / 0x3f3 | 29 | shikata_ga_nai-Decoder-Stub |
| Gesamt | 1040 | sha256 530efb5efef917082e40dcf379f5e0a526375724af18aba6f0270f794f96d066 |
Der EIP-Offset ist 1007. Das ist keine Zahl, die man von !mona findmsp oder pattern_offset.rb bekommt — sie ist die Summe von fünf manuell abgestimmten Feldern. Der ursprüngliche PoC wurde erstellt, indem ein Absturz verbreitert wurde, bis sich die Rücksprungadresse verschob, nicht durch analytisches Lokalisieren des Offsets. Ich erwähne das, statt es zu beschönigen: Eine saubere Neufassung würde die wahre Distanz zur gespeicherten Rücksprungadresse ermitteln und align, imp und imp2 komplett entfernen, da keines von ihnen eine Bedeutung trägt. imp/imp2 sind Füllstrings, keine Imports.
buf ist ein 29-Byte-msfvenom-shikata_ga_nai-Stub. Disassembliert mit 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
Zwei Dinge ergeben sich daraus, und beide bedeuten, dass der Payload niemals laufen kann:
mov cl,0x1 — die Dekodierschleife ist für einen einzelnen 4-Byte-Block konfiguriert. Dahinter steckt kein echter Payload, nur diese 4 Bytes.\xe2\xf4 (loop)-Terminator fehlt. Ein vollständiger sgn-Stub beendet die Dekodierschleife mit loop vor dem kodierten Körper. Hier fällt die Ausführung direkt von add ebx,[eax+0x15] in E9 8B 7C 9C — das in diesem Moment noch kodiert ist und ohnehin keine gültige Befehlssequenz darstellt.Der Stub ist also ein Platzhalter, der das Ende des Payloads belegt. Das entspricht der Beschreibung des PoC auf Exploit-DB, und es ist die ehrliche Lesart: Dies ist eine Demonstration der EIP-Kontrolle, kein funktionierender Exploit.
Bewertet man dies so, wie es ein Broker oder Hersteller täte, statt so, wie es der CVSS-v3.1-Vektor tut:
milstd1553result.txt ist eine Datei, die die Anwendung selbst erzeugt, an einem Ort, den derselbe Benutzer bereits kontrolliert. Ein Angreifer, der sie neu schreiben kann, kann in der Regel bereits als dieser Benutzer Code ausführen. Das macht dies weit mehr zu einem Robustheitsfehler als zu einem Sicherheitsfehler.EIP in einem x86-Build aus der Zeit um 2020 sagt für sich genommen wenig aus. Um daraus Codeausführung zu machen, braucht es eine DEP/ASLR-Geschichte — ein Modul ohne /DYNAMICBASE, eine ROP-Kette oder einen partiellen Overwrite. Nichts davon wurde gemacht, und ich habe nicht geprüft, welche Gegenmaßnahmen der aktuelle Build mit sich bringt.UI:A entspricht der Realität; v3.1s UI:N nicht.Wenn jemand das wirklich interessant machen will, sind die produktiven Angriffsflächen überhaupt nicht diese Datei: der Kernel-Treiber, den DDC für seine 1553/664-PCIe-Karten ausliefert (IOCTL-Behandlung → LPE), jede netzwerkseitige ARINC-664/AFDX-Frame-Analyse sowie die Eingabe-Dateiformate, die die Suite aus nicht vertrauenswürdigen Quellen übernimmt. Diese überschreiten echte Grenzen. Diese hier nicht.
Der CVE-Eintrag weist zwei Mängel auf, die klar benannt werden sollten, da er unter meinem Namen veröffentlicht ist.