domingo, 3 de febrero de 2013

Mejorar y entender la seguridad del plugin de Java (IV)

El plugin de Java se está convirtiendo en un serio problema de seguridad, llevamos meses comprobándolo. Oracle ha añadido seguridad en su configuración por defecto, y ofrecido más granularidad a los usuarios. Pero todavía es mejorable. ¿Para qué sirven las nuevas funcionalidades y qué se puede esperar de ellas?

Ahora que conocemos un poco más qué hay que prevenir en Java, conviene analizar cómo es posible configurar esto. La forma habitual es a través del panel de control o lanzándolo desde línea de comandos.

C:\Program Files (x86)\Java\jre7\bin>javacpl

Desde la pestaña seguridad, se puede configurar lo más importante, mientras que desde la pestaña avanzado se puede afinar para conseguir un plugin más seguro.

Java también permite realizar cambios desde un fichero de configuración. Esto es muy útil en entornos corporativos. Se puede realizar de dos formas. Una para el usuario activo, y otra a nivel de sistema. En el primer caso, los ficheros deben almacenarse en:

%appdata%\Sun\Java\Deployment\deployment.config

Y en el segundo,

%windir%\Sun\Java\Deployment\deployment.config

En este fichero se indica con dos líneas en su contenido dónde se alojarán las propiedades, y si son "obligatorias"

deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=true

Las propiedades

Existe un buen puñado de propiedades que pueden ser configuradas aquí, casi tantas como la interfaz de configuración. Lo interesante (que no puede hacerse por la interfaz) es que se pueden "bloquear", de forma que no sean modificables por el usuario.

Estos cambios en el fichero se traducirán también en un cambio en el registro, como se puede observar en la imagen.


Para entornos centralizados es la mejor opción para una configuración "masiva" de puestos de trabajo.

Los certificados

Otro aspecto interesante es controlar los certificados y saber cuáles se almacenan como de "confianza" para Java e incluso cuáles están en la lista negra. Toda esta información está en los ficheros c:\Program Files\Java\jre7\lib\security\cacerts y C:\Program Files\Java\jre7\lib\security\blacklist.

Se pueden añadir o ver los certificados a través del panel de control o de línea de comando con "keytool" (contraseña "changeit" por defecto).

El caso de los certificados "bloqueados" en la lista negra es muy curioso. Como ha analizado Neal Poole en su blog, la lista negra de applets firmados es totalmente opaca para los usuarios, y no permite actualización dinámica. De hecho, Oracle no da información sobre qué Jars bloquea en la lista ni por qué razón. Simplemente, con cada nueva versión de Java, se actualiza (o no) la lista. No hay actualización dinámica. Se supone que cada uno de las "firmas" en el archivo corresponde con un archivo malicioso encontrado con anterioridad. El problema es que Neal Poole está intentando que Oracle meta en la lista negra un Jar del que tiene conocimiento desde hace un año... y todavía no lo ha conseguido.


Por supuesto, no existe posibilidad de una lista blanca, que quizás sería lo más interesante en el caso en el que se utilicen solo ciertos applets firmados. Para "simularlo", se pueden eliminar los certificados que no interesen con la "keytool" y su opción de borrado.

Veremos en una próxima entrega otras formas de proteger el plugin a través de las funcionalidades del navegador.

Más información:

How Hard Is It To Blacklist A Java Applet?

Deployment Configuration File and Properties

una-al-dia (28/01/2013) Mejorar y entender la seguridad del plugin de Java (I)

una-al-dia (29/01/2013) Mejorar y entender la seguridad del plugin de Java (II)


una-al-dia (30/01/2013) Mejorar y entender la seguridad del plugin de Java (III)


Sergio de los Santos
Twitter: @ssantosv

No hay comentarios:

Publicar un comentario en la entrada