gdcm-security-poc

Приватный пакет для воспроизведения сквозной санитизации по шести находкам GDCM

master — это датированный снимок, а не движущаяся ветка. Обе ревизии доступны из публичного репозитория, поэтому bootstrap.sh может подготовить любую из них без приватных исходников.

Область результатов

Доказательства времени выполнения в этом репозитории относятся к v3.2.6. Более широкие диапазоны ниже получены из инспекции истории исходников; затронутые паттерны также остаются в закреплённом снимке master.

Содержимое

• fixtures/ — инертные входные данные DICOM, закреплённые по SHA-256 в manifest/expectations.json и проверяемые перед каждым запуском триггера
• generators/ — детерминированные генераторы исходников без зависимостей для каждого фикстура
• harnesses/ — минимальные обвязки чтения/кодирования/декодирования; Результат 2 показан как через CLI gdcmconv, так и через библиотечный API транскодирования, который вызвал бы сервер
• manifest/expectations.json — машиночитаемые команды, решающие сигналы и критерии приёмки для цели fixed
• scripts/ — подготовка закреплённых исходников, сборки с санитайзерами, ограниченное выполнение, очистка
• evidence/ — краткие уже наблюдавшиеся результаты с явным указанием непроверенных целей
• LICENSE — лицензия MIT

Предварительные требования

Одноразовая среда сборки Linux или macOS с Git, Python 3, CMake 3.20+, Ninja и инструментальной цепочкой C++11 (Clang или GCC). В Ubuntu: git python3 cmake ninja-build clang zlib1g-dev. Установите CC/CXX, чтобы использовать GCC вместо этого.

Подготовка исходников клонирует по HTTPS, если GDCM_SOURCE_REPO не указывает на существующий локальный клон. SSH-хост не используется.

Подготовка и сборка

Эти команды подготавливают только исходники и артефакты сборки; они не открывают никакой фикстур.

Третий аргумент — это профиль. debug — это -O0 -g; release — это -O2 -g -DNDEBUG, что исключает gdcm_debug_assert() из GDCM и соответствует тому, как дистрибутивы собирают библиотеку. Запуск матрицы под обоими отвечает на первый вопрос, который задаёт сопровождающий, а именно: являются ли отчёты артефактом сборки с включёнными утверждениями.

GDCM_SUPPORT_BROKEN_IMPLEMENTATION=ON — это собственное значение по умолчанию GDCM, и оно оставлено без изменений. Переопределите консервативный параллелизм с помощью JOBS=8.

Каждая сборка записывает build-info.json (ревизия, компилятор, флаги, платформа) в своё дерево сборки GDCM, и каждое резюме запуска встраивает его, поэтому архивированные доказательства самодостаточны.

Запуск

run-matrix.sh запускает каждый автоматический случай для каждой цели, не останавливается на первом сбое и записывает _runs/matrix-<stamp>.json плюс отрендеренный _runs/matrix-<stamp>.md. Двухэтапный случай f1-exploit остаётся ручным и сообщается как таковой, а не ошибочно классифицируется как неудавшийся автоматический случай.

У каждого дочернего процесса отключены дампы ядра и установлен 15-секундный тайм-аут; Результат 5 дополнительно получает ограниченный лимит стека. Выходные данные остаются в _runs/. Классификатор сопоставляет класс санитайзера и затронутую функцию, никогда — адреса, PID или номера строк исходников.

Для vulnerable случай проходит, когда появляется решающий сигнал и его контроль остаётся чистым. Для master раннер записывает наблюдение, а не предварительно объявленный вердикт. Для fixed случай проходит только когда сигнал отсутствует, не появляется никакой другой сигнал санитайзера или фатальный сигнал, и обвязка возвращает допустимый чистый результат. Эти правила предварительны, пока FIXED_REV не назовёт фактический патч; они должны быть проверены на предмет предполагаемого поведения патча «отклонить или обработать».

Случаи

Ещё две обвязки являются исследованием эксплуатируемости, а не случаями воспроизведения, и собираются только в профиле без санитайзеров на Linux x86-64:

Сохранённые доказательства

evidence/v3.2.6-macos-arm64-debug.md фиксирует завершённую отладочную матрицу v3.2.6, включая каждый контроль и обе ограниченные проверки распространения Результата 3.

