Это тестовые примеры отказа в обслуживании/потребления ресурсов, а не продемонстрированные эксплойты выполнения кода. Запускайте их только в изолированной, ограниченной тестовой среде.

Бинарная инструментация BLARE2

media-gen — это слой воспроизводимости, а не то, как эти примеры были обнаружены. Сложной частью было найти и доказать поведение внутри большого нативного исполняемого файла Discord и его встроенных медиабиблиотек. blare2 сделал это практичным, переписав изолированную копию точной среды выполнения и позволив узким пробам наблюдать за исполнением без изменения установленного приложения.

Для примера WebM семантическая проба blare2 остановилась точно на проверке AudioDiscardHelper::ProcessBuffers и зафиксировала состояние сбоя: discarded_frames = 129 и decoder_delay = 128. Без этого наблюдения выход рендерера с STATUS_BREAKPOINT лишь указал бы на общую проверку релиза; он не установил бы, какой медиаинвариант нарушен или действительно ли сконструированное заполнение до него дошло.

Для примера M4A крупные выделения памяти являются временными и могут исчезнуть до взятия обычной выборки процесса. Покрытие точной среды выполнения и целевая инструментация blare2 в сочетании с высокочастотной выборкой процессов и дизассемблированием показали, что крошечный файл достиг построителя таблицы образцов MOV и что объявленное количество масштабировало выделения AVIndexEntry и таблицы таймингов. Это отделило проблему от обычного сбоя декодирования AAC или вводящей в заблуждение корреляции размера файла/OOM. Одного широкого покрытия точек входа функций было недостаточно: файлы с низким и высоким count проходили через одни и те же функции, тогда как размеры их выделений радикально различались.

blare2 не заменил анализ контейнера, обзор исходного кода или контроли и не доказал, что производственный путь загрузки/CDN Discord сохраняет эти байты. Его ценность была в атрибуции во время выполнения: он превратил подозрительное поведение парсера в воспроизводимую, привязанную к версии находку с точным состоянием сбоя и обоснованным объяснением выделения памяти. Без бинарной инструментации такого рода поиск этих двух примеров был бы существенно медленнее и гораздо труднее поддавался бы проверке.

Сборка

Из корня репозитория:

Бинарный файл — target/release/media-gen (media-gen.exe в Windows). Самому генератору нужны только Rust и зависимости в Cargo.toml.

Сбой отбрасывания двух версий WebM/Vorbis

Что его вызывает

Отрицательный DiscardPadding в Matroska становится фронтальным пропуском Vorbis. Старый путь Vorbis в Chromium задерживает эти метаданные на один закодированный пакет; текущий Chromium применяет их к текущему декодированному выводу и отбрасывает метаданные пакета 0, когда этот прайминг-пакет не выдаёт PCM. Повторение одного большого пропуска на пакетах 0 и 1 связывает оба поведения:

Дорожка имеет CodecDelay в 128 кадров. В старом режиме с задержкой пропуск пакета 0 в 577 кадров применяется к пакету 1. В текущем режиме пропуск пакета 0 отбрасывается, а идентичный пропуск пакета 1 применяется напрямую. В любом случае после смещения задержки кодека можно удалить только 448 кадров, поэтому 129 кадров переносятся в пакет 2. Его положительный фронтальный пропуск достигает проверки релиза Chromium после того, как эти 129 кадров уже удалены. Требуемый инвариант — discarded_frames <= decoder_delay; 129 <= 128 не выполняется и завершает рендерер.

Генератор разбирает заголовки настройки Vorbis, вычисляет декодированные размеры пакетов 1 и 2 и отказывает безопасно, если мост нежизнеспособен. Затем он:

• преобразует первые три аудиоэлемента SimpleBlock в элементы BlockGroup;
• записывает общий отрицательный DiscardPadding на пакетах 0 и 1 и положительный триггер в один кадр на пакете 2;
• сохраняет закодированные аудио- и видеополезные нагрузки; и
• заменяет устаревшие элементы SeekHead, Cues и затронутые CRC кластеров, чтобы перезаписанный контейнер оставался разбираемым.

