Java (por fin) permite mejorar la configuración de seguridad

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.

Java.png

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.
 Fuente