В данной статье будет рассмотрена еще одна известная уязвимость в Power Dependency Coordinator (pdc.sys) - CVE-2024-38107

По информации производителя, она эксплуатировалась in-the-wild, исправление для нее было выпущено в августе 2024

https://nvd.nist.gov/vuln/detail/cve-2024-38107

https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-38107

Тип уязвимости - Use-After-Free (UAF)

В предыдущей статье был рассмотрен интерфейс pdc.sys, его взаимодействие с клиентами, а также проанализирована уязвимость CVE-2025-27736. Многие упомянутые там особенности работы драйвера будут важны для понимания этой статьи, поэтому рекомендуется ознакомится с ее вводной частью (которая относится к ALPC и регистрационным сообщениям).

В любом случае, напомню, что для взаимодействия со своими клиентами pdc.sys использует ALPC, а на этапе соединения (NtAlpcConnectPort) производится регистрация клиента.

Типы ALPC сообщений

Для дальнейшего понимания уязвимости, надо более подробно рассмотреть взаимодействие клиента и сервера по ALPC. Для целей этой статьи будут важны типы ALPC сообщений, которые отправляются на разных этапах коммуникации между ALPC клиентом и сервером.
ALPC сообщения должны начинаться со структуры _PORT_MESSAGE

kd> dt nt!_PORT_MESSAGE -r2 +0x000 u1 : +0x000 s1 : +0x000 DataLength : Int2B +0x002 TotalLength : Int2B +0x000 Length : Uint4B +0x004 u2 : +0x000 s2 : +0x000 Type : Int2B +0x002 DataInfoOffset : Int2B +0x000 ZeroInit : Uint4B +0x008 ClientId : _CLIENT_ID +0x000 UniqueProcess : Ptr64 Void +0x008 UniqueThread : Ptr64 Void +0x008 DoNotUseThisField : Float +0x018 MessageId : Uint4B +0x020 ClientViewSize : Uint8B +0x020 CallbackId : Uint4B

Тип ALPC сообщения содержится в поле Type структуры _PORT_MESSAGE и может принимать следующие значения

#define LPC_REQUEST 1 #define LPC_REPLY 2 #define LPC_DATAGRAM 3 #define LPC_LOST_REPLY 4 #define LPC_PORT_CLOSED 5 #define LPC_CLIENT_DIED 6 #define LPC_EXCEPTION 7 #define LPC_DEBUG_EVENT 8 #define LPC_ERROR_EVENT 9 #define LPC_CONNECTION_REQUEST 10

Предшественником ALPC был LPC, и константы остались с тех времен. Некоторые из LPC типов сообщений потеряли актуальность при переходе на ALPC, другие же по-прежнему используются, рассмотрим некоторые из них. LPC_REQUEST — обычное ALPC сообщение (отправляемое через функцию NtAlpcSendWaitReceivePort), LPC_CLIENT_DIED — сообщение, отправляемое при завершении потока. LPC_CONNECTION_REQUEST – используется при установке ALPC соединения. Этот тип сообщения формируется в подвызове функции nt!AlpcpProcessConnectionRequest.

Пример стека при установке соединения с pdc

kd> kb # RetAddr Call Site 00 fffff803124187f2 pdc!PdcProcessMessage+0x22a 01 fffff80312418619 pdc!PdcpAlpcProcessMessages+0x6a 02 fffff8031093bdcf pdc!PdcMessageCallback+0x9 03 fffff8031093bcfc nt!ExNotifyWithProcessing+0xc7 04 fffff80310be4b8c nt!ExNotifyCallback+0xc 05 fffff80310bdd3d7 nt!AlpcpCompleteDispatchMessage+0x8bc 06 fffff80310bdcfb6 nt!AlpcpDispatchConnectionRequest+0x13f 07 fffff80310bdd9b1 nt!AlpcpProcessConnectionRequest+0x1be 08 fffff80310bdc73e nt!AlpcpConnectPort+0x2c5 09 fffff80310a10ef5 nt!NtAlpcConnectPort+0x6e 0a 00007ff84c9edef4 nt!KiSystemServiceCopyEnd+0x25 0b 00007ff849e72fc7 ntdll!NtAlpcConnectPort+0x14

nt!AlpcpSendCloseMessage отправляет сообщение LPC_PORT_CLOSED. Это сообщение отправляется при закрытии дескриптора порта или при завершение процесса. Ниже пример стека для закрытия порта

kd> kb # RetAddr Call Site 00 fffff803124187f2 pdc!PdcProcessMessage 01 fffff80312418619 pdc!PdcpAlpcProcessMessages+0x6a 02 fffff8031093bdcf pdc!PdcMessageCallback+0x9 03 fffff8031093bcfc nt!ExNotifyWithProcessing+0xc7 04 fffff80310be4b8c nt!ExNotifyCallback+0xc 05 fffff80310bdd519 nt!AlpcpCompleteDispatchMessage+0x8bc 06 fffff80310be08c1 nt!AlpcpDispatchCloseMessage+0x119 07 fffff80310be150e nt!AlpcpSendCloseMessage+0xe9 08 fffff80310c0718f nt!AlpcpClosePort+0x5e 09 fffff80310c0207c nt!ObCloseHandleTableEntry+0x51f 0a fffff80310a10ef5 nt!NtClose+0xec 0b 00007ff84c9ed1c4 nt!KiSystemServiceCopyEnd+0x25 0c 00007ff84a486785 ntdll!NtClose+0x14

Для завершения процесса

