Descubren añeja vulnerabilidad en Windows 7, XP, 2003, 2000,...
Descubrir este tipo de vulnerabilidades en sistemas operativos que ya ni se usan es un trabajo como el de un arquéologo, pero descubrirlas en versiones nuevas es como el trabajo de un genetista encontrando el gen culpable de alguna enfermedad.
El caso es que Tavis Ormandy (miembro del equipo de seguridad de Google) descubrió una vulnerabiliad heredada a Windows 7 desde Windows NT 3.1 (32 bits). Arrastrada desde hace 17 años, el fallo de seguridad permite que un programa de 16 bits pueda controlar la pila de procesos del kernel, por lo que un atacante podría perfectamente ejecutar código malicioso con los máximos privilegios del sistema. Afecta a todas las versiones de 32 bits de Microsoft.
Ormandy informó del problema a Microsoft en 2009, desde entonces la compañía aún no ha liberado una solución al mismo. Y sólo publicó un reporte de seguridad en el que afirma que están analizando el problema y que no tienen conocimiento de que esta vulnerabilidad haya sido utilizada para algún ataque.
Para poder ser víctima de un ataque utilizando esta falla, el atacante debería contar con credenciales de inicio de sesión válidas y ser capaz de entrar al sistema localmente.
“Una vez completada la investigación, Microsoft tomará las acciones apropiadas para ayudar a proteger a nuestros clientes”, lo que podría implicar la liberación de un parche de seguridad especial, indicó la empresa.
Mientras tanto se recomienda a todos los usuarios de Windows en su sabor 32 bits desactivar la ejecución de aplicaciones de 16 bits en sus sistemas. Para ello deben ir a Herramientas Administrativas > Componentes de Windows y Compatibilidad de Aplicaciones.
En hispasec.com lo explican de la siguiente forma:
El fallo reside en el soporte heredado de aplicaciones de 16 bits. No se valida correctamente el cambio de contexto y pila que se efectúa al llamar al manejador GP trap. Windows comete algunos errores y asume incorrectamente que:
* Se requiere el privilegio SeTcbPrivilege para configurar un contexto VDM (Virtual DOS Machine) .
* Código en ring3 no puede instalar selectores de segmento de código arbitrarios. Usando el modo Virtual-8086, es posible.
* Código alojado en el ring3 (espacio de usuario) no puede falsificar un "trap frame".Ormandy consigue eludir estas cuestiones, y el resultado es que un usuario puede realizar un cambio de contexto en el núcleo y ejecutar código como SYSTEM, el máximo privilegio en el sistema.
Para eludir el tercer punto, se necesita acceder a una dirección de memoria, que es siempre la misma en todos los Windows menos Vista y Windows 7 que realizan una "aleatorización" de la carga en memoria. Se supone que esto protege de este tipo de ataques. Sin embargo, usando NtQuerySystemInformation(), se puede llegar a calcular dónde está esa dirección aunque sea diferente en cada inicio, con lo que la protección ASLR (Address space layout randomization) también se ve eludida.
Ormandy avisó a Microsoft en junio de 2009, y poco después confirmaron el problema. Harto de que no publicasen una solución (que considera no muy compleja), ha decidido hacer público el fallo. Él mismo entiende que esta vulnerabilidad afecta de forma más seria a empresas y corporaciones que mantienen a sus usuarios con privilegios limitados. Por desgracia, la mayoría de usuarios caseros utilizan ya la cuenta de administrador en su Windows (no tan poderosa como SYSTEM, pero equivalente a efectos prácticos) para tareas cotidianas, con lo que la elevación de privilegios no suele ser un requisito en los ataques.
El exploit ha sido probado y funciona a la perfección. La buena noticia es que es relativamente sencillo mitigar el problema. Incluso ha publicado vídeos en Youtube de cómo hacerlo, destinados principalmente a administradores. Evitar el fallo implica deshabilitar el soporte para aplicaciones de 16 bits, que se supone no será ningún problema para la mayoría de usuarios.
Los pasos son los siguientes:
Desde la consola de políticas (gpedit.msc) abrir "Configuración de equipo", "Plantillas administrativas", "Componentes de Windows", "Compatibilidad de aplicación" y habilitar la política "Impedir el acceso a aplicaciones de 16 bits". Es importante asegurarse de que es aplicada a los sistemas que dependen del controlador de dominio, forzando una actualización de políticas.
Los vídeos publicados con cómo realizar esto (en inglés) desde la consola de políticas y aplicarlo a todos los clientes de un Directorio Activo están disponibles desde:
Windows Server 2003:
http://www.youtube.com/watch?v=XRVI4iQ2NugWindows Server 2008
http://www.youtube.com/watch?v=u8pfXW7crEQPara Windows XP:
http://www.youtube.com/watch?v=u7Y6d-BVwxkPara sistemas más antiguos, NT4, aquí se explica cómo deshabilitar esta funcionalidad:
Este es un grave revés para Microsoft. Si los administradores quieren mantener su red de usuarios controladas hasta que exista parche oficial, se recomienda aplicar esta solución temporal lo antes posible.
http://support.microsoft.com/kb/220159
Comentarios