Resumo

O componente afetado é o módulo ARINC 664-1 do dataSIMS 4.5.3. Ele relê um arquivo de resultado que — apesar do módulo ao qual pertence — se chama milstd1553result.txt; o nome é um artefato do fornecedor herdado da linhagem MIL-STD-1553 do pacote, não uma indicação de qual módulo é afetado. Fornecer uma versão excessivamente longa desse arquivo, com formato definido por um atacante, estoura um buffer de pilha de tamanho fixo durante o caminho de releitura e sobrescreve o endereço de retorno salvo. A falha termina com controle total do EIP:

O PoC publicado tem 1040 bytes e para na sobrescrita do EIP. Ele não alcança execução de código, e nunca foi essa a intenção — veja Explorabilidade.

Anatomia do payload

O layout de campos do PoC, verificado ao executar a porta (py poc/poc_py3.py --layout):

O offset do EIP é 1007. Não é um número que você obtém do !mona findmsp ou do pattern_offset.rb — é a soma de cinco campos ajustados manualmente. O PoC original foi construído ampliando uma falha até o endereço de retorno se mover, não localizando o offset analiticamente. Estou registrando isso em vez de embelezar: uma reescrita limpa encontraria a distância real até o endereço de retorno salvo e eliminaria align, imp e imp2 por completo, já que nenhum deles carrega significado. imp/imp2 são strings de preenchimento, não imports.

O stub decodificador é inerte

buf é um stub msfvenom shikata_ga_nai de 29 bytes. Desmontado com ndisasm -b32:

Duas coisas decorrem disso, e ambas significam que o payload jamais poderá ser executado:

1. mov cl,0x1 — o loop de decodificação está configurado para um único bloco de 4 bytes. Não há payload real por trás dele, apenas esses 4 bytes.
2. O terminador \xe2\xf4 (loop) está ausente. Um stub sgn completo encerra o loop de decodificação com loop antes do corpo codificado. Aqui a execução cai direto de add ebx,[eax+0x15] em E9 8B 7C 9C — que naquele momento ainda está codificado e, de qualquer forma, não é uma sequência de instruções válida.

Portanto, o stub é um espaço reservado que ocupa a cauda do payload. Isso corresponde a como o PoC foi descrito no Exploit-DB, e é a leitura honesta: esta é uma demonstração de controle do EIP, não um exploit funcional.

Explorabilidade (avaliação honesta)

Avaliando isso como um corretor de exploits ou um fornecedor faria, em vez de como o vetor CVSS v3.1 o faz:

• Nenhuma fronteira de privilégio é cruzada. milstd1553result.txt é um arquivo que o próprio aplicativo produz, em um local que o mesmo usuário já controla. Um atacante que consiga reescrevê-lo geralmente já consegue executar código como esse usuário. Isso o torna um bug de robustez muito mais do que um bug de segurança.
• O PoC não antecede nada. O controle do EIP em um build x86 da era 2020 diz pouco por si só. Transformá-lo em execução exige uma estratégia de DEP/ASLR — um módulo sem /DYNAMICBASE, uma cadeia ROP ou uma sobrescrita parcial. Nada disso foi feito, e não verifiquei quais mitigações acompanham o build atual.
• É local e exige que o operador carregue o arquivo. O UI:A do CVSS v4.0 reflete a realidade; o UI:N do v3.1, não.

Se alguém quiser tornar isso genuinamente interessante, as superfícies produtivas não são, de modo algum, este arquivo: o driver de kernel que a DDC distribui para suas placas PCIe 1553/664 (manipulação de IOCTL → LPE), qualquer parse de quadros ARINC 664/AFDX voltado à rede e os formatos de arquivo de entrada que o pacote consome de fontes não confiáveis. Esses cruzam fronteiras reais. Este aqui, não.

Correções ao registro publicado

O registro do CVE carrega dois defeitos que valem ser declarados abertamente, já que está publicado sob o meu nome.

