El US-CERT ha alertado sobre tres graves vulnerabilidades en Adobe
Shockwave que permiten la ejecución de código en el sistema con solo
visitar una página web. Según el aviso, Adobe fue alertado sobre el
problema en octubre de 2010, pero no solucionará los problemas hasta
febrero de 2013.
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í.
Ojos que no ven...
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.
Fuente
Shockwave que permiten la ejecución de código en el sistema con solo
visitar una página web. Según el aviso, Adobe fue alertado sobre el
problema en octubre de 2010, pero no solucionará los problemas hasta
febrero de 2013.
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í.
Ojos que no ven...
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.
Fuente