Zusammenfassung

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:

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.

Anatomie des Payloads

Der Feldaufbau des PoC, verifiziert durch Ausführen des Ports (py poc/poc_py3.py --layout):

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.

Der Decoder-Stub ist wirkungslos

buf ist ein 29-Byte-msfvenom-shikata_ga_nai-Stub. Disassembliert mit ndisasm -b32:

Zwei Dinge ergeben sich daraus, und beide bedeuten, dass der Payload niemals laufen kann:

1. mov cl,0x1 — die Dekodierschleife ist für einen einzelnen 4-Byte-Block konfiguriert. Dahinter steckt kein echter Payload, nur diese 4 Bytes.
2. Der \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.

Ausnutzbarkeit (ehrliche Einschätzung)

Bewertet man dies so, wie es ein Broker oder Hersteller täte, statt so, wie es der CVSS-v3.1-Vektor tut:

• Es wird keine Privilegiengrenze überschritten. 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.
• Der PoC ist seiner Zeit nicht voraus. Die Kontrolle über 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.
• Er ist lokal und erfordert, dass der Bediener die Datei lädt. CVSS v4.0s 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.

Korrekturen am veröffentlichten Eintrag

Der CVE-Eintrag weist zwei Mängel auf, die klar benannt werden sollten, da er unter meinem Namen veröffentlicht ist.

1. Das zitierte Herstellerprodukt ist das falsche

Die Produktbezeichnung des Eintrags — „dataSIMS Avionics ARINC 664-1 Version 4.5.3" — ist korrekt. Die betroffene Komponente ist das ARINC-664-Modul, wie in meinem ursprünglichen Exploit-DB-Titel angegeben.

Der Mangel ist die Herstellerreferenz, die der CNA angefügt hat. NVD zitiert BU-69414, die Produktseite von DDCs MIL-STD-1553-Software — ein anderer Datenbus-Stack als der, den dieser Fund betrifft. ARINC 664 ist AFDX (profiliertes Switched Ethernet, ARINC 664 Teil 7); MIL-STD-1553 ist ein doppelt redundanter 1-Mbps-Befehl/Antwort-Bus. Es sind nicht verwandte Standards.

Die wahrscheinliche Ursache der Fehlzitation ist der Name der Ergebnisdatei. dataSIMS benennt die Ergebnisdatei des ARINC-664-Moduls milstd1553result.txt — ein Überbleibsel aus der MIL-STD-1553-Linie der Suite. Jeder, der die CVE-Beschreibung liest und nach einer passenden Herstellerproduktseite sucht, wird dieser Zeichenkette direkt zur 1553-Linie folgen, was offenbar auch geschehen ist. Der Dateiname ist kein Beleg für das betroffene Modul, und ein Eintrag, der auf die 1553-Produktseite verweist, veranlasst Verteidiger, die falsche Komponente zu prüfen.

2. Die beiden CVSS-Vektoren schließen sich gegenseitig aus

Beide Vektoren stammen von VulnCheck und widersprechen sich bei den beiden Dingen, die zählen:

Sie können nicht beide richtig sein. Der v4.0-Vektor ist der vertretbare: Der PoC demonstriert einen Absturz, keinen Vertraulichkeits- oder Integritätsverlust. Der v3.1-Score von 8.4 überzeichnet den Fund, und ich sage das lieber hier, als davon zu profitieren.

Reproduktion

Nichts hiervon benötigt die Zielsoftware — der PoC schreibt nur die fehlerhafte Datei. Das Auslösen des Überlaufs erfordert dataSIMS 4.5.3, lizenzierte kommerzielle Software, die dieses Repository nicht verteilt.

Lade dann die Datei mit dem betroffenen Build unter einem Debugger und beobachte das EIP-Überschreiben. poc/49577.py ist der ursprüngliche Python-2-Quellcode, unverändert archiviert; er läuft nicht auf Python 3.

Anmerkungen zu Python 2 → 3

Der Port erzeugt eine byte-identische 1040-Byte-Datei (sha256 530efb5e…). Drei Dinge mussten geändert werden, und eines, das wie ein Fehler aussieht, ist keiner:

• print len(win32) ist in Python 2 eine Anweisung, in Python 3 ein SyntaxError.
• Das Original verkettet str-Felder mit einem bytes-Shellcode. Python 2 erlaubte das, weil str bereits Bytes waren; Python 3 wirft TypeError.
• open(..., "w") muss zu "wb" werden. Im Textmodus würde Python 3 jedes Byte ≥ 0x80 im Stub UTF-8-kodieren — 0xda → 0xc3 0x9a — und damit den Payload stillschweigend korrumpieren und seine Länge verändern.
• imp2 = "\x61\x72\x61\x63\x61\x67\x131\x7a" ist keine versionsabhängige Eigenheit. \x akzeptiert in Python 2 und 3 genau zwei Hexadezimalziffern, also ist \x131 0x13 gefolgt vom Zeichen 1. Das Feld ist in beiden Fällen 9 Bytes lang. Es liest sich nur schlecht.

Einschränkungen

Explizit benannt, damit niemand raten muss, was getan wurde und was nicht:

• Keine Root-Cause-Analyse. Proprietäre Binärdatei; die überlaufende Funktion wurde nicht identifiziert.
• Kein Patch, keine Herstellerwarnung und kein Datensatz koordinierter Offenlegung — der Fund von 2020 ging direkt an Exploit-DB.
• Nicht erneut getestet gegen irgendeine Version nach 4.5.3 und nicht gegen aktuelle Windows-Gegenmaßnahmen getestet.
• Keine funktionierende Codeausführung. Das EIP-Überschreiben ist das gesamte Ergebnis.
• Die CVE wurde 2026 von einem Dritt-CNA retroaktiv vergeben, fünf Jahre nach der Veröffentlichung, ohne mich zu kontaktieren.

Zeitleiste

Referenzen

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

Danksagung

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

Artikel: Englisch · Türkçe