No es habitual que Oracle emita una nueva versión de Java que no corrija fallos de seguridad. Sin embargo, la nueva versión 10 de la rama 7 ha nacido para incluir mejoras de seguridad (que no es lo mismo que corregir fallos). Además, algunas bastante interesantes que, dados todos los problemas que está causando, resultan necesarias.
En estos momentos y dese hace ya muchos meses, Blackhole es la herramienta preferida de los atacantes para infectar sistemas. Dentro de esta “suite” de explotación, las vulnerabilidades preferidas que más éxito tienen entre las víctimas son las relacionadas con Java, seguidas por los problemas en Flash y Windows. Sin ir más lejos, según nuestras propias estadísticas (basadas en varias decenas de casos a empresas y particulares en los últimos meses), Java está detrás de prácticamente el 100% de las infecciones por el troyano bancario Citadel (Zeus).
Así que cualquier mejora en la seguridad de Java es bienvenida. Varios navegadores están bloqueando las versiones no actualizadas, en un intento por proteger a sus usuarios. Pero Oracle ha decidido facilitar este aspecto a los usuarios. En esta ocasión, se han centrado en mejorar el panel de configuración del programa para permitir elegir una configuración más o menos segura. Por supuesto, y tropezando en la misma piedra de siempre, la configuración por defecto no es la más adecuada.
En el panel de control de Java, se podrá ahora desactivar cómodamente Java para el navegador, algo que se debería llevar a cabo. Sin embargo, Oracle permite ahora elegir diferentes niveles de “seguridad“, basados en si un applet está firmado (se considera “de confianza“) y en si se ejecuta sobre una versión de Java “segura” o no. Con versión “segura” se refieren a que sea la última publicada y esté actualizada.
Los niveles predeterminados juegan con diferentes combinaciones de estos parámetros. En “bajo“, todos los applets se ejecutarán sin preguntar a menos que lo intenten sobre una versión antigua o pregunte por recursos protegidos. En “muy alta“, todos los applets (firmados o no) pedirán confirmación y bloqueará directamente la ejecución en un JRE antiguo.
Por defecto (como muy probablemente lo dejarán la mayoría de usuarios), viene configurado para ejecutar sin preguntar applets no firmados en una versión “segura“. En realidad, actualizada a la última y “segura” no son siempre sinónimos ni en Java ni en ninguna aplicación. Recordemos que no hace mucho, varias vulnerabilidades de Java han estado siendo aprovechadas por atacantes sin que existiese un parche. Por tanto la última versión era “segura” para sus parámetros. También porque confían en un applet (que no deja de ser un programa) sin firmar para ejecutarse de forma transparente para el usuario. 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. Las páginas legítimas que usen applets, se verían así obligadas a firmar su código para evitar problemas.
En cualquier caso, una mejora interesante y necesaria.
Más información:
Java SE Development Kit 7, Update 10 (JDK 7u10)
Blackhole: Today’s malware market leader
Sergio de los Santos
Twitter: @ssantosv
Muy bueno, lo estabamos esperando
Muy bueno, lo estabamos esperando