Graves vulnerabilidades en Adobe Shockwave, necesitarán dos años para solucionarse

Shockwave es un plugin para navegadores que, aunque también de Adobe, no debe confundirse con Flash. En cierta manera, es menos popular pero más potente a la hora de desarrollar gráficos y juegos. Como ocurre con Java, muchos usuarios puede que lo tengan instalado en sus navegadores pero realmente no lleguen a usarlo a menudo si no visitan habitualmente páginas que lo requieran.

El US-CERT ha publicado tres graves vulnerabilidades que permiten la ejecución de código: CVE-2012-6271, CVE-2012-6270 y otra con CVE por determinar. Eludiendo los detalles técnicos, básicamente las tres vulnerabilidades permiten la ejecución de código arbitrario con solo visitar una web que aloje un archivo Shockwave especialmente manipulado, por supuesto de forma transparente para el usuario (si no ha configurado su navegador para evitar este tipo de plugins).

Esto no sería noticia si no fuese porque el US-CERT alertó a Adobe del problema en octubre de 2010. Ambos han mantenido silencio hasta ahora. Brian Krebs escribió a Adobe y le indicaron que la compañía solucionará el problema en la próxima versión de Shockwave que se lance, lo que ocurrirá en febrero de 2013. ¿La razón? Simplemente, no se apresuran a corregir el error mientras no se conozca que el fallo está siendo aprovechado por atacantes. Y por ahora parece que no es así.

El comportamiento de Adobe no es nada nuevo en la industria (y mucho menos en su empresa, donde la seguridad no parece ser prioritaria). Los fabricantes de software tienden a priorizar los problemas de seguridad más acuciantes, pero parecen relegar indefinidamente el resto. Parecen barrer debajo de la alfombra todo lo que no suponga una amenaza confirmada. Es habitual observar como las empresas posponen indefinidamente la solución a vulnerabilidades de las que son conscientes hasta que salen a la luz o, lo que es peor, se conoce que están siendo aprovechadas por atacantes. En ese momento, priorizan el problema hasta solucionarlo cuanto antes. De hecho, no es de extrañar que tras el reconocimiento de estas vulnerabilidades y los pocos detalles que se ofrecen, ya se estén analizando concienzudamente para encontrar los detalles técnicos y aprovechar la ventana de tiempo existente hasta la supuesta solución. En ese caso (y solo en ese) quizá sacarían un parche antes de la fecha prevista.

En un estudio que realizamos hace un tiempo, concluíamos que, mientras la vulnerabilidad permaneciese en secreto, los grandes fabricantes podían pasar hasta seis meses de media sin arreglarla. Sin embargo, en cuanto salen a la luz, es cuestión de pocas semanas o días que aparezca un parche oficial.

 

No es extraño que con este comportamiento, el propio ecosistema se haya adaptado sus reglas para «acelerar el proceso«. Zero Day Initiative tuvo que imponer un límite de 180 a los fabricantes para solucionar sus fallos, o de lo contrario los haría públicos. Los investigadores independientes, por su parte, encuentran en la publicación de los detalles una manera de presionar a los responsables cuando según su criterio han esperado demasiado tiempo una solución.

Es cierto que arreglar vulnerabilidades en software medianamente complejo y tan popular, no es tan sencillo como parece. De hecho, queremos entender que el retraso en la publicación de parches no se debe a la desidia, sino a la priorización de beneficios y manejo de recursos. ¿Qué es más conveniente para la empresa?: ¿Invertir en el desarrollo y mejora del producto o en la seguridad? ¿Reinventar el producto y mejorar su protección o seguir hacia delante con paños calientes y parches? ¿Es mejor asegurarse de que un parche no «rompe» nada, y para ello tomarse el tiempo necesario en pruebas, o lanzarlo cuanto antes aun a riesgo de fallar de alguna forma y empeorar la imagen de la empresa? Las compañías disponen de recursos finitos para el estudio y reparación de vulnerabilidades, y reparten los existentes entre los diferentes fallos de forma que se solucionan antes las que más riesgo conllevan y se relegan las menos prioritarias. El problema es que cuando se trata de software tan popular, la responsabilidad del fabricante es muy alta, siendo finalmente el usuario el que sale perdiendo.