CVE-2021-47881

dataSIMS Avionics ARINC 4.5.3(Data Device Corporation)의 로컬 스택 기반 버퍼 오버플로

안녕하세요, Kağan Çapar입니다. 2020년 2월 저는 DDC의 dataSIMS 항공 전자 데이터버스 소프트웨어에서 로컬 스택 기반 버퍼 오버플로를 발견했고, 2021년 2월 Exploit-DB에 개념 증명(PoC)을 공개했습니다. 약 5년 후인 2026년 1월, VulnCheck는 이 발견에 CVE-2021-47881을 소급 CVE로 지정했습니다 — 저는 그 지정 사실을 사후에 알게 되었으며, VulnCheck로부터 통보받은 것은 아닙니다.

이 저장소는 해당 발견에 대한 기록 보관 자료입니다: 공개 당시 그대로 보존된 원본 PoC, 바이트 단위로 동일한 Python 3 포트, 페이로드에 대한 주석이 포함된 상세 분석, 그리고 공개된 CVE 기록의 두 가지 문제점에 대한 정정입니다.

범위를 먼저 분명히 합니다. 이것은 기록이지 근본 원인 분석이 아닙니다. dataSIMS는 폐쇄형 상용 소프트웨어이고, 공급업체 패치는 없으며, 현재 릴리스를 대상으로 재테스트하지도 않았습니다. 여기서 검증 가능한 것은 검증되어 제시되었고, 그 외의 모든 것은 한계에서 명시합니다. CVE-2026-5201 수준의 깊이를 기대하고 오셨다면, 먼저 그 참고 사항을 읽어보시기 바랍니다.

요약

영향을 받는 구성 요소는 dataSIMS 4.5.3의 ARINC 664-1 모듈입니다. 이 모듈은 결과 파일을 읽어오는데, 그 파일은 — ARINC 664 모듈에 속함에도 불구하고 — milstd1553result.txt라는 이름을 갖고 있습니다. 이 이름은 어느 모듈이 영향받는지를 나타내는 표시가 아니라, 제품군의 MIL-STD-1553 계열에서 이어져 내려온 공급업체의 잔재입니다. 공격자가 조작한 과도하게 긴 버전의 해당 파일을 공급하면, 읽어오는 경로에서 고정 크기 스택 버퍼가 오버플로되어 저장된 복귀 주소가 덮어써집니다. 크래시는 EIP를 완전히 제어한 상태로 발생합니다:

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

공개된 PoC는 1040바이트이며 EIP 덮어쓰기에서 멈춥니다. 코드 실행까지는 이루어지지 않으며, 그렇게 의도된 적도 없습니다 — 익스플로잇 가능성을 참조하세요.

페이로드 구조

포트 버전을 실행하여(py poc/poc_py3.py --layout) 검증한 PoC의 필드 배치:

EIP 오프셋은 1007입니다. 이것은 !mona findmsp나 pattern_offset.rb로 얻을 수 있는 숫자가 아니라, 수작업으로 조정한 다섯 필드의 합입니다. 원본 PoC는 오프셋을 분석적으로 찾는 대신, 복귀 주소가 이동할 때까지 크래시를 확장하는 방식으로 제작되었습니다. 저는 이것을 포장하지 않고 있는 그대로 밝힙니다: 새로 깔끔하게 작성한다면 저장된 복귀 주소까지의 실제 거리를 찾아낼 수 있고, align, imp, imp2는 어느 것도 의미를 담고 있지 않으므로 완전히 제거할 수 있습니다. imp/imp2는 임포트가 아니라 채움 문자열입니다.

디코더 스텁은 비활성 상태

buf는 29바이트 msfvenom shikata_ga_nai 스텁입니다. 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

여기서 두 가지 사실이 도출되며, 둘 다 이 페이로드는 결코 실행될 수 없음을 의미합니다:

