Parece que el error no permite la ejecución de código, y (por ahora) representa un simple fallo que hace que la aplicación se cuelgue.
Desde el primer momento, tal y como anunciamos en un boletín anterior, no quedaba excesivamente clara la potencial gravedad de la vulnerabilidad. “En cualquier caso, se debe ser cauto, y todavía desde algunos foros, se sospecha del verdadero alcance del problema” decíamos entonces. No se tenían detalles, tan sólo una presentación en directo en una conferencia, aunque sí fue confirmado por algunos medios importantes como SecurityFocus. Finalmente, parece que las sospechas se confirman y la vulnerabilidad ha perdido bastante peso en cuanto a potencial dañino. Los propios responsables de la difusión del supuesto fallo han confesado que querían pasárselo bien y sin pruebas, afirmaron que podrían ejecutar código y que conocían muchas otras vulnerabilidades no reveladas. Pura fanfarronería.
Snyder, jefa de seguridad de Mozilla, ha confirmado que la denegación de servicio es reproducible en base a la información aportada por los dos bromistas, pero que no pueden confirmar la ejecución de código. A pesar de la desagradable broma, en Mozilla se lo toman en serio y lo están estudiando. Harán saber si en realidad es posible la ejecución de código. No en vano, es cierto que JavaScript es un problema real para todo navegador y ha sido fuente de graves vulnerabilidades anteriores.
Esperemos que no ocurra como con la reciente vulnerabilidad en el control ActiveX WebViewFolderIcon de Internet Explorer. El día 17 de julio HD Moore la descubrió y publicó que se trataba de una simple forma de hacer morder el polvo al navegador. Hubo que esperar al 27 de septiembre para que alguien hiciese pública una forma de aprovecharlo para ejecutar código y se convirtiese en una de las vulnerabilidades más explotadas del momento. Nunca se sabe.
La experiencia debe convencernos que no siempre todo lo que se dice o hace en una demostración en directo es cierto. Sin ir más lejos, una historia sospechosamente parecida ocurrió a principios de agosto, cuando Jon “Johnny Cache” Ellch y David Maynor quisieron demostrar en una presentación Black Hat cómo colarse en un Apple Macbook en 60 segundos a través de sus controladores “wireless”. Finalmente todo fue una gran exageración y la demostración, aunque vistosa, no era del todo real. En resumen, usaron otros controladores vulnerables que no pertenecían a Apple.
Todo esto ha servido, como también escribíamos anteriormente, para avivar la estéril polémica entre navegadores. A la espera de que se confirme si realmente existe un problema grave (posible, pero poco probable), lo que sigue siendo cierto es que, cada vez más, la seguridad del navegador depende en gran medida del usuario. Se deben tomar las medidas de seguridad adecuadas para usar de forma responsable cualquier programa. Las discusiones partidistas están de más, y sobre todo, las bromas de mal gusto con las que se busca una rápida notoriedad a costa de alarmar a los usuarios.
Hasta ahora ejercía como director de Grandes Cuentas. En el pasado trabajó para Veritas, Symantec…
Con Clumio Backtrack permite revertir objetos almacenados en Amazon S3 a una versión específica en…
Según Ookla, los mercados móviles de la Unión Europea con tres jugadores tienen velocidades de…
Los modelos 27B2G5500, 24B2G5200 y 27B2G5200 cuentan con tecnología PowerSensor que activa el modo ahorro…
Red Hat ha anunciado una versión preliminar de Red Hat OpenShift Lightspeed que permite aprovechar…
Acumuló 2.160 millones de dólares durante el tercer trimestre de su ejercicio 2025, de los…