Oracle se ha pronunciado sobre la
seguridad de Java y la gestión de sus
applets. Como responsable de una inmensa mayoría de las infecciones a través
del navegador, es
interesante conocer qué planes tiene la compañía para este producto en el
futuro.
Oracle debe tomar cartas en el
asunto. Desde principios de
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).
Más información:
Maintaining the security-worthiness of Java is
Oracle’s priority
Sergio de los Santos
Twitter: @ssantosv
Sinceramente creo que la situación de pánico anti-Java se les ha ido de las manos...
ResponderEliminarCon lo fácil que hubiera sido deshabilitar por defecto el plugin del JRE en el navegador, y que sea el usuario quien lo autorice en los sitios que considere de confianza (servidor corporativo de la empresa, etc.).
Porque la mayoría de los grandes clientes están huyendo del los Applets por la fama ganada.