Манифест сообщает о немедленном и отложенном путях отдельно. Для включённого в репозиторий образца оба пути называют пакет 2 проверочным пакетом и сообщают expected_carry_frames: 129 и expected_check_fails: true.

Создание кандидата

Репозиторий содержит контрольный WebM длительностью 43 мс и размером 4 185 байт:

Входные данные должны содержать:

• дорожку A_VORBIS;
• положительный CodecDelay (обычно считывается из дорожки); и
• как минимум три аудиопакета, режимы Vorbis которых можно декодировать;
• вывод пакета 1 больше задержки кодека; и
• вывод пакета 2 больше вычисленного переноса.

Полезные опции — --trigger-skip, --codec-delay и --sample-rate. --second-skip остаётся псевдонимом для переименованной опции --trigger-skip. Значения по умолчанию — это значения, необходимые для известного состояния сбоя. Команда выводит JSON-отчёт в stdout и записывает тот же отчёт в --manifest, когда эта опция указана.

Включённый в репозиторий кандидат имеет длительность 43 мс и размер 4 206 байт. Его SHA-256:

Ожидается, что хеш вывода изменится, если изменятся входные данные, окно пакетов или опции.

Выделение памяти при постоянном количестве образцов M4A

Что его вызывает

Пример M4A злоупотребляет корректной формой таблицы образцов MP4, а не закодированной полезной нагрузкой AAC. Генератор изменяет seed следующим образом:

1. Он заменяет явный массив размеров образцов stsz на sample_size = 1.
2. Он устанавливает объявленное количество образцов в stsz, первом прогоне stsc и первом прогоне stts в одно и то же большое значение.
3. Он удаляет старые явные записи размеров и исправляет размеры родительских боксов.
4. Он исправляет абсолютное смещение stco, чтобы однобайтовая полезная нагрузка AAC по-прежнему указывала внутрь mdat.

Зафиксированный демультиплексор FFmpeg считает объявленное количество авторитетным при построении своих таблиц индекса и таймингов. Соответствующие структуры используют примерно 24 байта на объявленный образец для AVIndexEntry и 12 байт на образец для данных таймингов: всего 36 байт на запись count. Максимальное принимаемое количество в протестированной сборке — 178,956,969 (0x0AAAAAA9), что проецируется в:

Точный рендерер Discord достиг пика приватной памяти в 6 614 761 472 байта при загрузке метаданных. Соседнее значение count 178,956,970 отклоняется зафиксированной границей FFmpeg и остаётся вблизи нормального объёма памяти. Это неконтролируемое потребление ресурсов (CWE-400), а не наблюдаемое целочисленное переполнение, выделение отрицательного размера или запись за границы. Фактическая полезная нагрузка AAC может быть усечена; успешное воспроизведение не требуется для достижения крупного выделения.

Создание кандидата

Генератор намеренно принимает seed вместо встраивания кодировщика AAC. Используйте fast-start файл AAC/M4A с одной явной таблицей stsz, одним прогоном stsc, одной или несколькими записями stts и смещениями чанков stco. Он отказывает безопасно, если требуемая структура отсутствует.

Значение по умолчанию --sample-count — 178956969, максимальное принимаемое значение в зафиксированной сборке. Используйте меньшее значение для дымового теста с низким потреблением памяти, например:

--sample-count 178956970 — полезный соседний контроль отклонения, а не триггерное значение. Необязательный флаг --moov-at-end перемещает moov после mdat и обновляет stco/co64; он полезен при тестировании файла, физические байты AAC которого находятся перед его метаданными, но он не требуется для механизма выделения памяти.

Чтобы явно создать такую компоновку:

Соответствующие артефакты — samples/short-vorbis-dual-control.webm, samples/short-vorbis-dual-crash.webm, и samples/short-vorbis-dual-crash.json.