CVE-2021-47881

Desbordamiento de búfer local basado en pila en dataSIMS Avionics ARINC 4.5.3 (Data Device Corporation)

Hola, soy Kağan Çapar. En febrero de 2020 encontré un desbordamiento de búfer local basado en pila en el software de bus de datos de aviónica dataSIMS de DDC y publiqué una prueba de concepto en Exploit-DB en febrero de 2021. Casi cinco años después, en enero de 2026, VulnCheck le asignó el CVE-2021-47881 como CVE retroactivo — me enteré de la asignación después de los hechos, no por parte de ellos.

Este repositorio es el registro de archivo de ese hallazgo: el PoC original conservado tal como se publicó, un port a Python 3 byte-idéntico, un desglose anotado del payload y correcciones para dos problemas en el registro CVE publicado.

Alcance, por adelantado. Esto es un registro, no un análisis de causa raíz. dataSIMS es software comercial de código cerrado, no hay parche del proveedor y no he vuelto a probar esto contra una versión actual. Lo que es verificable aquí está verificado y mostrado; todo lo demás se indica en Limitaciones. Si viniste esperando la profundidad de CVE-2026-5201, lee esa nota primero.

Resumen

El componente afectado es el módulo ARINC 664-1 de dataSIMS 4.5.3. Este lee un archivo de resultados que — a pesar del módulo al que pertenece — se llama milstd1553result.txt; el nombre es un artefacto del proveedor heredado del linaje MIL-STD-1553 de la suite, no una indicación de qué módulo está afectado. Suministrar una versión excesivamente larga y moldeada por un atacante de ese archivo desborda un búfer de pila de tamaño fijo durante la ruta de lectura y sobrescribe la dirección de retorno guardada. El fallo aterriza con control total de EIP:

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

El PoC publicado tiene 1040 bytes y se detiene en la sobrescritura de EIP. No logra ejecución de código, y nunca fue su intención — consulte Explotabilidad.

Anatomía del payload

El diseño de campos del PoC, verificado ejecutando el port (py poc/poc_py3.py --layout):

El desplazamiento de EIP es 1007. Ese no es un número que se obtenga de !mona findmsp o pattern_offset.rb — es la suma de cinco campos ajustados a mano. El PoC original se construyó ensanchando un fallo hasta que la dirección de retorno se moviera, no localizando el desplazamiento analíticamente. Lo señalo en lugar de maquillarlo: una reescritura limpia encontraría la distancia real a la dirección de retorno guardada y eliminaría por completo align, imp e imp2, ya que ninguno tiene significado. imp/imp2 son cadenas de relleno, no importaciones.

El stub del decodificador es inerte

buf es un stub de shikata_ga_nai de msfvenom de 29 bytes. Desensamblado 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

De esto se desprenden dos cosas, y ambas significan que el payload nunca puede ejecutarse:

1. mov cl,0x1 — el bucle de decodificación está configurado para un único bloque de 4 bytes. No hay un payload real detrás, solo esos 4 bytes.
2. El terminador \xe2\xf4 (loop) está ausente. Un stub sgn completo termina el bucle de decodificación con loop antes del cuerpo codificado. Aquí la ejecución cae directamente de add ebx,[eax+0x15] a E9 8B 7C 9C — que en ese momento aún está codificado y, de todos modos, no es una secuencia de instrucciones válida.

Así que el stub es un marcador de posición que ocupa la cola del payload. Esto coincide con cómo se describió el PoC en Exploit-DB, y es la lectura honesta: esto es una demostración de control de EIP, no un exploit funcional.

Explotabilidad (evaluación honesta)

Ponderando esto como lo haría un corredor o un proveedor, en lugar de como lo hace el vector CVSS v3.1:

• No se cruza ningún límite de privilegios. milstd1553result.txt es un archivo que la propia aplicación produce, en una ubicación que el mismo usuario ya controla. Un atacante que pueda reescribirlo generalmente ya puede ejecutar código como ese usuario. Esto lo convierte en un bug de robustez mucho más que en un bug de seguridad.
• El PoC no supone ningún avance. El control de EIP en una compilación x86 de la era 2020 dice poco por sí solo. Convertirlo en ejecución requiere una historia de DEP/ASLR — un módulo sin /DYNAMICBASE, una cadena ROP o una sobrescritura parcial. Nada de eso se hizo, y no he comprobado qué mitigaciones incluye la compilación actual.
• Es local y necesita que el operador cargue el archivo. El UI:A de CVSS v4.0 refleja la realidad; el UI:N de v3.1 no.