1. mov cl,0x1 — 디코드 루프가 단일 4바이트 블록용으로 구성되어 있습니다. 그 뒤에는 실제 페이로드가 없고, 그 4바이트만 있을 뿐입니다.
2. \xe2\xf4(loop) 종결자가 없습니다. 완전한 sgn 스텁은 인코딩된 본문 앞에서 loop로 디코드 루프를 종료합니다. 여기서는 실행이 add ebx,[eax+0x15]에서 곧바로 E9 8B 7C 9C로 흘러갑니다 — 그 지점은 그 시점에 여전히 인코딩되어 있고, 어차피 유효한 명령어 시퀀스도 아닙니다.

따라서 이 스텁은 페이로드의 꼬리를 차지하는 자리 표시자입니다. 이것은 Exploit-DB에서 PoC가 설명된 방식과 일치하며, 솔직한 해석이기도 합니다: 이것은 EIP 제어 시연이지, 작동하는 익스플로잇이 아닙니다.

익스플로잇 가능성 (솔직한 평가)

CVSS v3.1 벡터가 하는 방식이 아니라, 브로커나 공급업체가 하는 방식으로 이를 평가해 보면:

• 권한 경계를 넘지 않습니다. milstd1553result.txt는 응용 프로그램 자체가 생성하는 파일이며, 동일한 사용자가 이미 제어할 수 있는 위치에 있습니다. 이 파일을 다시 쓸 수 있는 공격자는 일반적으로 이미 그 사용자 권한으로 코드를 실행할 수 있습니다. 따라서 이것은 보안 버그라기보다 견고성 버그에 훨씬 가깝습니다.
• PoC는 그 어떤 것보다 앞서지 않습니다. 2020년대 x86 빌드에서 EIP를 제어한다는 것은 그 자체로 큰 의미가 없습니다. 이것을 코드 실행으로 전환하려면 DEP/ASLR 우회 전략 — /DYNAMICBASE가 없는 모듈, ROP 체인, 또는 부분 덮어쓰기 — 이 필요합니다. 그 어느 것도 수행되지 않았고, 현재 빌드에 어떤 완화 조치가 포함되어 있는지도 확인하지 않았습니다.
• 로컬 취약점이며, 운영자가 파일을 로드해야 합니다. CVSS v4.0의 UI:A는 현실을 반영하고, v3.1의 UI:N은 그렇지 않습니다.

누군가 이 취약점을 진정으로 흥미롭게 만들고 싶다면, 생산적인 표면은 이 파일이 전혀 아닙니다: DDC가 1553/664 PCIe 카드용으로 제공하는 커널 드라이버(IOCTL 처리 → LPE), 네트워크에 노출된 ARINC 664/AFDX 프레임 파싱, 그리고 제품군이 신뢰할 수 없는 소스에서 소비하는 입력 파일 형식입니다. 그것들은 실제 경계를 넘어섭니다. 이 취약점은 그렇지 않습니다.

공개 기록에 대한 정정

CVE 기록에는 분명히 밝혀야 할 두 가지 결함이 있습니다. 제 이름으로 공개된 것이기 때문입니다.

1. 인용된 공급업체 제품이 잘못되었습니다

기록의 제품 지정 — "dataSIMS Avionics ARINC 664-1 버전 4.5.3" — 은 정확합니다. 영향받는 구성 요소는 제 원래 Exploit-DB 제목에 명시된 대로 ARINC 664 모듈입니다.

문제는 CNA가 첨부한 공급업체 참조입니다. NVD는 BU-69414를 인용하는데, 이는 DDC의 MIL-STD-1553 소프트웨어 제품 페이지입니다 — 이 발견이 영향을 미치는 스택과는 다른 데이터버스 스택입니다. ARINC 664는 AFDX(프로파일링된 스위치드 이더넷, ARINC 664 Part 7)이고, MIL-STD-1553은 1Mbps 이중화 명령/응답 버스입니다. 두 가지는 무관한 표준입니다.

