¿Cuánto se tarda en resolver una vulnerabilidad?

uando se publicó el reciente parche MS04-007, eEye (la empresa que había descubierto el problema) publicó un boletín con la descripción técnica el problema, como suele hacer. Pero en esta ocasión, el boletín era ligeramente diferente.

Para ilustrar el prolongado lapso de tiempo que transcurrió entre el descubrimiento y notificación del problema (finales de julio de 2003) y la disponibilidad del parche (febrero de 2004), eEye añadió un preámbulo al boletín con el texto de una canción. Por si no fuera poco, eEye explicaba: "Nos hubiera gustado escribir un poema del tipo 'Una noche antes de Navidad', pero el fabricante ha dejado pasar algunas fechas, por lo que debemos de acudir a MC(SE) Hammer". A continuación, publicaban la letra de la canción "U Can't Trust This" ("No puedes confiar en esto").

Esta canción, por descontado, incluye un buen número de referencias a los diversos problemas de seguridad que ha sufrido recientemente Windows. En varias ocasiones, desde Hispasec, hemos comentado el método tradicional (y no escrito) utilizado por la comunidad especializada en seguridad informática en lo referente al descubrimiento de vulnerabilidades. Así, tradicionalmente, se suele poner en preaviso a la empresa afectada, facilitando toda la información técnica y todos los detalles conocidos en primer lugar a la empresa y, en la medida que sea posible, colaborar en la resolución del problema.

Por su parte, el descubridor de la vulnerabilidad asume el compromiso moral de no desvelar la existencia de la misma hasta que el fabricante no distribuya públicamente la actualización necesaria para eliminar el problema. ¿Es normal tardar más de 28 semanas en publicar un parche para una vulnerabilidad tan importante como esta? Se puede aducir, por parte del fabricante, que el desarrollo de una actualización no es una tarea trivial, ya que se hace necesario investigar y verificar que las modificaciones efectuadas no afectan negativamente al funcionamiento normal y esperado del producto.

Igualmente, deben utilizarse unos mecanismos muy precisos para garantizar que las modificaciones efectuadas pasan a formar parte del repositorio oficial del producto (evitando, de esta forma, los problemas de regresiones). Pero incluso asumiendo estos condicionantes que acabamos de citar, un periodo de 28 semanas (200 días) es muy difícil de justificar. Durante todo este tiempo Microsoft ha conocido la existencia de una importante vulnerabilidad de seguridad, que afectaba a un gran número de sus productos (incluyendo sus buques insignias) y que podía ser utilizada por atacantes remotos para ejecutar código de forma impune e incontrolable.

Otras vulnerabilidades

eEye parece que se ha cansado de esperar indefinidamente la respuesta de Microsoft a los problemas que van descubriendo. Así, acaba de publicar una página de "próximos avisos", indicando la fecha de la notificación y el número de días que han transcurrido sin que Microsoft aporte una solución.

En esa relación de vulnerabilidades existentes y no solucionadas, por lo que cualquier intruso que conozca su existencia puede sacar provecho de las mismas, eEye avisa de la existencia de cinco vulnerabilidades críticas (aquellas que permiten la ejecución de código por un atacanteremoto) que afectan potencialmente a varios centenares millones de usuarios. También se citan tres vulnerabilidades de severidad media y una vulnerabilidad de severidad baja.

Todas estas vulnerabilidades han sido convenientemente notificadas a Microsoft y el lapso de tiempo que ha transcurrido es, en el momento de redactar este boletín, entre 0 y 98 días. Sin llegar, de momento, al extremo recientemente vivido con la vulnerabilidad en la biblioteca ASN.1, a mi entender 98 días ya es un periodo de tiempo demasiado prolongado para una vulnerabilidad crítica.

Más información

eEye Upcoming Advisories