soportetecnico

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 pueden 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.

Fuente: http://www.javahispano.org

OpenJDK será la implementación oficial de referencia para Java SE 7

Nos comentan que faltan menos de dos meses para la fecha de lanzamiento de JDK 7 y que la especificación de Java SE 7 (JSR 336) todavía se está puliendo. Oracle es el responsable de entregar la implementación de referencia de Java SE 7 por su rol de conducción en la especificación. En una movida interesante -alineada con su estrategia hacia un ecosistema Java abierto- la referencia estará completamente basada en el código fuente de la OpenJDK y liberada bajo la licencia de software libre GPL.
El rol de la Implementación de Referencia (IR) es ser usada como el estándar dorado para todas las implementaciones Java. Para tener una implementación compatible con Java SE certificada, el implementador debe pasar una gran cantidad de tests de compatibilidad – el Technology Compatibility Kit (TCK). Además de esto, las implementaciones pueden ser comparadas con la IR como un chequeo adicional de compatibilidad. Básicamente, si una implementación ha sido certificada de tener el mismo comportamiento que la IR entonces es compatible con Java. Hay una página para consultar más información sobre este asunto en JCP FAQ.
Históricamente, Sun siempre usó la JDK de Sun como la IR y la lanzó a través de la licencia Binary Code License (BCL). Esto era muy conveniente para Sun ya que significaba que la implementación de su producto era compatible por definición. Sin embargo, también era confuso ya que la JDK de Sun contenía algunas características que no eran parte del estándar, como el Plugin de Java. También, continuando con esta práctica podría dificultar las cosas para quienes implementan Java open source ya que no podrían estudiar o evaluar el código fuente oficial de la IR. (El código fuente de la JDK de Oracle es un poco distinto al de OpenJDK – algo que se abordará más adelante).
Con esto en mente, Oracle:
    -Creará binarios de la IR basados únicamente en la base de código de la OpenJDK.
    -Hacer binarios disponibles bajo la licencia BCL (la licencia normal de Java) para quienes implementen máquinas virtuales comerciales y GPLv2 (con la Classpath exception) para implementaciones open-source.
    -Continuar proveyendo licencias comerciales TCK, pero también actualizar la licencia OCTLApara que cubra Java SE 7. Esto último permite acceso gratis al TCK a los desarrolladores para verificar sus implementaciones.
Oracle cree que estos cambios llevarán a mejorar la claridad en la comunidad Java, así como facilitar las cosas para las implementaciones comerciales y open sources de Java SE.
Aclaran que esto no cambia la política con Apache Harmony. En muchos sitios ya se han hecho eco de que esto es un ataque más de Oracle a esta implementación libre de Java de Apache. El cambio en la licencia OCTLA permitiría el acceso gratuito al TCK para implementaciones GPL derivadas del OpenJDK, por lo que Harmony no está incluida. Y sigue luchando por adquirir una licencia para el TCK.

Fuente: http://picandocodigo.net/