Si alguien quiere hacer que esto sea genuinamente interesante, las superficies productivas no son este archivo en absoluto: el controlador de kernel que DDC distribuye para sus tarjetas PCIe 1553/664 (manejo de IOCTL → LPE), cualquier análisis de tramas ARINC 664/AFDX expuesto a red y los formatos de archivo de entrada que la suite consume de fuentes no confiables. Esas cruzan límites reales. Este no.

Correcciones al registro publicado

El registro CVE tiene dos defectos que vale la pena señalar sin rodeos, ya que se publica bajo mi nombre.

1. El producto del proveedor citado es el incorrecto

La designación de producto del registro — "dataSIMS Avionics ARINC 664-1 versión 4.5.3" — es correcta. El componente afectado es el módulo ARINC 664, como se indica en el título original de mi Exploit-DB.

El defecto es la referencia al proveedor que adjuntó el CNA. NVD cita BU-69414, que es la página de producto del software MIL-STD-1553 de DDC — una pila de databus diferente de la que afecta este hallazgo. ARINC 664 es AFDX (Ethernet conmutada perfilada, ARINC 664 Parte 7); MIL-STD-1553 es un bus de comando/respuesta redundante dual de 1 Mbps. Son estándares no relacionados.

La causa probable de la cita incorrecta es el nombre del archivo de resultados. dataSIMS nombra el archivo de resultados del módulo ARINC 664 como milstd1553result.txt — un remanente del linaje MIL-STD-1553 de la suite. Cualquiera que lea la descripción del CVE y busque una página de producto del proveedor que coincida seguirá esa cadena directamente hasta la línea 1553, que es lo que parece haber sucedido. El nombre del archivo no es evidencia del módulo afectado, y un registro que apunta a la página de producto 1553 envía a los defensores a auditar el componente equivocado.

2. Los dos vectores CVSS son mutuamente excluyentes

Ambos vectores provienen de VulnCheck y se contradicen entre sí en las dos cosas que importan:

No pueden ser correctos ambos. El vector v4.0 es el defendible: el PoC demuestra un fallo, no una divulgación o pérdida de integridad. La puntuación v3.1 de 8.4 exagera el hallazgo, y prefiero decirlo aquí antes que beneficiarme de ello.

Reproducción

Nada de aquí necesita el software objetivo — el PoC solo escribe el archivo malformado. Para desencadenar el desbordamiento se requiere dataSIMS 4.5.3, que es software comercial con licencia y que este repositorio no distribuye.

# 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

Luego cargue el archivo con la compilación afectada bajo un depurador y observe la sobrescritura de EIP. poc/49577.py es el código fuente original en Python 2, archivado textualmente; no se ejecutará en Python 3.

Notas de Python 2 → 3

El port produce un archivo de 1040 bytes byte-idéntico (sha256 530efb5e…). Tres cosas tuvieron que cambiar, y una cosa que parece un bug no lo es:

• print len(win32) es una declaración en Python 2, un SyntaxError en Python 3.
• El original concatena campos str con un shellcode bytes. Python 2 lo permitía porque str era bytes; Python 3 lanza TypeError.
• open(..., "w") debe convertirse en "wb". En modo texto, Python 3 codificaría en UTF-8 cada byte ≥ 0x80 del stub — 0xda → 0xc3 0x9a — corrompiendo silenciosamente el payload y cambiando su longitud.
• imp2 = "\x61\x72\x61\x63\x61\x67\x131\x7a" no es una peculiaridad dependiente de la versión. \x toma exactamente dos dígitos hexadecimales tanto en Python 2 como en 3, por lo que es seguido del carácter . El campo es de 9 bytes en ambos. Simplemente se lee mal.

Limitaciones

Se indica explícitamente para que nadie tenga que adivinar qué se hizo y qué no:

• Sin análisis de causa raíz. Binario de código cerrado; la función que se desborda no ha sido identificada.
• Sin parche, sin aviso del proveedor y sin registro de divulgación coordinada — el hallazgo de 2020 fue directamente a Exploit-DB.
• No re-probado en ninguna versión posterior a 4.5.3, y no probado contra las mitigaciones actuales de Windows.
• Sin ejecución de código funcional. La sobrescritura de EIP es todo el resultado.
• El CVE fue asignado retroactivamente en 2026 por un CNA de terceros, cinco años después de la publicación, sin contactarme.

Cronología

Referencias

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

Créditos

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

Análisis: English · Türkçe