evidence/v3.2.6-linux-x86_64-finding01-groom.md и evidence/v3.2.6-linux-x86_64-finding03-leak.md фиксируют два результата эксплуатируемости ниже. Результаты текущего master, полной матрицы релизного профиля и f1-exploit не заявляются, пока их стенограммы не сохранены.

Очистка

Очистка отказывается запускаться без маркера пакета и удаляет только _work, _build, _generated, _runs и кэши байт-кода Python под этим репозиторием. Сохранённые доказательства в evidence/ не удаляются.

Примитив эксплуатации (Результат 1)

f1-exploit работает только на Linux-x86_64 и запускается вручную; manifest/expectations.json содержит точную последовательность команд. При детерминированной схеме размещения обвязки он проверяет три отдельных факта, каждый с согласованным негативным случаем:

• переполнение достигает памяти, которую аллокатор выдал после целевого буфера;
• байты, попадающие туда, — это точные байты, которые запросил сконструированный DICOM. Подстановка другого значения или использование простого фикстура f1 сообщает о повреждении, но явно не о контроле содержимого, поэтому проверка фальсифицируема;
• указатель на функцию синтетической жертвы в итоге содержит адрес, предоставленный файлом, и вызов его передаёт управление функции внутри обвязки.

Примерно половина 8-байтовых окон в пределах 12288-байтового переполнения принимает произвольное значение. Остальные связаны, потому что DoYBRFull422 дублирует один исходный байт в две выходные позиции; смещение 6144 — одно из свободных окон. Декодирование кадра 1 выполняется последним, поэтому именно содержимое кадра 1 сохраняется после выделения.

Обвязка записывает, возвращает ли ImageReader::Read() true, пока соседний объект изменён. Успешная стенограмма Linux x86-64 должна быть сохранена, прежде чем описывать этот результат как наблюдаемое доказательство.

Что происходит без инструментирования

f1-exploit предоставляет свою собственную схему жертвы, поэтому он не может ответить, имеет ли немодифицированный процесс такую схему. finding01_groom использует стандартную glibc, PIE по умолчанию и ASLR, с глобальными хуками выделения, которые записывают, но не перемещают выделения. В сохранённых тестах:

• выделение, следующее за 24576-байтовым буфером, было освобождённым 2049-байтовым рабочим блоком GDCM во всех 20 записанных испытаниях. Ни один живой объект или vtable не наблюдался;
• повреждение метаданных списка свободных блоков этого блока вызывает собственную проверку согласованности glibc, которая прерывает работу. Простая обвязка finding01 умирает так же без какого-либо инструментирования.

На протестированной сборке glibc Результат 1 надёжно вызывал отказ в обслуживании; путь выполнения кода не был найден. Протестированная геометрия была фиксированной, и другие аллокаторы или платформы могут размещать кучу иначе.

finding03_leak — более сильный результат. В протестированной сборке чтение за пределами границ достигает 131070 байт, указатель vtable gdcm::ByteValue попадает в декодированные пиксели, и обвязка выводит базу загрузки библиотеки, используя известное смещение vtable этой сборки. Это результат локального раскрытия на уровне API: он требует применения LUT и доступа к декодированному буферу пикселей. Он не показывает, что сетевой сервис возвращает эти пиксели.

Эти два нельзя объединить в выполнение кода здесь, и не только потому, что жертва не была найдена: им нужны разные значения PhotometricInterpretation, поэтому нужны два файла, и утечка базы полезна только пока процесс, выполняющий утечку, ещё жив.

Граница доказательств

Отчёт санитайзера доказывает заявленное событие нарушения безопасности памяти или неопределённого поведения в протестированном процессе и ревизии. f1-exploit проверяет контроль байтов и перезапись соседнего указателя на функцию под инструментированным аллокатором, который намеренно предоставляет целевую схему. Он не устанавливает эту схему в немодифицированном потребителе. Сохранённые испытания finding01_groom не наблюдали эту схему для протестированной геометрии и сборки glibc.

Ничто из этого не доказывает удалённую достижимость в каком-либо конкретном продукте, персистентность или применимость в нижележащих системах. Аргумент достижимости для данного развёртывания — это отдельное утверждение, сделанное в тексте раскрытия, а не этим пакетом.