¿Cuánto se tarda en resolver una vulnerabilidad?

En el momento en que se anunció la disponibilidad del parche para la
vulnerabilidad en la biblioteca ASN.1 de Windows, los descubridores del
problema mostraron públicamente su queja por el prolongado periodo de
tiempo que transcurrió entre el descubrimiento y la disponibilidad del
parche, especialmente teniendo en cuenta la criticidad del problema.

Cuando 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 atacante
remoto) 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.