Три пути входа, один путь выхода через `ObfDereferenceObject`.

Это не значит, что код неправильный. Это значит, что **инвариант распределён** — ни одна отдельная функция не владеет утверждением *«этот объект сейчас жив»*, поэтому корректность зависит от того, что каждый вызывающий код согласованно понимает, какой ссылкой он владеет и как долго эта ссылка действительна. Распределённые инварианты — это среда обитания состояний гонки, потому что гонка никогда не является логической ошибкой, которую можно увидеть в одной функции. Это ошибка в предположении, разделяемом между двумя.

Поэтому вопрос, который я начал задавать каждой функции, касающейся `PWND`, был не *«корректен ли этот код?»*, а:

> **Если это конкретное тело функции выполняется на двух потоках с интервалом в несколько инструкций, какой из них ошибочен?**



## 3. Корневая причина

Дефект представляет собой **разрыв между проверкой и использованием (time-of-check / time-of-use) между освобождением ссылки и уничтожением объекта** в пути уничтожения окна, без надлежащей синхронизации с параллельным потребителем, проверяющим валидность дескриптора.

Если свести к сути:```c
/* Thread A — teardown */
NtUserDestroyWindow(HWND hwnd)
{
    PWND pWnd = ValidateHwnd(hwnd);
    if (pWnd) {
        ObfDereferenceObject(pWnd);   /* reference released */

        /* <-- race window: object may become reclaimable here */

        FreeWindowObject(pWnd);       /* teardown proceeds on a pointer
                                         no longer guaranteed live      */
    }
}

if (pWnd->fnid == FNID_BUTTON)    /* use-after-free */
    ...

Чтобы это имело значение, должны выполняться два условия, и оба выполнялись:

**(a) Окно реально.** `ValidateHwnd` — это шлюз, который должен обеспечивать безопасность доступа на основе дескрипторов. Если проверка может успешно пройти для объекта, уничтожение которого уже началось, то это не шлюз, а рекомендация.

**(b) Освобождённая память управляема атакующим.** Поля, читаемые сразу после проверки, включают `fnid`, который управляет диспетчеризацией сообщений. Решение о диспетчеризации, принятое на основе переиспользованной памяти, — это разница между *«ненадёжным крахом»* и *«нарушением границы безопасности»*. Именно это различие — вся причина, по которой это CWE-362 с воздействием EoP, а не баг стабильности.

> Наблюдаемое **повреждение** — это use-after-free; **причина** — CWE-362, параллельное выполнение с использованием общего ресурса без надлежащей синхронизации. Это два разных утверждения, и MSRC интересует второе. **Сообщайте о причине, а не только о симптоме.**

### Почему гонки в win32k структурно сложнее, чем кажутся

Если вы охотились за гонками в других подсистемах, win32k вас разочарует: архитектура противодействует вам тремя конкретными способами.

**Окна имеют привязку к потоку.** Окно принадлежит потоку, который его создал. Значительная часть подсистемы построена на предположении, что владеющий поток — это тот, кто обращается к объекту, а это означает, что наивный подход «запустить два потока, вызывающих один и тот же API», часто ничего не пересекает — вы не создаёте гонку, а выстраиваетесь в очередь. Чтобы два пути действительно столкнулись на одном объекте, нужно понимать, какие операции реально выполняются в потоке вызывающего, а какие маршализуются в поток владельца.

**Диспетчеризация сообщений частично сериализует вас.** Отправки (sends) и постановки в очередь (posts) ведут себя по-разному, а межпотоковая и внутрипоточная диспетчеризация — снова по-разному. Часть того, что выглядит как возможность параллелизма, молча превращается в упорядоченную операцию, прежде чем достигнет интересующего вас кода. Если вы не знаете, в какую категорию попадает ваш триггер, вы сделаете вывод, что настоящая гонка недостижима, — это ложноотрицательный результат, который неотличим от «здесь нет бага».

**Критическая секция прячется в вызывающем коде.** Значительная часть подсистемы работает под крупнозернистой блокировкой, захватываемой значительно выше функции, на которую вы смотрите. Это самый большой источник потерянного времени при аудите win32k: функция без видимой синхронизации, которая тем не менее полностью безопасна, потому что все пути в неё уже сериализованы. **Покрытие блокировкой — это межпроцедурное свойство.** Нужно подниматься по графу вызовов, а не просто читать функцию.

Именно из-за третьего пункта фраза *«в этой функции нет блокировки»* как сигнал почти ничего не стоит, и именно поэтому большая часть работы в этом исследовании была потрачена на достижимость, а не на сам дефект.

## 4. Почему оценка воздействия именно такая

MSRC оценило это как **Important, Elevation of Privilege, CVSS 8.8, вектор атаки — локальный, аутентифицированный.** Эту оценку определяют два свойства:

**Достижимость из низкой целостности.** Поверхность вызовов сообщений win32k достижима из контекстов, находящихся значительно ниже SYSTEM. Именно поэтому она актуальна для цепочек побега из песочницы: процесс рендеринга, уже добившийся выполнения кода внутри своей песочницы, всё ещё может обращаться к этой поверхности. Серьёзность ядерного бага — это в основном функция того, *кто может до него добраться*, а не того, насколько изощрённым является повреждение.

**Повреждение, влияющее на диспетчеризацию.** Повреждение поля, на котором работает `switch`, качественно хуже, чем повреждение поля, которое только лишь логируется. Первое превращает баг памяти в вопрос управления потоком выполнения.

Я хочу быть здесь точным, потому что видел, как авторы первых CVE преувеличивают это: **я продемонстрировал гонку и use-after-free. Я не предоставлял готового эксплойта уровня SYSTEM.** Формулировка «побег из песочницы» описывает *класс цепочек*, к которому относится этот тип бага, и почему эта поверхность ценна, — это аргумент о достижимости, а не утверждение, что я такой эксплойт построил. Преувеличение воздействия — самый быстрый способ сжечь доверие вендора, и оценка MSRC — это цифра, которая имеет значение, а не моя.

## 5. Сначала была фальсификация — большинство кандидатов отпали

Та часть, о которой никто не пишет: это был не первый кандидат. Это тот, который выжил.

Моё рабочее правило: **кандидат считается виновным, пока его виновность не доказана.** Для каждого перспективного паттерна записывается конкретная причина, по которой он *не должен* быть эксплуатируемым, и я сначала пытаюсь подтвердить эту причину, а уже потом — воспроизвести его. Кандидаты, которые я закрыл до этого, включали:

- пути, которые выглядели несинхронизированными, но были сериализованы блокировкой, захватываемой на один кадр выше,
- пути, где «освобождённый» объект на самом деле кэшировался, а не освобождался,
- пути, которые были действительно гонящимися, но недостижимыми из какого-либо вызывающего кода, доступного пользователю с низкими привилегиями.

Каждый из них — это находка, которую я *не* отправил в MSRC. В этом и суть. Продуктивность исследователя — это не количество сгенерированных кандидатов, а скорость, с которой он может отбраковать ошибочные, чтобы не держать их ещё в два часа ночи.

**Три вопроса, которые убили большинство кандидатов:**

1. **Держит ли кто-то выше меня блокировку?** Межпроцедурно, а не локально. Отсутствие блокировки в функции ничего не значит.
2. **Может ли непривилегированный вызывающий код реально достичь обеих сторон?** Гонка между двумя путями, требующими разных уровней привилегий, — это не гонка, а мысленный эксперимент.
3. **Можно ли переиспользовать освобождённую память в окне, на которое я могу влиять?** Если разрушение практически атомарно, то нет бага, о котором стоит сообщать.

## 6. Проверка: статический анализ даёт гипотезы, отладчик — истину

Статический анализ `win32kfull.sys` дал мне гипотезу. Он никогда не мог дать мне сам баг. **Гонки не видны в декомпиляторе**, потому что дефект не в инструкциях — он в чередовании выполнения.

### Лаборатория

| Роль | Конфигурация |
| --- | --- |
| Хост / отладчик | Windows 11, WinDbg |
| Цель | Windows Server 2022, Build 20348.2159 |
| Анализ | Kali Linux + Windows 11 VM |
| Транспорт отладки | VMware serial COM, отладка ядра хост → цель |
| Статический анализ | Ghidra via GhidraMCP |
| Помощь при триаже | Проход с помощью ИИ по декомпилированному выводу |

Реальную работу выполняли три слоя инструментирования.

### Special pool и Driver Verifier

Самый эффективный шаг в любом расследовании UAF в ядре. По умолчанию освобождённая память пула почти сразу переиспользуется следующим выделением похожего размера — а это значит, что use-after-free обычно *не вызывает сбой*. Он читает чужие валидные данные, продолжает выполнение и взрывается где-то в несвязанном месте минуты спустя. Затем вы тратите три дня на аудит невиновной функции.

Special pool меняет это. Каждое выделение получает собственную страницу с соседней guard-страницей, а освободившиеся страницы помечаются как no-access вместо переиспользования. В результате проблемное разыменование вызывает сбой **на той инструкции, которая его выполняет**, а не ниже по потоку:```
!verifier 0x1 win32kfull.sys        ; special pool on the target driver
!verifier 0x8 win32kfull.sys        ; pool tracking

