Cómo funcionan las nuevas listas negras en Java y cómo aprovecharlas (usando listas blancas)

Oracle ha introducido la noción de lista blanca en su última versión de Java 7 update 40. Es un gran paso adelante (tomado demasiado tarde) en seguridad para esta plataforma pero… ¿cómo funciona? ¿cómo se maneja con versiones más antiguas? Y lo más importante ¿cómo se consigue bloquear todo excepto algunos applets que se quieran?

Esta es la primera vez en años que Java permite hacer lista blanca de applets. Se ha convertido en una necesidad real para la seguridad, a causa de los numerosos kits existentes que aprovechan cualquier problema relacionado con Java y su “inseguridad natural”. Antes de esta versión, Java disponía ya de una lista negra de algunos applets. Pero el sistema está totalmente manejado por Oracle, actualizado solo en cada versión, no es dinámico y se encuentra muy mal documentado. Pero ahora, al menos con Java 7u40, se tiene la oportunidad de realizar listas blancas con bastante granularidad. Pero no es trivial.

Se necesita un fichero ruleset.xml, compilarlo y firmarlo. Para firmarlo se puede usar un certificado “real” o un autofirmado creado ad-hoc e introducido en el repositorio de confianza.

Paso a paso. Creando el ruleset.xml

Se trata de un fichero XML estándar con una sintaxis relativamente simple. Es posible bloquear o permitir applets dependiendo del dominio del que provengan o dependiendo de quién los ha firmado. También se puede especificar bajo qué versión de Java se quiere que se ejecute. Acepta comodines y reglas por defecto, lo que lo hacen muy granular. En el ejemplo, se crea un fichero que permite que funcionen solo los applets alojados en java.com y bloquear el resto.

<ruleset
version=”1.0+”>

<rule>

  <id location=”http://*.java.com”
/>

  <action
permission=”run” version=”SECURE-1.7″ />

</rule>

<rule>

<id
/>

  <action
permission=”block”>

  <message>Bloqueado por las
reglas del sistema</message>

</action>

</rule>

</ruleset>

El último “id” indica que es la regla predeterminada y casa con cualquiera que no haya casado antes. La etiqueta “version” puede ser cómoda… o peligrosa. Permite especificar que un applet funcionará solo con la versión (antigua) deseada y eso, por definición, traerá problemas de seguridad. Así que si el sistema mantiene versiones antiguas (6.x) y un applet las usa, es necesario tener en cuenta que estas reglas no aplican en la rama 6.x de JRE y no se bloqueará nada. En resumen, mantener esa rama en el equipo podría anular toda la seguridad.


Los ruleset permite ejecutar, por ejemplo, solamente applets firmados por un certificado concreto… y mucho más. Las especificaciones están aquí.

Paso a paso. Crear el jar y firmarlo

Se debe descargar el JDK y ejecutar:

C:Archivos
de programaJavajdk1.7.0_40bin>jar -cvf DeploymentRuleSet.jar rulset.xml

Una vez creado, firmarlo:

C:Archivos
de programaJavajdk1.7.0_40bin>jarsigner -verbose -keystore keystore.jks
-signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar selfsigned

Donde “keystore.jks” podría ser el repositorio de claves normal y “selfsigned” el alias del certificado. Si ya se tiene un certificado válido (firmado por una CA), se puede eludir el siguiente paso. Si no, se puede crear un certificado autofirmado con el siguiente comando:

keytool
-genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass 123456
-validity 360 -keysize 2048

Donde “123456” es la contraseña necesaria para desbloquear el repositorio (no confundir con la contraseña del propio certificado).

Hará algunas preguntas. No importan las respuestas.

Finalmente, se exporta el certificado:

keytool
-export -alias selfsigned self.crt -keystore keystore.jks

Y debe importarse como raíz de confianza. Se podría hacer en Windows (instalándolo en certmgr.msc) o dentro del repositorio proipo de Java, de esta forma:

C:Archivos de programaJavajdk1.7.0_40bin>keytool -importcert -alias selfsign

ed -file self.crt -trustcacerts -keystore ….jre7libsecuritycacerts

Ahora que DeplymentRuleSet.jar está firmado por una raíz de confianza, se puede copiar a su sitio (es curioso que Oracle todavía conserva muchos nombres “Sun” cuatro años después).

C:Archivos
de programaJavajdk1.7.0_40bin>copy DeploymentRuleSet.jar c:WINDOWSSunJavaDeploymentDeploymentRuleSet.jar

Si se ejecuta javacpl.cpl se puede comprobar que Java está al tanto de las reglas:

Comprobándolo todo

Así, si se comprueban applets en el dominio especificado (lista blanca), se ejecutarán pero cualquier otro será bloqueado. Esto es bastante interesante y una funcionalidad muy esperada (si no se tienen que mantener versiones antiguas).

Conviene no olvidar:

• Todo esto no tiene sentido si no se desarrollan otras medidas de seguridad en Java. Por ejemplo elevar la palanca de seguridad a “alta” en las opciones de seguridad. Por ahora, con esta palanca se podría “proteger” al usuario del malware “autofirmado”, pero ¿qué pasa con el código bien firmado? Esta funcionalidad trata de llenar ese hueco.

• Muy importante: un applet considerado en la lista blanca a través de cualquier regla, hace que el resto de pantallas de advertencia introducidas en Java 7u10 desaparezcan antes de su ejecución.

• Todo esto no es útil si Java no se actualiza regularmente y se eliminan las versiones antiguas del sistema si no se necesitan.

Como curiosidad, si se usa un certificado en el que no se confía para firmar DeploymentRuleSet.jar, se bloquearán también los applets, pero con otro mensaje.

Es importante notar que Oracle ha advertido que si encuentra certificados que firmen ficheros DeploymentRuleSet.jar que permitan ejecutar todo sin restricciones, los meterá en la lista negra definitiva. 

En cualquier caso,
Oracle tiene que mantener la compatibilidad hacia atrás con la rama 1.6 incluso cuando se le deje de dar soporte. Esta ha sido la mejor manera que han encontrado para ayudar a los administradores con una herramienta nativa que controle la locura del plugin de Java. No está mal.

Sergio de los Santos

ssantos@11paths.com

@ssantosv