Los desarrolladores de Firefox debaten dejar de soportar Java por motivos de seguridad
AbrahamLos desarrolladores de Firefox están debatiendo hacer que el navegador web deje de soportar el plugin Java para mitigar los problemas derivados del ataque "BEAST" presentado la semana pasada por Duong y Rizzo en la conferencia Ekoparty. Este ataque permite desencriptar tráfico https del navegador web; aunque es bastante CPU intensivo en la conferencia sus creadores demostraron como eran capaces de robar una cookie https de Paypal en un par de minutos.
Debido a un bug en Java, un Applet Java no firmado y sin permisos puede establecer conexiones de red con servicios que estén corriendo en el local host. El ataque de Duong y Rizzo consiste en emplear un snipher local en el equipo del usuario atacado para ver el tráfico encriptado, y a continuación emplea un ataque criptográfico (que todavía no entiendo en detalle, pero de lo que no hay duda es que funciona) contra los datos.
Este ataque es bastante serio ya que virtualmente convierte a una conexión https en vulnerable si el usuario tiene cargado en otra pestaña del navegador código malicioso. El principal vector de ataque (quizás el único en la práctica según algunos comentarios en el foro de Mozilla) es Java, por lo que se están planteando deshabilitar el plugin Java en FireFox.
La discusión fundamentalmente va en la línea de sí la seguridad para los usuarios compensa la mala experiencia que van a tener; Java todavía se emplea en Applets para alguna que otra aplicación bastante extendida como el video-chat de Facebook.
Chrome por su parte parece haber arreglado temporalmente este problema rompiendo en fragmentos los datos que se van a encriptar. Esta actualización está disponible en la versión beta del navegador. Aunque esta solución parece estar causando bugs en el funcionamiento del navegador web de Google con alguna web.
Al margen de lo que el ataque BEAST pueda significar para https, está claro que esto es una mala noticia para Java. Una vez más, Java y el escritorio se lleva la fama de ser una forma para comprometer la integridad de los equipos de los usuarios.
Oracle tiene que hacer algo sobre estos continuos problemas de seguridad de Java si quiere que empresas como Facebook siga usando esta tecnología para aplicaciones de cliente, y sea más largo plazo quiere que JavaFX tenga futuro.
Reader Comments (10)
Espero que los elementos de defensa se pongan las pilas, porque sería un palo gordo para Java. Lástima de no tener tiempo para profundizar en el tema, pero a bote pronte, parece sencillo echar la culpa a Java, ¿no?
Entiendo que si el usuario no tiene el virus en su ordenador, no hay problema. El problema no es sólo Java, si no que el usuario tiene un virus en su propio ordenador. Echar la culpa a Java en este caso es limitarse a ver sólo una parte del problema....
Vamos, es solo una opinión.
Desde mi punto de vista, la culpa sí es de Java. Y ya tengo hablado largo y tendido en el pasado de esto. Java, al menos en 2010 (Microsoft todavía no ha publicado datos de 2011) era el principal vector de ataque para PCs Windows. Oracle tiene que cambiar la política de actualización de Java si quiere que Java tenga futuro en el escritorio. Y ya está tardando demasiado en hacerlo.
Java está ganando muy mala fama, con motivo, en temas de seguridad que escritorio. Este ataque (BEAST) es uno más. Y el problema es que ahora Oracle no tiene una buena forma de actualizar (cuando tenga el parche...) todos esos JREs. Sin actualizaciones automáticas, la mayor parte de la gente no se va a bajar una nueva versión de Java, sobre todo cuando no saben tan siquiera qué demonios es eso de "Java" que muestra una taza de café en la barra de tareas de su equipo y que nunca usan para nada. Si no lo usan ¿para qué lo van a actualizar?
Perdón, pero Java FX no fue discontinuado ya?
No, si al final vamos a usar JavaScript ... Una decada mas y no nos quedara mas remedio. Incluso habra buenas APIs. <sarcasmo off>
No, Java FX no fue discontinuado. Sólo si discontinuo Java FX script.
Aunque no hay que quitarle mérito a Java y sus applets no firmados, el ataque en sí es una vulnerabilidad del protocolo TLS.
Pero bueno, el agujero de la JVM en sí es como para quitarse el sombrero....
Entiendo la parte de culpa de Java en este asunto, pero toda la fanfarria que se le está dando sobre que es una vulnerabilidad de Java la que permite todo esto me parece "publicidad interesada".
Es decir, para explotar esta vulnerabilidad tienes que tener un sniffer malicioso en marcha en tu ordenador. O sea, vamos, el piratoide interesado te ha colado un sniffer en tu sistema y puede espiar todas tus comunicaciones y el problema "supergordo" es que Java se pueda comunicar con ese sniffer...
Y sobre las estadísticas de Microsoft sobre vías de ataque a Windows... sí hombre, me voy a creer yo lo que me dice el perro pastor sobre los ataques a las ovejas.
Basta con hacer una simple comparación entre Firefox y Java, en temas de seguridad, para caer en la cuenta de dónde han estado desde siempre los mayores problemas.
Java Security : http://www.oracle.com/technetwork/topics/security/alerts-086861.html
Firefox Security: http://www.mozilla.org/security/known-vulnerabilities/
Como se ha apuntado en un mensaje anterior, y se reconoce abiertamente en el foro de discusión de Firefox, a partir del comentario nº 40 en adelante, el principal problema es TLS 1.0
Creo que se conoce poco que JAVASE 1.7 incluye TLS 1.1 que es inmune al ataque de referencia; sin embargo esta desactivado por defecto. La razón es la misma por la que Java puede ser utilizado para ese tipo de ataque: que la inmensa mayoría de sitios web no funcionan con TLS 1.1
Habrá que ver lo que comenta Oracle sobre la posible solución a este problema.
El problema no es un sniffer, eso se consigue hacer fácil, ¿cuántos de ustedes usan WIFI en un café, en un salón e incluso se topan cada tanto con una red con "protección" WEP?
El tema tampoco es sólo de FF, esto pasa en la mayoría de los navegadores y tampoco es tan exclusivo de Java, si leen el paper van a ver:
"The author of this papers then collected a list of browser features and plugins that satisfy this condition. Surprisingly, there are a lot of them, including but not limited to Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java
Applet URLConnection API, and Silverlight WebClient API"
O sea, no es solo Java, de hecho la mayoría de código de la demo es javascript y la parte hecha en Java se podría haber hecho con cualquier otra cosa.
De todos modos: Java desde que se hizo la compra de Oracle no viene bien parado y si además de éste, no arreglan otros problemas se van a ir al pozo. No nos olvidemos de políticas como la reciende de quitar licencia para la distribución en los Linux (donde al menos si Oracle no proveía un mecanismo fiable de actualización lo hacia el repositorio) van a enterrarse cada vez más.
Pues bien, tenemos navegadores que no soportan flash, ahora vamos a tener uno que no soporta Java. Por suerte tenemos Chrome que soporta todo.