Oracle desvela el futuro de la seguridad de Java en el navegador

Oracle debe tomar cartas en el asunto. Desde principios de 2013 ha comenzado una estrategia para mejorar la seguridad de Java en el navegador, pero el tiempo se le echa encima. Además, Oracle es una compañía que no se caracteriza por dinamizar sus productos. Es muy conservadora y en seguridad, siempre ha supuesto un considerable desastre que les ha acarreado una fama de la que les cuesta librarse. El desarrollador jefe de Java, Nandini Ramani, ha escrito un post hablando del futuro de la seguridad en Java, sus planes y una pequeña valoración del estado del producto.

Si en 2012 se cerraron 58 vulnerabilidades, en lo que llevamos de 2013 (solo la mitad) ya se han solucionado 97. Ramani achaca este incremento a que desde la compra del producto a Sun, Java está ahora sometido a los estrictos estándares de seguridad de Oracle. De hecho explica que se están usando más “herramientas automáticas” para “abarcar más código“ y evitar así que se introduzcan nuevas vulnerabilidades.

Los números no son definitivos para valorar la seguridad. Como ya se ha mencionado, Chrome en cantidad de vulnerabilidades corregidas es un desastre pero se puede considerar el navegador más seguro por otros factores. En este caso el problema es además de la cantidad, la calidad: fallos graves y muy relevantes que han sido corregidos muy tarde, que siguen siendo tremendamente explotados, que son sencillos de aprovechar por los atacantes, o que han surgido en forma de 0day. El problema no es que corrija gran cantidad de fallos (que puede considerarse algo positivo y bien visto) sino que la “calidad” de estos fallos es muy atractiva para los atacantes. De esos casi 100 fallos en 2013, se explotan activamente muy pocos, apenas media docena, que son muy efectivos entre las víctimas.

Así que a partir de octubre, Oracle publicará parches de forma coordinada con el resto de sus productos. Cuatro veces al año y cada tres meses. Esta medida va en línea con la que adoptó hace poco y en la que se propuso una nueva estrategia de numeración de sus versiones. Ramani también afirma lo que ya veníamos avisando que tendría que pasar tarde o temprano. Terminará por bloquear por defecto los applets no firmados y los autofirmados. En Java 7 u21 se introdujo algo positivo: estar firmado ya no significaba necesariamente salir de la sandbox. Así que siguen peleando en este aspecto para que la criptografía sea realmente útil en su modelo de seguridad.

También parece que van a modificar su pobre modelo de lista negra de applets. Se trata de un fichero de texto plano que se descarga con cada nueva versión. Van a dinamizarlo publicando actualizaciones diarias. Esto es curioso puesto que hasta ahora, se actualizaba muy de vez en cuando. Apenas contiene 40 bloqueados en estos momentos y la cifra no ha variado demasiado en los últimos años. Esto terminará en la activación del Online Certificate Status Protocol (OCSP) por defecto. Por último, entre otras medidas, planean un sistema de seguridad que sea más útil para un administrador, y le permita elegir durante la instalación qué nivel de seguridad proporcionar.

En el apartado de servidor, debido a la mala fama que le está otorgando el Java “de cliente” en las empresas, separarán claramente el “Server JRE” para que los administradores de servidores no tengan miedo de instalar su parte servidora debido a los problemas en el plugin (parte cliente), y reducir así el vector de ataque.

Estas son medidas lógicas, cuyas carencias ya veníamos criticando en una-al-día desde hace tiempo como fallos básicos en la seguridad en conjunto de Java y los applets. Al menos se muestra la voluntad de cambio, aunque sea tarde y en un periodo no determinado (probablemente necesite todo 2013 para realizar estos movimientos).

  

Sergio de los Santos

Twitter: @ssantosv