Si recientemente comentábamos que Microsoft tenía que estar en estado de alerta máxima para solucionar el pasado 0-day de Internet Explorer, ayer mismo aparecía una nueva vulnerabilidad que afecta a todos los sistemas operativos del 'gigante'.
Tavis Ormandy, un conocido investigador (cuyos gustos irónicamente se declinan más por Linux) avisó de la vulnerabilidad a Microsoft en junio de 2009. Harto de que no publicasen una solución (que considera no muy compleja), ha decidido hacer público el fallo.
En esta ocasión, se trata de un fallo en el soporte heredado de aplicaciones de 16 bits, es decir, un fallo que estaba presente en los sistemas operativos de Microsoft desde 1993, ¡hace 17 años!.
Concretamente, 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.
El exploit ya es público y funciona a las mil maravillas. La buena noticia es que esta vez si es sencillo solucionar el problema: bastaría con deshabilitar temporalmente el soporte para aplicaciones de 16 bits.
Para ello, hay que habilitar “Impedir el acceso a aplicaciones de 16 bits” en la Consola de Políticas (gpedit.msc), dentro de “Configuración de equipo – Plantillas administrativas – Componentes de Windows – Compatibilidad de aplicación”. Y hay que forzar una actualización de las políticas en los sistemas que dependan del controlador de dominio para que se aplique el cambio.
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 Windows NT4 (instrucciones):
http://support.microsoft.com/kb/220159
Fuente: http://www.hispasec.com/unaaldia/4106
Tavis Ormandy, un conocido investigador (cuyos gustos irónicamente se declinan más por Linux) avisó de la vulnerabilidad a Microsoft en junio de 2009. Harto de que no publicasen una solución (que considera no muy compleja), ha decidido hacer público el fallo.
En esta ocasión, se trata de un fallo en el soporte heredado de aplicaciones de 16 bits, es decir, un fallo que estaba presente en los sistemas operativos de Microsoft desde 1993, ¡hace 17 años!.
Concretamente, 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.
El exploit ya es público y funciona a las mil maravillas. La buena noticia es que esta vez si es sencillo solucionar el problema: bastaría con deshabilitar temporalmente el soporte para aplicaciones de 16 bits.
Para ello, hay que habilitar “Impedir el acceso a aplicaciones de 16 bits” en la Consola de Políticas (gpedit.msc), dentro de “Configuración de equipo – Plantillas administrativas – Componentes de Windows – Compatibilidad de aplicación”. Y hay que forzar una actualización de las políticas en los sistemas que dependan del controlador de dominio para que se aplique el cambio.
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 Windows NT4 (instrucciones):
http://support.microsoft.com/kb/220159
Fuente: http://www.hispasec.com/unaaldia/4106
Comentarios
Publicar un comentario