Introduction Этот пост является второй и последней частью нашего исследования Avast и будет фокусироваться на эксплойте CVE-2025-13032, уязвимости двойного чтения, обнаруженной в драйвере ядра Avast. Этот пост напоминает об ошибке и проводит нас через то, как мы эксплуатировали её в системе Windows 11 на момент обнаружения. Не забудьте прочитать первую часть, если пропустили → https://www.safateam.com/intelligence-hub/research/technical-articles/cve-2025-13032-entering-and-breaking-the-avast-antivirus-sandbox-part-1

Bug Explanation Уязвимость, которую мы хотим эксплуатировать, — это уязвимость двойного чтения, ведущая к overflow pool kernel. Приведенный ниже фрагмент кода supposed захватить структуру `_UNICODE_STRING`, поставленную пользователем, но поле `Length` пользовательского ввода многократно извлекается, что приводит к проблеме двойного чтения. Первое извлечение делается для выделения буфера, в который будет скопирована строка, а второе извлечение делается для выполнения memcpy на основе полученного значения, что приводит к overflow pool если пользователь изменит его между действиями. Для эксплойта двойного чтения второй поток работает в тесной петле, непрерывно переключая поле `Length` общего `_UNICODE_STRING` между небольшим безопасным значением и большим вредоносным значением (например, `0x1000`, больше выделенного буфера). Основной поток вызывает уязвимый IOCTL в цикле. Когда выровнен по времени — ядро читает `Length` как маленькое для вызова `ExAllocatePoolWithTag`, затем читает как большое для `memmove` — копируется больше байт, чем было выделено, образуя overflow pool. Окно гонки узкое, но его можно выиграть надежно в modest number of iterations. Наша цель — эксплуатировать этот overflow pool для получения примитива arbitrary kernel read/write и достижения локального повышения привилегий. Данная уязвимость дает нам хорошие условия для эксплойта: overflow targets `PAGED_POOL`, и размер выделения и размер overflow контролируемы, а также содержимое. Paged Pool — это область памяти ядра Windows, используемая для объектов и данных, которые ядру или драйверам нужны, но которые могут быть выгружены на диск. Используется для памяти, которая не требует доступа критическим кодам, работающим с высоким приоритетом. The allocator groups allocations by size class, meaning same-sized objects tend to land close to each other in memory — the property that makes heap spraying viable. Since Windows 10 19H1 this is handled by the Segment Heap, which uses two backends: the LFH for small allocations, which picks free slots randomly within a size bucket, and the VS allocator for larger ones, which serves the first available chunk of the right size — each requiring a different spray strategy. We can also note that most Windows objects are stored in the paged ...