NotSecDrv - Un código PoC para CVE-2018-7249

Descripción General

Se descubrió un problema en secdrv.sys tal como se distribuye en Microsoft Windows Vista, Windows 7, Windows 8 y Windows 8.1 anteriores a KB3086255, y tal como se distribuye en Macrovision SafeDisc. Dos llamadas cuidadosamente sincronizadas al IOCTL 0xCA002813 pueden provocar una condición de carrera que deriva en un use-after-free. Cuando se explota, un atacante sin privilegios puede ejecutar código arbitrario en el kernel.

La vulnerabilidad fue reportada a Microsoft y, dado que no afecta a una máquina Windows actualizada (solo a versiones anteriores a KB3086255), no tomarán ninguna medida. Fue probada y explotada con éxito en Windows 7 x86.

También relacionada con CVE-2018-7250.

Captura de pantalla

Detalles

Esto documenta mi pequeña investigación sobre el controlador secdrv.sys. Todos los comportamientos descritos del controlador fueron obtenidos mediante ingeniería inversa y podrían ser incorrectos / inexactos.

El offset 0x4 del búfer de entrada al IOCTL (0x0CA002813) contiene un número que denominaré TYPE. La función principal del manejador de este IOCTL (0x0CA002813), sub_11A88, recibe 3 tipos diferentes: 0x96, 0x97 y 0x98.

• 0x96 asigna un bloque de PagedPool, lo almacena en un array de tamaño 0x64, lo inicializa (más o menos :)), y copia una parte del mismo al búfer proporcionado por el usuario en el offset 0x10.
• 0x97 utiliza un bloque previamente asignado, que fue asignado con 0x96 (encuentra el bloque correcto en el array mencionado mediante una etiqueta), y lo usa para cifrar el búfer de entrada del usuario con una especie de rutina de cifrado xor modificada. Luego llama a una función que está almacenada en otra estructura, a la que apunta un campo del bloque asignado.
• 0x98 libera un bloque que fue asignado con 0x96. Encuentra el bloque correcto buscando la etiqueta que se le dio durante el proceso de asignación.

Fuga de Información (CVE-2018-7250)

Después de que el IOCTL de tipo 0x96 asignara un nuevo bloque y lo inicializara, pero no por completo, copia el bloque al modo usuario. 16 bits del bloque recién asignado no fueron inicializados y contienen datos de asignaciones PagedPool anteriores. Los bits no inicializados se copian luego al modo usuario en .text:00011BE9 mediante la instrucción REP MOVSD. Código PoC aquí.

Ejecución Arbitraria de Código (CVE-2018-7249)

Cuando se llama al IOCTL de tipo 0x97, encuentra el bloque necesario, que fue previamente asignado con el tipo 0x96, mediante su etiqueta. Si la asignación ya fue liberada por el IOCTL de tipo 0x97, DeviceIoControl devuelve un error. La vulnerabilidad aquí es que la asignación utilizada por el tipo 0x97 puede liberarse DURANTE su operación (ya que no se utilizan mecanismos de sincronización), quedando así en un estado de use-after-free si se gana la carrera. Si un atacante consigue liberar el bloque durante la operación del IOCTL de tipo 0x97 (usando el tipo 0x98) y asignar un nuevo bloque, controlado por él, en exactamente la misma ubicación de memoria, puede sobrescribir un puntero a otra estructura, que contiene un puntero a función que puede utilizarse para finalmente secuestrar el flujo de ejecución del controlador y ejecutar código arbitrario en el anillo 0. Debido a que la rutina de cifrado se ejecuta sobre un búfer proporcionado por el usuario, que puede ser de gran tamaño, el cifrado puede tardar mucho tiempo en ejecutarse, lo que proporciona una ventana de tiempo perfecta para que el IOCTL de tipo 0x98 libere el bloque mientras aún está en uso. Las ventanas de tiempo pueden ser tan largas (¡más de 1 segundo!) que la carrera puede ganarse de forma fiable al primer intento. El use-after-free comienza en .text:00011B68, y la llamada real, que será secuestrada para saltar al shellcode, ocurre en .text:00011B86.

Los pasos llevados a cabo para explotar esta vulnerabilidad con éxito son los siguientes:

• Liberar todos los bloques anteriores con la etiqueta que planeamos usar más tarde, asegurándonos de que todos los IOCTL operen sobre el mismo bloque de PagedPool.
• Rociar el PagedPool y crear agujeros que coincidan con el tamaño de las asignaciones en el IOCTL de tipo 0x96 (0x30 bytes). Esto es necesario para, más tarde, poder asignar de forma fiable un reemplazo falso en lugar del bloque liberado.
• Asignar un bloque con el IOCTL de tipo 0x96. Este bloque se asignará en uno de los agujeros creados anteriormente.
• Asignar una gran región de memoria de espacio de usuario y llamar al IOCTL de tipo 0x97. La gran región de memoria asegurará que el hilo que libera la asignación tenga tiempo suficiente para ganar la carrera.
• Iniciar un nuevo hilo que llamará al IOCTL de tipo 0x98 y liberará el bloque sobre el que el otro hilo está operando.
• Rociar el pool de nuevo desde el nuevo hilo (después de que el bloque haya sido liberado) para reemplazar el bloque liberado con una asignación controlada por el atacante. Este bloque falso debe contener punteros válidos a las estructuras necesarias.
• Colocar la dirección del shellcode en el offset correcto del puntero a función en la estructura falsa que creamos, y esperar a que sea llamado (se llamará desde el IOCTL de tipo 0x97, después de que termine el cifrado).
• ¡A disfrutar!

Entorno de Prueba

OS: Windows 7 Kernel Version 7600 MP (1 procs) Free x86 compatible Built by: 7600.16385.x86fre.win7_rtm.090713-1255 VM: 4GB RAM, 1 CPU Hardware: Windows 10 Pro 64 bit, Placa base Gigabyte Z370 HD3, 16GB RAM, Intel i5-8400 2.80GHz (6 CPUs)