Блок, который *выделен* с правдоподобным тегом и мусорным содержимым, указывает на **повреждение**. Блок, который *освобождён* или находится на странице без доступа в специальном пуле, указывает на **ошибку времени жизни** — что-то удерживало указатель после смерти объекта. В этом различие между *«здесь писал атакующий»* и *«этот объект не должен был быть достижимым»*, и это разница между отчётом о повреждении кучи и отчётом CWE-362.

Перепроверьте тип объекта, прежде чем остановиться на каком-либо из вариантов. У `PWND` есть узнаваемая форма; если память, на которой произошёл сбой, всё ещё хранит его остатки, вы почти наверняка имеете дело с проблемой окна времени жизни, а не со случайной перезаписью.

### Живая отладка ядра при чередовании

Даже со специальным пулом гонка остаётся проблемой планировщика, а **отладчик меняет планирование.** В этом главная досада работы с гонками: инструмент возмущает то, что измеряет. Точка останова на пути уничтожения объекта сериализует именно те два потока, которые вы пытаетесь перекрыть, и ошибка вежливо исчезает.

Путь через это — перестать пытаться поймать гонку точкой останова и вместо этого:

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

Сам сбой, когда он у вас есть, выглядит буднично — разыменование `PWND` на пути диспетчеризации сообщений, где объект уже прошёл уничтожение в другом потоке, а `!pool` подтверждает, что блок был освобождён, а не перезаписан:```
kd> !analyze -v

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Access violation
FAULTING_MODULE: win32kfull