En un tiempo récord, Oracle ha publicado una nueva versión que corrige el grave fallo en JRE publicado hace unos días.Además ha mejorado la configuración por defecto. ¿Qué esconde esta decisión? ¿Es efectiva?
Aunque Oracle se ha apresurado a publicar la versión 7u11 de su JRE para corregir el grave fallo de seguridad que estaba siendo aprovechado por atacantes, el paso más importante que ha dado Oracle es subir la seguridad por defecto a “alta” para el plugin web. Con esta nueva configuración, se preguntará al usuario si quiere ejecutar un applet no firmado. Esto es relevante por varias razones. Hace unas semanas, escribíamos:
“Por defecto (como muy probablemente lo dejarán la mayoría de usuarios), viene configurado para ejecutar sin preguntar applets no firmados [..]. Los atacantes encontrarían un mayor obstáculo si tuviesen que firmar los applets maliciosos y que fueran validados por una entidad de confianza. Esto sí podría suponer un pequeño freno“.
Oracle incluía esta configuración que permitía de forma cómoda exigir que los applets estuvieran firmados, tras un 2012 desastroso donde varias vulnerabilidades se convirtieron en el vehículo preferido para que los atacantes lanzaran agresivas campañas como la del virus de la policía. Recién estrenado 2013 aparece otro grave fallo. Ahora mejora el tiempo de respuesta, pero además marca un importante hito. Al subir por defecto la seguridad a “alta“, está “obligando” a que los applets tengan que estar firmados por entidades de confianza para que sean ejecutados, pero deja la última palabra al usuario. Esto, como siempre, es una mala decisión.
El usuario no suele hacer buenas elecciones en seguridad, simplemente porque no entiende y quiere obtener lo que busca de forma cómoda. Este sistema de diálogo donde la pelota cae de del lado del usuario, sin duda es un avance, pero también puede suponer un problema para las páginas legítimas que lanzan applets y no los han firmado. Se bloquearán y los usuarios menos experimentados puede que piensen que le están atacando. Este, suponemos, era uno de los temores que estacaban a Oracle en una configuración insegura. Pero parece que lo van superando. Ya no les importa “romper” en cierta manera páginas legítimas con tal de detener una sangría que está dañando la imagen de Java en la web.
Pero esa decisión también puede estar motivada porque Oracle sabe que su modelo de seguridad de los applets de Java es un desastre, y que funcionar reactivamente parcheando sus versiones no es la mejor manera de avanzar. Según Adam Gowdiak siguen existiendo decenas de vulnerabilidades conocidas en Java, esperando ser aprovechadas por los atacantes. Tantas que, según HD Moore, a Oracle le llevaría dos años solucionarlas todas. Para colmo, los últimos fallos se basan en el diseño, no en un problema de programación concreto. Estos son más difíciles de solucionar de raíz.Por tanto, ese movimiento forzando en cierta manera que los applets estén firmados es más importante de lo que parece. Asume que, o bien comienza a tomar soluciones reales, o Java para la web puede quedar condenado a la extinción como sinónimo de problemas de vulnerabilidad.
¿Será una solución efectiva?
En principio, no es mala idea. Lo ideal hubiera sido bloquear todos los no firmados (en la configuración “muy alta“), pero algo es algo. Los applets de los atacantes no suelen estar firmados, por lo que al menos, ya no se ejecutarán automáticamente, por defecto y de forma totalmente transparente. Habrá un diálogo previo. Toca al usuario decidir qué hacer.
Además, sabemos que el modelo de firma pública no es perfecto, y que incluso en los últimos años, hemos observado varios incidentes relacionados con certificados que permiten a los atacantes o bien firmar nuevos o bien crear nuevos. Se han dado muchos casos de malware firmado legítimamente.
Por tanto, ahora los atacantes pueden o bien intentar firmar sus applets, o bien continuar confiando en que los usuarios no actualizarán a la versión 7u11, con lo que seguirán como siempre, solo que con un mercado de potenciales víctima menor. Pero lo más probable es que no ocurra nada, puesto que usarán la ingeniería social para hacer que el usuario piense que es indispensable que deba aceptar el diálogo propuesto y así seguir infectando como hasta ahora. Más incómodo pero también muy efectivo.
¿Acaso los usuarios medios saben qué es un applet y qué consecuencias tiene? Probablemente creerán que es una simple formalidad, y lanzará la ejecución. Esto, si bien no es la situación ideal para el atacante, no detiene el problema por completo.
En cualquier caso, si bien Oracle parece apuntar en la buena dirección, casi siempre lo hace tarde o de forma incompleta. Este movimiento podía haberse realizado hace varios años, desde que comenzó una vorágine de vulnerabilidades en su máquina virtual o, lo que es mejor, bloquear directamente todo lo que no esté firmado. Al final, han acabado tomando una decisión en la dirección buena… pero en el camino los atacantes han ganado unos buenos beneficios y Oracle ha perdido credibilidad.
Y posiblemente el impacto para el usuario no sería para tanto ante un cambio en la configuración por defecto incluso más drástico. Se adaptarían. Microsoft tuvo que esperar a que pasaran Blaster, Sasser y otros importantes gusanos para activar el cortafuegos de XP por defecto en 2004. Muchos usuarios y programadores encontraron un grave problema que les produjo muchos dolores de cabeza… pero mereció la pena. No hay que menospreciar la capacidad de adaptación del usuario, programadores y administradores.
Más información:
Oracle updates Java, security experts say bugs remain
Update Release Notes
Sergio de los Santos
Twitter: @ssantosv
¿Qué espera Oracle para matar de una vez al maldito plugin? NO TIENE NINGUN SENTIDO EN 2013. Mejor sería que el plugin fuera una instalación separada opcional, fuera del JRE, para que fuera instalado solo REALMENTE donde se necesite en entornos controlados.
Los plugins para navegadores son el principal vector de ataque en los últimos años, sea Java, Flash, Acrobat, Real, etc. HAY QUE MATARLOS de una vez.
Sino, creo que los navegadores deberían tomar la decisión de desactivarlos definitivamente, no solo cuando hay una vulnerabilidad detectada, sino hasta que el usuario los reactive explícitamente bajo su responsabilidad. Es irresponsable activarlos por defecto.
Tristemente la inacción y mal manejo de Oracle con estos temas, está manchando el prestigio de Java como tecnología en general, especialmente del lado del servidor. Pero claro, como Oracle insiste con promover su JavaFX destinado al fracaso, no podría matar al PLUGIN que este requiere para usarlo con la web. Es una política destinada al fracaso que le puede costar muy caro a una tecnología de servidor muy buena.
No hay que confundir la probada y segura tecnología Java del lado del servidor, con el Java en otros entornos. La irresponsabilidad de Oracle está manchando todo el conjunto.
ya podeis ir modificando este texto porque según un experto de seguridad este acaba de encontrar una nueva vulnerabilidad 0 day en la versión última(7 u11)
http://krebsonsecurity.com/2013/01/new-java-exploit-fetches-5000-per-buyer/