Краткое описание

Затронутый компонент — модуль ARINC 664-1 в dataSIMS 4.5.3. Он считывает файл результатов, который — несмотря на модуль, к которому он относится, — называется milstd1553result.txt; это имя — артефакт вендора, доставшийся от линии MIL-STD-1553 этого пакета, а не указание на то, какой модуль затронут. Подача чрезмерно длинной версии этого файла, сформированной атакующим, переполняет буфер стека фиксированного размера на пути чтения и перезаписывает сохранённый обратный адрес. Крах происходит при полном контроле над EIP:

Опубликованный PoC имеет размер 1040 байт и останавливается на перезаписи EIP. Он не достигает выполнения кода и никогда не был для этого предназначен — см. Эксплуатируемость.

Анатомия полезной нагрузки

Раскладка полей PoC, проверенная запуском порта (py poc/poc_py3.py --layout):

Смещение до EIP — 1007. Это не число, которое вы получите от !mona findmsp или pattern_offset.rb, — это сумма пяти полей, настроенных вручную. Оригинальный PoC был собран путём расширения данных до тех пор, пока не сдвинулся обратный адрес, а не путём аналитического определения смещения. Я отмечаю это, а не приукрашиваю: аккуратный переписанный вариант нашёл бы истинное расстояние до сохранённого обратного адреса и полностью отбросил бы align, imp и imp2, поскольку ни одно из них не несёт смысла. imp/imp2 — это строки-заполнители, а не импорты.

Заглушка-декодер инертна

buf — это 29-байтная заглушка shikata_ga_nai от msfvenom. Дизассемблировано с помощью ndisasm -b32:

Из этого вытекают две вещи, и обе означают, что полезная нагрузка никогда не сможет выполниться:

1. mov cl,0x1 — цикл декодирования настроен на один 4-байтный блок. За ним нет реальной полезной нагрузки, только эти 4 байта.

2. Терминатор \xe2\xf4 (loop) отсутствует. Полная заглушка sgn завершает цикл декодирования инструкцией loop перед закодированным телом. Здесь выполнение падает прямо с add ebx,[eax+0x15] на E9 8B 7C 9C — которая в этот момент всё ещё закодирована и в любом случае не является валидной последовательностью инструкций.

Итак, заглушка — это заполнитель, занимающий хвост полезной нагрузки. Это соответствует тому, как PoC был описан на Exploit-DB, и это честное прочтение: это демонстрация контроля над EIP, а не рабочий эксплойт.

Эксплуатируемость (честная оценка)

Оценивая это так, как это сделал бы брокер или вендор, а не так, как вектор CVSS v3.1:

• Ни одна граница привилегий не пересекается. milstd1553result.txt — это файл, который создаёт само приложение, в месте, которым тот же пользователь уже управляет. Атакующий, способный перезаписать его, как правило, уже может выполнять код от имени этого пользователя. Это делает данную ошибку скорее ошибкой надёжности, чем ошибкой безопасности.

• PoC не опережает время. Контроль над EIP в x86-сборке эпохи 2020 года сам по себе мало о чём говорит. Превращение его в выполнение кода требует истории с DEP/ASLR — модуля без /DYNAMICBASE, ROP-цепочки или частичной перезаписи. Ничего из этого не было сделано, и я не проверял, с какими механизмами смягчения поставляется текущая сборка.

• Она локальна и требует, чтобы оператор загрузил файл. UI:A в CVSS v4.0 отражает реальность; UI:N в v3.1 — нет.

Если кто-то хочет сделать это по-настоящему интересным, продуктивные поверхности атаки — вовсе не этот файл: драйвер ядра, который DDC поставляет для своих PCIe-карт 1553/664 (обработка IOCTL → LPE), любой сетевой разбор кадров ARINC 664/AFDX и входные форматы файлов, которые пакет потребляет из недоверенных источников. Они пересекают реальные границы. Этот — нет.

Исправления к опубликованной записи

В записи CVE есть два дефекта, о которых стоит сказать прямо, поскольку она опубликована под моим именем.

1. Указанный продукт вендора — не тот

Обозначение продукта в записи — "dataSIMS Avionics ARINC 664-1 версия 4.5.3" — корректно. Затронутый компонент — модуль ARINC 664, как указано в моём оригинальном заголовке на Exploit-DB.

Дефект — в ссылке на вендора, которую прикрепил CNA. NVD ссылается на BU-69414, что является страницей программного продукта DDC MIL-STD-1553 — другого стека databus, не того, которого касается эта находка. ARINC 664 — это AFDX (профилированный коммутируемый Ethernet, ARINC 664 Part 7); MIL-STD-1553 — это двухрезервированная шина «команда/ответ» со скоростью 1 Мбит/с. Это несвязанные стандарты.

Вероятная причина неверной ссылки — имя файла результатов. 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 — лицензионное коммерческое ПО, которое этот репозиторий не распространяет.

Затем загрузите файл в затронутой сборке под отладчиком и наблюдайте перезапись EIP. poc/49577.py — это оригинальный исходник на Python 2, заархивированный дословно; на Python 3 он не запустится.

Примечания по Python 2 → 3

Порт создаёт байт-идентичный файл размером 1040 байт (sha256 530efb5e…). Три вещи пришлось изменить, и одна вещь, которая выглядит как баг, багом не является:

• print len(win32) — это оператор (statement) в Python 2 и SyntaxError в Python 3.
• Оригинал конкатенирует поля str с шеллкодом bytes. Python 2 позволял это, потому что str и был байтами; Python 3 вызывает TypeError.
• open(..., "w") должен стать "wb". В текстовом режиме Python 3 кодировал бы в UTF-8 каждый байт ≥ 0x80 в заглушке — 0xda → 0xc3 0x9a — незаметно повреждая полезную нагрузку и меняя её длину.
• imp2 = "\x61\x72\x61\x63\x61\x67\x131\x7a" — это не причуда, зависящая от версии. \x принимает ровно две шестнадцатеричные цифры и в Python 2, и в Python 3, поэтому \x131 — это 0x13, за которым следует символ 1. Поле занимает 9 байт в обоих случаях. Просто читается оно плохо.

Ограничения

Изложено явно, чтобы никому не пришлось гадать, что было сделано, а что нет:

• Нет анализа первопричины. Бинарь с закрытым исходным кодом; переполняющаяся функция не идентифицирована.
• Нет патча, нет уведомления вендора и нет записи о скоординированном раскрытии — находка 2020 года ушла напрямую на Exploit-DB.
• Не перепроверялось ни на одном релизе после 4.5.3 и не тестировалось против текущих механизмов смягчения Windows.
• Нет работающего выполнения кода. Перезапись EIP — это весь результат.
• CVE был присвоен задним числом в 2026 году сторонним 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

Разборы: Английский · Турецкий