Intel se esforzó, pero a Microsoft le dio pereza: investigadores descubren que el núcleo de Windows elude las instrucciones de protección del procesador.

La protección de los procesadores Intel, que debería impedir que el núcleo de Windows acceda a la memoria de programas ordinarios, en algunas llamadas al sistema aparece desactivada de antemano. Un especialista en seguridad detectó este comportamiento mientras desarrollaba un exploit de demostración para el controlador vulnerable HackSys Extreme Vulnerable Driver.

El especialista aprovechó un error de escritura arbitraria para redirigir la ejecución de código del núcleo y mover la pila a la memoria del proceso de usuario. Ese esquema, a primera vista, parecía que debería fallar de inmediato debido a la función Prevención de acceso en modo supervisor (SMAP). Intel desarrolló SMAP precisamente para limitar el acceso a las páginas de memoria de usuario desde el modo núcleo.

Sin embargo, en una máquina virtual con Windows 11, compilación 26200.8328, la cadena funcionó con éxito y permitió obtener privilegios SYSTEM. La comprobación mostró que SMAP estaba activado mediante el bit 21 del registro CR4, pero al mismo tiempo en el registro de banderas del procesador se encontraba establecido el bit AC (Alignment Check, bit de verificación de alineación). Según la documentación de Intel, el bit AC activado permite al núcleo acceder a la memoria de usuario incluso con SMAP activo.

Una serie de pruebas mostró que el estado del bit AC no dependía del programa de usuario. Incluso cuando el programa restablecía explícitamente el bit antes de la llamada al sistema, el controlador seguía recibiendo control con AC=1. Tras forzar el restablecimiento de AC dentro del propio controlador, el intento de leer la memoria de usuario conducía inmediatamente a un fallo del sistema. Por tanto, la propia función SMAP funcionaba correctamente, pero Windows permitía de antemano el acceso a esa memoria en la ruta de manejo de la solicitud que se investigó.

La causa está relacionada con la arquitectura de Windows. Ya en 2020, los especialistas del Centro de Respuesta a Amenazas de Microsoft estudiaron si era posible habilitar completamente SMAP para el núcleo convencional. En el trabajo publicado, Microsoft llegó a la conclusión de que el código existente de Windows accede con demasiada frecuencia de forma directa a la memoria de usuario.

Cuando los especialistas de Microsoft examinaron un arranque normal del sistema, contaron alrededor de 2900 de esos accesos en 994 funciones. Si las instrucciones que habilitan y deshabilitan el acceso a la memoria de usuario se añadieran automáticamente, esto ralentizaría las llamadas al sistema aproximadamente un 23% y algunas operaciones del sistema de archivos entre 20 y 40%. Para el núcleo protegido de Windows ese enfoque resultó aceptable, ya que Microsoft controla completamente el código que allí se ejecuta.

Posteriormente, en Windows aparecieron funciones especiales que permiten intercambiar datos de forma segura entre el núcleo y la memoria de usuario. En la documentación actual de Microsoft se enumeran, entre otras, RtlCopyFromUser y RtlCopyToUser. Sin embargo, el modelo por el que todo el código del núcleo debe usar únicamente esas funciones aún no cubre Windows por completo.

Resultados no significan que SMAP sea completamente inútil en Windows. La comprobación se llevó a cabo en una compilación concreta de Windows 11 y a través de la ruta de procesamiento de solicitudes del controlador. Pero el experimento muestra que, al explotar algunos controladores vulnerables, un atacante puede obtener control en un contexto donde ya se ha permitido el acceso del núcleo a la memoria de usuario. Por lo tanto, no se puede considerar a SMAP como una barrera independiente contra ataques después de la ejecución de código en el núcleo.