Al respecto del actual 0 DAY de Microsoft sobre la MSVIDCTL.DLL

Si bien ya informamos de esta noticia hace unos dias en https://blog.satinfo.es/?p=490  ,

 complementamos lo indicado con esta notica de Hispasec de hoy:
“Microsoft conocía el último “0 day” desde 2008″
El pasado día 4 de julio se supo que ciertos atacantes estaban aprovechando de forma masiva una vulnerabilidad no hecha pública hasta ahora en un ActiveX de Microsoft. Poco después Microsoft confirmaba el problema en una notificación, que ofrecía contramedidas pero en el que todavía no se publicaba parche oficial. Al parecer, Microsoft estaba al tanto desde 2008 no solo de esta, sino de otra vulnerabilidad más en el mismo componente.
CVE-2008-0015 es el CVE que Microsoft ha asignado a este nuevo “0 day”. El CVE es el Common Vulnerabilities and Exposures, un estándar (administrado por la organización Mitre.org) que se encarga de identificar unívocamente a las vulnerabilidades. El CVE ha tenido gran aceptación entre todos los fabricantes porque la mayor parte de las veces es muy complejo saber a qué vulnerabilidad nos estamos refiriendo solo por ciertas características. Es necesario una especie de número de identidad único para cada fallo, puesto que en ocasiones son tan parecidas, complejas o se ha ofrecido tan poca información sobre ellas que la única forma de diferenciar las vulnerabilidad es por su CVE.

¿Por qué asignar un CVE de 2008 en 2009? Esto significa que Microsoft conocía el fallo desde el año pasado. Los fabricantes solicitan CVEs al Mitre y los asignan libremente a las vulnerabilidades que encuentran. Ryan Smith y Alex Wheeler de IBM ISS X-Force lo descubrieron y lo reportaron entonces. Microsoft asignó el CVE pero todavía no lo ha hecho público ni lo ha solucionado… hasta que se ha convertido en un “0 day”. Los atacantes (no se sabe cómo) han descubierto la existencia del fallo y desde no se sabe cuándo, están aprovechándolo para instalar malware en los sistemas Windows. Esto ha hecho que Microsoft deje de mantener la vulnerabilidad en el letargo y tenga que ponerse a trabajar en ella cuanto antes.

¿Es normal tardar tanto para solucionar una vulnerabilidad? Según Microsoft, básicamente depende de si es conocida o no. La compañía se vuelca totalmente en un fallo cuando es público, si no, va a “otro ritmo” a la hora de parchear. Incluso cuando la vulnerabilidad es pública, hay que tener en cuenta que Microsoft hace insistentes pruebas de compatibilidad cada vez que saca un parche, y aun así, a veces comete errores. El código del sistema operativo es demasiado complejo y las interacciones pueden ser impredecibles, así que la estrategia para los parches de Windows es “lento pero (en lo posible) seguro”. En este caso Microsoft ha sido lento sin excusas, teniendo en cuenta la gravedad de la vulnerabilidad, el tiempo transcurrido y que (como ha pasado) al final la información o bien ha sido filtrada o descubierta independientemente por los atacantes. Microsoft tiene la responsabilidad de actuar (por volumen de uso, por recursos disponibles y por ser objetivo principal del malware) mucho más rápido. Wheeler, uno de los descubridores del fallo, piensa que no: que hay muchos problemas de seguridad, y que es normal que Microsoft se dedique a los que están siendo explotados con prioridad. Como este no era público hasta hace poco, no piensa que sea demasiado tiempo.

Para colmo, se ha dado a conocer que desde el IBM ISS X-Force, también se notificó a Microsoft otra vulnerabilidad en 2008, identificada con el CVE-2008-0020, en la misma librería Msvidctl.dll de DirectShow. Esta todavía no ha sido reconocida por Microsoft, pero es probable que sea parcheada junto con la CVE-2008-0015.

Microsoft acumula así dos vulnerabilidades en DirectShow que se sabe que están siendo aprovechadas por atacantes (CVE-2009-1537 y CVE-2008-0015) y otra de la que no se sabe demasiado (CVE-2008-0020).

Por otro lado, en el “advisory” oficial de Microsoft se ofrecía información interesante. Por ejemplo, limita el problema a Windows XP y 2003. También enumera nuevos CLSID a los que se les puede activar el Kill Bit para evitar que sean explotables a través de Internet Explorer. Esto puede significar que son potenciales nuevos vectores de ataque que podrían ser usados para aprovechar la vulnerabilidad. Los ataques estaban llevándose a cabo a través de un solo CLSID (asociado a una librería) para aprovechar la vulnerabilidad, pero al parecer existen más, que Microsoft bloquea ahora para prevenir futuros ataques hasta que el problema sea solucionado por completo.

Se recomienda en todo caso, ejecutar la herramienta que Microsoft ha publicado para activar todos los Kill Bits de los CLSID implicados, que si bien no soluciona el fallo de raíz, evita que Internet Explorer se convierta en un vector de ataque

Fuente

Al respecto informamos que el actual ELISTARA ya incluye el killbit indicado en este artículo, y que McAfee ya detecta los threats que utilizan estas vulnerabilidades.

saludos

ms, 9-7-2009