1. O produto do fornecedor citado é o errado

A designação de produto do registro — "dataSIMS Avionics ARINC 664-1 versão 4.5.3" — está correta. O componente afetado é o módulo ARINC 664, como consta no título original do meu Exploit-DB.

O defeito é a referência de fornecedor que a CNA anexou. A NVD cita BU-69414, que é a página de produto do software MIL-STD-1553 da DDC — uma pilha de databus diferente da que esta descoberta afeta. ARINC 664 é AFDX (Ethernet comutada com perfil, ARINC 664 Parte 7); MIL-STD-1553 é um barramento de comando/resposta duplamente redundante de 1 Mbps. São padrões sem relação entre si.

A causa provável da citação incorreta é o nome do arquivo de resultado. O dataSIMS nomeia o arquivo de resultado do módulo ARINC 664 como milstd1553result.txt — um resquício da linhagem MIL-STD-1553 do pacote. Qualquer pessoa que leia a descrição do CVE e procure uma página de produto correspondente do fornecedor seguirá essa string direto para a linha 1553, que é o que aparentemente aconteceu. O nome do arquivo não é evidência do módulo afetado, e um registro que aponta para a página do produto 1553 envia defensores para auditar o componente errado.

2. Os dois vetores CVSS são mutuamente exclusivos

Ambos os vetores vêm da VulnCheck e se contradizem nos dois pontos que importam:

Ambos não podem estar corretos. O vetor v4.0 é o defensável: o PoC demonstra uma falha, não divulgação ou perda de integridade. A pontuação 8.4 do v3.1 superestima a descoberta, e prefiro afirmar isso aqui a me beneficiar dela.

Reprodução

Nada aqui requer o software alvo — o PoC apenas grava o arquivo malformado. Disparar o estouro exige o dataSIMS 4.5.3, que é um software comercial licenciado que este repositório não distribui.

Em seguida, carregue o arquivo no build afetado sob um depurador e observe a sobrescrita do EIP. poc/49577.py é o código-fonte original em Python 2, arquivado na íntegra; ele não será executado no Python 3.

Notas sobre Python 2 → 3

A porta produz um arquivo byte-idêntico de 1040 bytes (sha256 530efb5e…). Três coisas precisaram mudar, e uma coisa que parece um bug não é:

• print len(win32) é uma instrução no Python 2 e um SyntaxError no Python 3.
• O original concatena campos str com um shellcode bytes. O Python 2 permitia porque str era bytes; o Python 3 levanta TypeError.
• open(..., "w") precisa se tornar "wb". Em modo texto, o Python 3 codificaria em UTF-8 cada byte ≥ 0x80 do stub — 0xda → 0xc3 0x9a — corrompendo silenciosamente o payload e alterando seu comprimento.
• imp2 = "\x61\x72\x61\x63\x61\x67\x131\x7a" não é uma peculiaridade dependente de versão. \x aceita exatamente dois dígitos hexadecimais tanto no Python 2 quanto no 3, então \x131 é 0x13 seguido do caractere 1. O campo tem 9 bytes em ambos. Apenas parece errado.

Limitações

Declarado explicitamente para que ninguém precise adivinhar o que foi feito e o que não foi:

• Nenhuma análise de causa-raiz. Binário de código fechado; a função que causa o estouro não foi identificada.
• Nenhum patch, nenhum aviso do fornecedor e nenhum registro de divulgação coordenada — a descoberta de 2020 foi direto para o Exploit-DB.
• Não foi retestado em nenhuma versão após a 4.5.3 nem testado contra as mitigações atuais do Windows.
• Nenhuma execução de código funcional. A sobrescrita do EIP é o resultado completo.
• O CVE foi atribuído retroativamente em 2026 por uma CNA terceirizada, cinco anos após a publicação, sem contato comigo.

Linha do tempo

Referências

• 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álises: English · Türkçe