kd> kb # RetAddr Call Site 00 fffff803124187f2 pdc!PdcProcessMessage 01 fffff80312418619 pdc!PdcpAlpcProcessMessages+0x6a 02 fffff8031093bdcf pdc!PdcMessageCallback+0x9 03 fffff8031093bcfc nt!ExNotifyWithProcessing+0xc7 04 fffff80310be4b8c nt!ExNotifyCallback+0xc 05 fffff80310bdd519 nt!AlpcpCompleteDispatchMessage+0x8bc 06 fffff80310be08c1 nt!AlpcpDispatchCloseMessage+0x119 07 fffff80310be150e nt!AlpcpSendCloseMessage+0xe9 08 fffff80310c0718f nt!AlpcpClosePort+0x5e 09 fffff80310c9b445 nt!ObCloseHandleTableEntry+0x51f 0a fffff80310c9cdd9 nt!ExSweepHandleTable+0xd5 0b fffff80310c9b170 nt!ObKillProcess+0x35 0c fffff80310caf30e nt!PspRundownSingleProcess+0x204 0d fffff80310ce7ff8 nt!PspExitThread+0x5f6 0e fffff803108f8ead nt!KiSchedulerApcTerminate+0x38 0f fffff80310a02a90 nt!KiDeliverApc+0x60d

Для целей статьи будут важны два сообщения - LPC_PORT_CLOSED и LPC_CLIENT_DIED.

Анализ патча

Если сравнить две версии драйвера pdc.sys до августа 2024 и после, то видно, что изменения находятся в двух функциях — PdcProcessMessage и PdcpAlpcProcessMessages.

Наиболее интересное изменение (в контексте анализа уязвимости) находится в функции PdcProcessMessage. Эта функция отвечает за обработку ALPC сообщений от клиентов.

Ниже приведен фрагмент функции PdcProcessMessage до изменений

Участок кода PdcProcessMessage до изменений

После изменений тот же фрагмент имеет уже другой вид

Фрагмент обновленной PdcProcessMessage — Фрагмент обновле��ной PdcProcessMessage

Следует обратить внимание, что изменение касается как раз обработки различных типов ALPC сообщений – в старой версии драйвера сообщения LPC_PORT_CLOSED и LPC_CLIENT_DIED обрабатывались одинаково, а в новой версии их обработка происходит по-разному. Рассмотрим изменения более подробно.

В старой версии драйвера при получении сообщений данных типов происходила очистка ресурсов ALPC клиента с помощью функции PdcFreeClient.

В новой версии драйвера при получении LPC_PORT_CLOSED по-прежнему вызывается код очистки ресурсов, а LPC_CLIENT_DIED — не обрабатывается.

Для того, чтобы понять, в чем причина такого разделения и как это связано с уязвимостью, необходимо рассмотреть подробнее сообщение LPC_CLIENT_DIED.

LPC_CLIENT_DIED

Сообщение LPC_CLIENT_DIED отправляется функцией PspExitThread при завершении потока, получателем сообщения является так называемый termination port, который установлен завершаемому потоку. Участок кода PspExitThread, отвечающий за отправку сообщения приведен ниже

В обычном случае у потока нет termination port, но он может быть установлен с помощью функции NtRegisterThreadTerminatePort. Ее код приведен ниже

Надо сказать, что termination порты в системе все же используются, например в csrss.

Если проанализировать работу с termination портами в системе, то становится очевидно несколько вещей:

termination port – это ALPC port
termination port может быть не один, это список. Порт описывается структурой _TERMINATION_PORT
kd> dt nt!_TERMINATION_PORT +0x000 Next : Ptr64 _TERMINATION_PORT +0x008 Port : Ptr64 Void
функция NtRegisterThreadTerminatePort не проверяет, что порт уже был установлен в качестве termination port и, в результате, один и тот же порт можно устанавливать потоку сколько угодно раз.
Как следствие предыдущего пункта, функция PspExitThread также будет отправлять сообщение LPC_CLIENT_DIED всем привязанным портам, и, если порт был привязан n раз, ему будет отправлено сообщение LPC_CLIENT_DIED также n раз.
NtRegisterThreadTerminatePort работает с текущим потоком, а не с произвольным.

Теперь у нас достаточно информации для того, чтобы перейти к срабатыванию уязвимости

Воспроизведение

Таким образом, если pdc port будет установлен потоку как termination port, то при завершении этого потока pdc получит сообщение LPC_CLIENT_DIED. При этом, если pdc port будет установлен потоку несколько раз, то сообщение LPC_CLIENT_DIED также будет получено несколько раз. Как было выяснено ранее при анализе функции PdcProcessMessage, до патча при обработке сообщения LPC_CLIENT_DIED происходила очистка ресурсов и освобождение памяти. Возможность повторного вызова кода освобождения ресурсов звучит как условие для UAF, но стоит проверить на практике, действительно ли отправка повторного LPC_CLIENT_DIED pdc port приведет к срабатыванию уязвимости.

Если выполнить последовательность шагов ниже

Создать поток (Thread1)
Присоединиться к порту \PdcPort функцией NtAlpcConnectPort с корректным регистрационным сообщением (см. предыдущую статью)
Из потока Thread1 дважды установить \PdcPort как Termination Port.
Завершить поток Thread1

В этом случае PspExitThread отправит сообщение LPC_CLIENT_DIED pdc порту дважды. На втором сообщении произойдет обращение к освобожденной памяти и далее BSOD, таким образом, после выполнения шагов выше получаем срабатывание уязвимости.

Анализ CVE-2024-38107 в Power Dependency Coordinator