Antes de que Windows introdujera el aislamiento de privilegios de la interfaz de usuario, cualquier aplicación podía enviar todo tipo de mensajes de ventana a cualquier ventana en el mismo escritorio (un ataque de ruptura), lo que permite la elevación de privilegios.
Ahora, UIPI evita que las aplicaciones con privilegios bajos envíen la mayoría de los mensajes de la ventana a las aplicaciones con privilegios más altos. Wikipedia dice :
El aislamiento de privilegios de la interfaz de usuario (UIPI, por sus siglas en inglés) es una tecnología introducida en Windows Vista / 2008 Server para combatir los ataques de ataques de fragmentación. Al hacer uso del Control de integridad obligatorio, evita que los procesos con un "nivel de integridad" (IL) más bajo envíen mensajes a procesos IL más altos (a excepción de un conjunto muy específico de mensajes de UI).
Parece que debería tratar el problema, de acuerdo con este PDF vinculado en ese artículo, solo WM_NULL , WM_MOVE , WM_SIZE , WM_GETTEXT , WM_GETTEXTLENGTH , WM_GETHOTKEY , WM_GETICON , WM_RENDERFORMAT ,% co_de Se permiten%, WM_DRAWCLIPBOARD , WM_CHANGECBCHAIN , y% no documentado WM_THEMECHANGED y 0x313 . (El PDF menciona un posible ataque de denegación de servicio, que comienza en la página 57, pero aunque es un problema, eso no es una elevación de privilegios. También hice una inspección superficial de la DLL responsable, y parece que en Windows 8 no lo hace. no se registra realmente el mensaje que conduce al problema.)
No parece que ninguno de ellos tenga el problema creado por 0x31B , que provocó que el proceso de destino saltara a una dirección arbitraria. Sin embargo, este artículo de un blogger de Microsoft (Raymond Chen) insinúa enérgicamente que los ataques más graves siguen siendo un problema:
Lo que puede hacer es hacer que un servicio inyecte el programa en la sesión y dejar que se ejecute como el usuario que ha iniciado sesión. (Debe hacer que se ejecute como el usuario que inició sesión para evitar un ataque de rotura).
Este documento de Microsoft en UAC señala que algunos recursos "todavía se comparten entre procesos en diferentes niveles de privilegios ":
- Ventana de escritorio, que en realidad posee la superficie de la pantalla.
- Memoria compartida de solo lectura del montón del escritorio.
- tabla de átomos global.
- Portapapeles
Aun así, solo con tener acceso a esas cosas desde procesos con diferentes niveles de privilegios no parece permitir el salto real que causa la elevación de privilegios. E incluso si se realizó el salto, creo que la Prevención de ejecución de datos detendría la ejecución del código inyectado.
Entonces, ¿tener una ventana de un proceso que se ejecuta como WM_TIMER en el escritorio de un usuario con pocos privilegios todavía le da a ese usuario la oportunidad de elevar los privilegios?