Buscar
Social
Ofertas laborales ES
« La última semana en javaHispano | Main | Oracle WebLogic 12c »
lunes
dic052011

Java sigue siendo el líder en vulnerabilidades

Java continúa liderando el ranking de vectores de ataque contra PCs Windows (y teniendo en cuenta que este sistema operativo es el usado por más de 90% de los equipos, probablemente lidera el ranking global de vectores de ataque contra ordenadores en general).

La semana pasada Microsoft hizo público su "Microsoft Security Intelligence Report". El informe analiza la segunda mitad de 2010 en la primera mitad de 2011, haciendo un énfasis especial en los dos primeros trimestres de 2011. Uno de los resultados que presenta es que Java sigue siendo el principal vector de ataque, seguido en esta ocasión por ataques debidos a vulnerabilidades del propio sistema operativo (que especialmente en el segundo trimestre de 2011 han crecido considerablemente).

En esta gráfica podéis ver el número de exploits que han empleado un determinado mecanismo para infectar un equipo. Donde pone "Documents Readers" se refiere fundamentalmente a Adobe Acrobat y Reader (la línea representa algunos otros lectores de documentos más, pero su contribución es despreciable frente a los de Adobe).

Aunque voy a parecer un disco rayado porque recientemente hemos hablado de este tema, así como en el año pasado, lo diré una vez más: el motivo de esta patética situación de Java es que la inmensa mayoría de la gente no es consciente de que tiene un JRE instalado, no sabe lo que es ni para qué vale. Y cuando se quiere actualizar a menudo lo ignora porque ya está cansada de actualizar cosas y "esa cosa no sabe para qué es ni (crea él) la usa para nada".

La única solución para esta situación es habilitar por defecto actualizaciones automáticas para el JRE, actualizaciones que se podrían deshabilitar si se desea. El comportamiento de los usuarios no va a haber forma de cambiarlo. Y sin actualizar el JRE es imposible hacerlo seguro, ya que en cualquier software se siguen encontrando vulnerabilidades de modo continuo.

Por poner un pequeño ejemplo, en el último par de semanas un nuevo ataque contra Java está siendo explotado bastante activamente por la comunidad de hackers. Este ataque sólo está parchado en Java 6 Update 29 o en Java 7 Update 1. ¿Cuántos de vosotros tenéis actualizados a la última Java en vuestro equipo y por tanto no sois vulnerables ante este ataque?. Yo no tengo mi equipo actualizado. Y apostaría que bastantes pocos de vosotros lo tenéis…

Aquí tenéis el Microsoft Security Intelligence Report al completo. Tiene una sección dedicada a Java.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (5)

En mi caso estoy tranquilo, porque estoy usando la versión 1.7.04 ;)
Las actualizaciones automáticas, a pesar de que parecen la solución más eficaz, tienen sus problemas.
Hasta la fecha, las actualizaciones de Java se añaden a las existentes, no las reemplazan. Es bastante habitual ver múltiples versiones de Java instaladas en el mismo equipo, porque no se ha desinstalado ninguna, antes de proceder a la actualización de la nueva.
Aunque mantener diversas versiones tiene su utilidad para desarrolladores, es evidente que para usuarios finales puede ser desde un lío a un desastre.

Creo que la solución más eficaz podría ser:
1.- Desarrolladores: versiones independientes de usuarios finales, con actualizaciones manuales.
2.- Usuarios: versiones con actualizaciones automáticas, que eliminen o desinstalen las anteriores existentes, y con opción a bloquear la actualización.

No me parece lógico que los JRE que se usan para desarrollo, se instalen con las mismas características de gestión que las de usuarios finales.

diciembre 5, 2011 | Registered Commenterchoces

Totalmente de acuerdo. Desarrollo es un tema diferente de los usuarios finales. Lo mismo que aplicaciones empresariales en producción. A fin de cuentas, la inmensa mayoría de estas vulnerabilidades se basan en lanzar un Applet no firmado que no requiere ninguna confirmación por parte del usuario y después hacer una excavación de permisos. Y eso no en principio no es una amenaza para un servidor. Las actualizaciones automáticas tienen que poderse desactivar de un modo sencillo, y eso será lo que se haga en la inmensa mayoría de las aplicaciones empresariales. Pero para los usuarios finales actualizaciones automáticas trasparentes sin mantener versiones anteriores son lo más adecuado.

diciembre 5, 2011 | Registered CommenterAbraham

¿Pero existe algun indicio de que Oracle tenga planeado que las actualizaciones son automaticas?, ¿O tendremos que empezar a sugerirle ?

diciembre 6, 2011 | Registered Commenterivmx

Al menos, para JavaSE 1.7 no creo que haya nada planeado en ese sentido.
Podría plantearse un Request for Enhancement, haciendo la petición. Voy a comprobar cómo se puede hacer la proposición para 1.7
Como JavaSE 1.8 está iniciando su desarrollo, tal vez sea más fácil. Intentaré llevar la cuestión al grupo de proyecto que realiza el deployment, que ahora mismo no sé cuál es, pero lo averiguaré.

diciembre 6, 2011 | Registered Commenterchoces

Pues yo también voy a sonar a disco rayado.

En Ubuntu las actualizaciones del JER se bajan como parte de las del sistema operativo, al igual que las del flash player, firefox, y la mayoría del software instalado.

Microsoft hace exactamente lo mismo con los paquetes de .NET, su navegador y las DLL de su office suite. Por lo que si tanto le preocupa java debería hacer lo mismo que Ubuntu.

Otra cosa, y como bien habéis apuntado el vector de entrada son los applet, por lo que una solución alternativa pasaría por deshabilitar los applet y demás plugin´s por política, algo que algunos de nosotros hemos empezado a establecer. Y que de todas formas terminara ocurriendo de mediano a largo plazo de manera factica en los navegadores.

Un saludo,

diciembre 7, 2011 | Registered Commenterefrigerio

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>