Microsoft vuelve a tener problemas. Adicionalmente al 0-day de Internet Explorer que publicamos recientemente (sobre el que se han posteado algunas recomendaciones), se le suma otro 0-day que afecta a todas las versiones de 32bits de su sistema operativo desde Windows NT 3.1 hasta Windows 7 . Las versiones de 64bits de Windows Xp, Vista, 7, 2003 y 2008 no se ven afectadas porque no tienen compatibilidad con aplicaciones de 16bits. Existe un exploit público que aprovecha esta vulnerabilidad.

La vulnerabilidad permite obtener privilegios a nivel de sistema sobre la máquina local de forma que se podría ejecutar cualquier tipo de programa y comprometer el sistema.  

El utilizar un usuario no privilegiado en nuestra sesión de Windows, es una aspecto que venimos recomendando hace tiempo puesto que nos libra del 92% de los problemas de seguridad, pero con esta vulnerabilidad, la recomendación ya no es efectiva mientras no salga el parche correspondiente de Microsoft o se tomen las medidas preventivas pertinentes.

El problema viene por errores de programación en la máquina virtual DOS (VDM) que se introdujo en 1993 para dar soporte a viejas aplicaciones de 16bits, con lo cual el problema viene existiendo desde hace 17 años.

Adicionalmente a las recomendaciones que siguen, también se puede deshabilitar la máquina VDM en Windows Xp creando un fichero "quitaVMD.reg" con el siguiente contenido:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat]

"VDMDisallowed"=dword:00000001

Microsoft Windows

Microsoft Windows desde el NT hasta Windows 7, pasando por 2000, 2003, 2008, XP y Vista.

Riesgo:   Alto

Elevación de privilegios del sistema. Un usuario puede realizar un cambio de contexto en el núcleo y ejecutar código como SYSTEM.

Tavis Ormandy, reputado investigador de seguridad que ha encontrado numerosos fallos de seguridad en diferentes programas, ha publicado un exploit para una vulnerabilidad que permite elevar privilegios en Windows. Se trata de un fallo de diseño que arrastran todos los Windows de 32 bits (basados en tecnología NT) desde 1993. Esto va desde el NT hasta Windows 7, pasando por 2000, 2003, 2008, XP y Vista.

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=XRVI4iQ2Nug

Windows Server 2008
http://www.youtube.com/watch?v=u8pfXW7crEQ

Para Windows XP:
http://www.youtube.com/watch?v=u7Y6d-BVwxk

Para sistemas más antiguos, NT4, aquí se explica cómo deshabilitar esta funcionalidad:
http://support.microsoft.com/kb/220159

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.

CVE-2010-0232

Fuente:  Hispasec una-al-día http://www.hispasec.com/unaaldia/