Introduction Este artículo de blog es la segunda y última parte de nuestra investigación de Avast y se centrará en la explotación de CVE-2025-13032, una vulnerabilidad de doble obtención que descubrimos en el controlador kernel de Avast. Esta publicación recapitula el error y recorre cómo lo explotamos en un sistema Windows 11 actualizado en el momento del hallazgo. Si no lo leyó, puede leer la primera parte → https://www.safateam.com/intelligence-hub/research/technical-articles/cve-2025-13032-entering-and-breaking-the-avast-antivirus-sandbox-part-1

Bug Explanation El error que queremos explotar es un problema de doble obtención que conduce a un desbordamiento de pool de kernel. El fragmento de código que se muestra a continuación está supuesto a capturar una estructura `_UNICODE_STRING` suministrada por el usuario, pero el campo `Length` de la entrada del usuario se obtiene múltiples veces, lo que resulta en un problema de doble obtención. La primera obtención se realiza para asignar un búfer donde se copiará la cadena, y la segunda obtención se realiza para ejecutar un memcpy basado en el valor recuperado, lo que resulta en un desbordamiento de pool si el usuario cambia entre esas acciones. Para explotar la doble obtención, un segundo hilo se ejecuta en un bucle apretado, cambiando continuamente el campo `Length` del `_UNICODE_STRING` compartido entre un valor pequeño y seguro y un valor grande y malicioso (por ejemplo, `0x1000`, mayor que el búfer asignado). El hilo principal llama al IOCTL vulnerable en un bucle. Cuando el tiempo se alinea — el kernel lee `Length` como pequeño para la llamada `ExAllocatePoolWithTag`, luego lee como grande para el `memmove` — se copian más bytes de los que se asignaron, produciendo el desbordamiento de pool. La ventana de carrera es estrecha pero se puede ganar de manera fiable dentro de un número modesto de iteraciones. Nuestro objetivo es explotar este desbordamiento de pool para obtener un primitivo de lectura/escritura arbitrario de kernel y lograr una escalada de privilegios local. El error nos brinda buenas condiciones de explotación: el desbordamiento apunta a `PAGED_POOL`, tanto el tamaño de asignación como el tamaño del desbordamiento están controlados, así como el contenido. Paged Pool es una región de memoria del kernel de Windows utilizada para objetos y datos que el kernel o los controladores necesitan, pero que pueden paginarse a disco. Se utiliza para memoria que no necesita ser accedida por código crítico que se ejecuta con alta prioridad. El asignador agrupa asignaciones por clase de tamaño, lo que significa que los objetos del mismo tamaño tienden a aterrizar cerca uno del otro en memoria — la propiedad que hace viable el spraying de heap. Desde Windows 10 19H1 esto es manejado por el Segment Heap, que usa dos backends: el LFH para pequeñas asignaciones, que elige ranuras libres al azar dentro de un tamaño cubo, y el VS allocator para los más grandes, que sirve la primera disponible del tamaño correcto — cada uno requiere una estrategia de spraying diferente. También podemos notar que la mayoría de los objetos de Windows se almacenan en el paged ...