잘못된 인용의 가능한 원인은 결과 파일 이름입니다. dataSIMS는 ARINC 664 모듈의 결과 파일을 milstd1553result.txt로 명명합니다 — 제품군의 MIL-STD-1553 계열에서 남겨진 잔재입니다. CVE 설명을 읽고 일치하는 공급업체 제품 페이지를 찾는 사람은 누구든 그 문자열을 따라 곧바로 1553 제품군으로 가게 되며, 실제로 그렇게 된 것으로 보입니다. 파일 이름은 영향받는 모듈의 증거가 아니며, 1553 제품 페이지를 가리키는 기록은 방어자가 잘못된 구성 요소를 감사하도록 만듭니다.

2. 두 CVSS 벡터는 상호 배타적입니다

두 벡터 모두 VulnCheck에서 나온 것이며, 중요한 두 가지 측면에서 서로 모순됩니다:

둘 다 맞을 수는 없습니다. v4.0 벡터가 방어 가능한 쪽입니다: PoC는 크래시를 입증할 뿐, 기밀성 침해나 무결성 손실을 입증하지 않습니다. v3.1의 8.4점은 이 발견을 과장하며, 저는 그것으로 이득을 보기보다 여기서 이렇게 밝히는 편이 낫습니다.

재현

여기에는 대상 소프트웨어가 필요하지 않습니다 — PoC는 변조된 파일을 작성할 뿐입니다. 오버플로를 트리거하려면 dataSIMS 4.5.3이 필요한데, 이는 이 저장소에서 배포하지 않는 라이선스 상용 소프트웨어입니다.

# 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

그런 다음 디버거에서 영향받는 빌드로 파일을 로드하고 EIP 덮어쓰기를 관찰하세요. poc/49577.py는 원문 그대로 보존된 원본 Python 2 소스입니다. Python 3에서는 실행되지 않습니다.

Python 2 → 3 참고 사항

포팅 결과 바이트 단위로 동일한 1040바이트 파일(sha256 530efb5e…)이 생성됩니다. 세 가지가 변경되어야 했고, 버그처럼 보이는 한 가지는 실제로 버그가 아닙니다:

• print len(win32)는 Python 2에서는 문장이고 Python 3에서는 SyntaxError입니다.
• 원본은 str 필드와 bytes 셸코드를 연결합니다. Python 2는 str이 곧 bytes였기 때문에 허용했지만, Python 3는 TypeError를 발생시킵니다.
• open(..., "w")는 "wb"가 되어야 합니다. 텍스트 모드에서 Python 3는 스텁의 0x80 이상의 모든 바이트를 UTF-8로 인코딩합니다 — 0xda → 0xc3 0x9a — 페이로드를 조용히 손상시키고 길이를 변경합니다.
• imp2 = "\x61\x72\x61\x63\x61\x67\x131\x7a"는 버전 종속적인 특이점이 아닙니다. \x는 Python 2와 3 모두에서 정확히 두 자리 16진수를 취하므로 \x131은 뒤에 문자 이 오는 것입니다. 필드는 두 경우 모두 9바이트입니다. 단지 읽기에 좋지 않을 뿐입니다.

한계

무엇이 수행되었고 수행되지 않았는지 누구도 추측할 필요 없도록 명시적으로 밝힙니다:

• 근본 원인 분석 없음. 폐쇄형 소스 바이너리이며, 오버플로가 발생하는 함수는 식별되지 않았습니다.
• 패치도, 공급업체 권고도, 조정된 공개 기록도 없음 — 2020년 발견은 곧바로 Exploit-DB로 공개되었습니다.
• 4.5.3 이후의 어떤 릴리스에서도 재테스트되지 않았으며, 현재 Windows 완화 조치에 대해서도 테스트되지 않았습니다.
• 작동하는 코드 실행 없음. EIP 덮어쓰기가 결과의 전부입니다.
• CVE는 공개 5년 후인 2026년에 제3자 CNA에 의해 소급 지정되었으며, 저에게 연락하지 않았습니다.

타임라인

참고 자료

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

크레딧

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

분석 글: English · Türkçe