Mejorar y entender la seguridad del plugin de Java (I)
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?
Lo primero que es necesario entender cuáles son los riesgos de los applets de Java. La máquina virtual Java es la encargada de ejecutarlos y, por seguridad, los mantiene dentro de una "sandbox".
Esto quiere decir que no les permite acceder al disco, ejecutar
código... ¿Por qué son peligrosos entonces? Porque existen situaciones
en las que las que se les permite a esos applets salir de la sandbox. Si
ocurre esto, el applet se convierte a efectos prácticos en un
ejecutable (puede hacer prácticamente cualquier cosa con los permisos
con los que se ejecuta). ¿Bajo qué circunstancias pueden salir de la
sandbox?
- Oficialmente, solo cuando los applets están firmados por una entidad certificadora válida. Las entidades certificadoras válidas se pueden ver por la interfaz. Esas entidades pueden ser modificadas a través del fichero C:\Program Files\Java\jre7\lib\security\cacerts. Con "keytool" y sus opciones de "delete" e "import", se pueden configurar. Pero en las opciones de seguridad avanzada de Java, también se permite "Usar los certificados y claves del almacén de claves del explorador", con lo que hay que tenerlo en cuenta. Se puede confiar en más certificadoras de las que se cree.
- Un applet puede salir de la sandbox (aunque no esté firmado), por culpa de una vulnerabilidad en la propia implementación de la máquina virtual. Si la implementación de la máquina Java en sí (la parte escrita en C) contiene un desbordamiento de memoria intermedia, por ejemplo, puede que sea explotada y se ejecute código. Estas serían vulnerabilidades "clásicas" que atacan a la implementación. Su mitigación es como cualquier otra vulnerabilidad en un programa: usar herramientas antipayload, antiexploit... y por supuesto, mantenerse actualizado.
- Por último, un applet puede escapar de la zona de seguridad por un fallo de diseño "del lenguaje" que se lo permita. Las últimas vulnerabilidades más graves en Java han sido por esta razón (invocando clases privilegiadas desde código no confiable, serialización...). Esta es una de las razones por las que se insiste en deshabilitar por completo el plugin, puesto que supone un grave problema. Son un fallo intrínseco de diseño, que requieren un cambio profundo y que no serán solucionadas a corto plazo. Se sabe que la última versión sigue siendo vulnerable en este sentido y todavía quedan vulnerabilidades (fórmulas para eludir la sandbox) que descubrir.
¿Cómo defenderse? Deshabilitar Java si no se usa. Pero esto no
siempre es posible. Eliminar el problema no es una solución para todo el
mundo, sino otro problema adicional si de verdad se necesita esta
funcionalidad. Además, Java tiene el problema de que "no tiene competencia".
Solo queda entender cómo protegerse de manera más eficaz. Puesto que se
trata de contener la ejecución de applets dañinos que puedan eludir la
sandbox, la clave está en:
- La criptografía: hay que luchar contra los applets no
firmados (no suelen aportar nada bueno), autofirmados (son sospechosos),
y vigilar estrechamente los firmados (aun así el firmado solo garantiza
al autor, no sus intenciones).
- Actualización: No permitir que ciertos applets se lancen en versiones antiguas para evitar que se aprovechen de vulnerabilidades conocidas.
En este sentido de control de certificados y versiones, en la versión 7u10 se introdujeron los niveles de seguridad y la "autoconciencia" de ser una versión "insegura". Lo veremos en detalle la próxima entrega.
Fuente:
Comentarios
Publicar un comentario