La ralentización del sistema alcanza el 23 %, por lo que Microsoft optó por mantener abierta una brecha en la protección a nivel de hardware de los procesadores.

La protección de los procesadores Intel, que debería impedir que el núcleo de Windows acceda a la memoria de los programas habituales, 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 trasladar la pila a la memoria del proceso de usuario. Un esquema así, aparentemente, debería haber fallado de inmediato debido al mecanismo Supervisor Mode Access Prevention (SMAP). Intel desarrolló SMAP precisamente para limitar el acceso a las páginas de memoria de usuario desde el modo kernel.

Sin embargo, en una máquina virtual con Windows 11 compilación 26200.8328 la cadena se ejecutó 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 apareció establecido el bit AC (Alignment Check, bit de verificación de alineación). Según la documentación de Intel, el bit AC establecido 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 el control con AC=1. Tras forzar el restablecimiento de AC ya dentro del controlador, el intento de leer la memoria de usuario provocaba inmediatamente un fallo del sistema. Es decir, el propio mecanismo SMAP funcionaba correctamente, pero Windows autorizaba de antemano el acceso a esa memoria en la ruta de procesamiento de la petición analizada.

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

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

Más adelante en Windows surgieron funciones específicas 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 según el cual todo el código del núcleo debe usar únicamente esas funciones todavía no abarca Windows en su totalidad.

Los resultados no significan que SMAP sea completamente inútil en Windows. La verificación se realizó en una compilación concreta de Windows 11 y a través de la ruta de manejo de peticiones del controlador. Pero el experimento muestra que al explotar ciertos controladores vulnerables un atacante puede obtener el control en un contexto donde el acceso del núcleo a la memoria de usuario ya está permitido. Por ello, no se puede considerar a SMAP como una barrera independiente contra ataques tras la ejecución de código en el núcleo.