Steve Gibson ha publicado una, cuando menos, curiosa teoría. La famosa vulnerabilidad de los Windows MetaFile (WMF) que ha supuesto una pesadilla para Microsoft (obligándola, quizás por presiones externas, a romper su ciclo de actualizaciones mensuales) podría ser intencionada. Una puerta trasera incluida a propósito en el sistema operativo más famoso.
El 12 de enero Steve Gibson y su Gibson Research Corporation desataron la polémica. Una mezcla de conspiración y paranoia, pero basada en datos técnicos concretos. Gibson es un reputado especialista en seguridad informática. Su página, grc.com aloja útiles y variadas herramientas de seguridad para Windows y suele realizar intensos y concienzudos exámenes técnicos. Uno de ellos, estudiaba a fondo la vulnerabilidad WMF.
Este fallo, decía, está basado en los registros de tipo META_ESCAPE, concretamente en el subcódigo SetAbortProc. En ella se deben especificar dos argumentos, uno que representarían el “Device Context” y el segundo sería una función a ejecutar ante un evento de cancelación de impresión.
Sin embargo, según el estudio de Gibson, esto no ocurre exactamente así. Descubrió, cuando tuvo problemas para fabricar su propio “exploit” de la vulnerabilidad, que era necesario poner el valor LENGTH de la función SetAbortProc (culpable del fallo) a “1”. Los primeros 4 bytes de cualquier metafile representan la longitud, pero para conseguir un exploit funcional para esta vulnerabilidad concreta, y poder ejecutar código arbitrario al procesar este tipo de ficheros, era necesario según Gibson, establecer deliberadamente ese valor a “1”.
De este extraño y sospechosamente concreto valor necesario para lanzar el peligroso comportamiento de la función, con el que Gibson consiguió reproducir un exploit válido, dedujo que la única conclusión razonable es que se trataba de una puerta trasera incluida en las versiones recientes de Microsoft. Por qué estaba así programado, quién lo sabía y para qué se supone que iba a ser usado, nunca lo sabríamos.
Evidentemente, acusaciones de tal magnitud vertidas por un reputado experto, no tardaron en crear un gran revuelo entre investigadores e interesados. La mayoría, en las listas especializadas, no podían más que desechar la teoría de conspiración de Gibson. Simplemente, resultaba demasiado increíble y de ser cierto, podría convertirse en un
acontecimiento de tal magnitud que su repercusión escaparía a la imaginación de cualquiera.
Microsoft, a través de su blog, se defendió. No todas las versiones son “igual” de vulnerables ni el fallo es tan sencillo de reproducir. En los sistemas Windows 9x el problema no es “crítico” puesto que procesan de distinta forma las rutinas afectadas y se necesitaría un paso más para poder reproducirlo de forma automática con éxito. Al haber terminado el ciclo de vida estipulado por Microsoft para estos sistemas, no sacarán parches para problemas de seguridad no calificados como críticos (los que pueden ser aprovechados sin interacción alguna por parte del usuario).
Stephen Toulouse escribió además en el blog oficial de Microsoft que se conocía el fallo desde hacía muchos años y que estaba presente desde los tiempos de Windows 3.0, allá por 1990. SetAbortProc fue programada cuando la seguridad no representaban la mayor de las prioridades y fue introducida en los tiempos en los que procesar imágenes era lento y quizás fuese necesario abortar el proceso de impresión antes de que terminara, mucho antes incluso de que existiera el formato WMF. Aunque la funcionalidad fue perdiendo importancia, se fue portando, junto con muchas otras, versión tras versión, en lenguaje ensamblador, a los siguientes sistemas operativos que surgieron después.
Toulouse responde a la acusación concreta de Gibson, alegando que en realidad, el fallo puede ser reproducido con un valor correcto e incorrecto del campo LENGH y no necesariamente el “1”. Si ocurre esto, es porque probablemente en el caso concreto que estudió Gibson, el registro SetAbortProc es el último en el MetaFile y esto puede provocar diferencias en el valor de la longitud necesario para poder aprovechar la vulnerabilidad. Por tanto, Microsoft alegaba que la conclusión de Gibson era poco más que circunstancial y no podía demostrar intencionalidad alguna.
En el mismo blog oficial de Microsoft, Toulouse habla de que por ejemplo, por conocer el peligro potencial de la función, se impedía a ciertas aplicaciones como Internet Explorer, procesar estos registros de tipo META_ESCAPE que contienen la función SetAbortProc. Así, al referenciar una imagen directamente en HTML, IE no la procesa y en
principio no se le creía una vía para explotar el fallo. Con lo que Microsoft “no contaba” es que, a través de Visor de Imágenes y Faxes de Microsoft, el navegador puede convertir una imagen WMF en un registro EMF imprimible. Durante esta conversión, la aplicación sí que procesa el registro META_ESCAPE y entonces sí que se vuelve vulnerable, tal y como hemos podido comprobar en las últimas semanas.
Estas explicaciones y justificaciones no han sido suficiente para muchos. Gibson se ha retractado de las formas técnicas en las que da la razón a Microsoft, pero insiste en el fondo y en su teoría de la puerta trasera, no necesariamente “con malas intenciones”. Richard M. Smith va más allá y se pregunta lo que probablemente todo el mundo estaba pensando. Si Microsoft conocía el potencial peligro de SetAbortProc, ¿Por qué no lo deshabilitó por completo e introdujo otras funciones alternativas para abortar la impresión? ¿Por qué tantas contramedidas (impedir que ciertas aplicaciones lo usen) y no una eliminación completa? ¿Por qué los equipos de desarrollo de NT, 2000, XP y el responsable del Visor de Imágenes y Faxes no han sido quienes han dado la voz de alarma? Además, dada la problemática historia con los ficheros WMF, ¿por qué no se eliminó por completo su soporte en Internet Explorer? O también: ¿no deberían los archivos WMF haber sido marcados en el registro para impedir su descarga por considerarse no seguros?
Estas preguntas son válidas incluso para versiones de Windows que todavía están por llegar. Y es que, aunque no ha sido anunciado en ningún boletín, ya existe un primer parche para Windows Vista, la futura versión de escritorio de Windows. La comunidad que la tiene instalada y la comprueba a fondo puede descargar ya su primer parche, que solventa la vulnerabilidad WMF. Esto confirma que la función culpable de la vulnerabilidad, SetAbortProc, también está presente, muchos años después de su creación y completamente obsoleta ya, en la versión del sistema operativo aún en pruebas.
Gibson da marcha atrás en sus teorías sobre conspiraciones iniciales… y Microsoft también. Windows Vista ha sido retrasado una y otra vez desde que fue anunciado, y mientras tanto, a la vez, ha perdido por el camino varias de las funcionalidades prometidas que finalmente no vendrán incluidas en él. Se puede concluir que Vista está siendo especialmente probada, o desarrollada, o quizás que plantea más problemas de los que en principio se planearon y eso consume demasiado tiempo. A la “vista” de este primer parche que en principio no debiera haber existido, por las consecuencias claras que se deducen de él, su código no es tan novedoso como se nos promete. ¿Cuánto más código vulnerable, arrastrado desde hace años, existe o existirá en este nuevo Windows?
ssantos@hispasec.com
Más información:
Microsoft knew about the WMF flaw for years
http://www.securityfocus.com/archive/1/422067/30/0/threaded
http://www.securityfocus.com/archive/1/422067
Microsoft denies Windows secret backdoor
http://www.techworld.com/security/news/index.cfm?NewsID=5180
Looking at the WMF issue, how did it get there?
http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx
Deja un comentario