Buscar
Social
Ofertas laborales ES
« La semana pasada en javaHispano | Main | Emitrom anuncia Lienzo 1.0 »
viernes
dic142012

¿Es Java inseguro?

El titulo de esta "nota de opinión" viene a cuento de lo que hablábamos con Abraham en el podcast número 145 sobre una vulnerabilidad que afecta a las versiones 5, 6 y 7 de Java.

Mi comentario sobre este tipo de noticias suele ser que el problema son los browser's, y da igual, si el vector de ataque es un applet, un activex, un flash, una imagen o un streaming de video.

O simplemente, un fragmento de código en JavaScript , tal es el caso de la ultima vulnerabilidad encontrada en Internet Explorer, que afecta a todas sus versiones (desde la 6 a la 10), reportada por la empresa spider.io y publicado en diarioTi, y por medio de la cual es posible capturar el estado del mouse desde un banner publicitario en la solapa del banner, en cualquiera de las otras solapas, mas allá del marco de la ventana del navegador, o incluso con el IE minimizado y el cursor en otra aplicación (ver video).


Estos problemas, tampoco son (y al igual que con java) exclusivos de IE, si no que existen en Chrome, en Firefox, Safari e incluso en Opera

De hecho, el problema de los fallos de seguridad, tampoco se limitan a los browser's, si no que existen en productos tan diversos como motores de base de datos o sistemas operativos (tanto para PC como para moviles).

Y sin que a nadie se le ocurra calificar a estos como inseguros y que por tanto deban dejarse de lado.

En el caso particular de Java, debe tomarse en cuenta el hecho de que casi todas las vulnerabilidades (por no decir todas) se limitan a una modalidad de despliegue (los applet) la cuan no solo tiene los días contados (como el resto de los plugins), sino que nunca fue, es o será soportada por consolas de arquitectura ARM (llámense tablet's o teléfonos)

Por lo que les vuelvo a preguntar.
¿Java es inseguro?

Quizás a la luz de lo expuesto y siempre en pos de la seguridad deberíamos plantearnos utilizar menos aplicaciones web y mas CR o RIA (es decir, más Java)
O por lo menos dentro del ámbito empresarial.

¿Cual es vuestra opinión?

 

 

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (19)

>¿Java es inseguro?

Pues claro, y la prueba está en que lleva dos o tres años siendo el principal vector de ataque contra PCs. ¿sabes qué diferencia a Java de Chrome, Firefox o Internet Explorer? Que estos se actualizan de modo transparente semitransparente por el usuario, y con una periodicidad como mucho mensual (Internet Explorer) o prácticamente diaria en el caso de Chrome, y no una vez cada cuatro meses. Encima, por norma general, los usuarios son conscientes de que tiene que actualizar su navegador web o sistema operativo pero no "el Java", que no saben realmente para qué lo usan, o si lo usan. Simplemente apareció ahí un día porque, por ejemplo, instalaron Minecraft.

diciembre 16, 2012 | Registered CommenterAbraham

Tengo la VM de Java iniciada todo el día, y en absoluto estoy expuesto a ninguna de esas vulnerabilidades.
Dudo mucho que mi NetBeans, al igual que aTunes, JDownloader, Limewire, Vuze y similares, deban preocuparse en lo más mínimo.
Tampoco las aplicaciones empresariales, sean de servidor o de escritorio, están "asustadas" que se diga.

Luego, no es que el lenguaje Java sea inseguro, sino que algún uso particular y minoritario del mismo, léase applets, puede serlo.

diciembre 17, 2012 | Registered Commenterchoces

@choces Luego, no es que el lenguaje Java sea inseguro, sino que algún uso particular y minoritario del mismo, léase applets, puede serlo.

Uso particular y minoritario que, insisto una vez más, en la práctica es el principal vector de ataque contra PCs. No importa cuántos programadores Java desarrollen Applets. Importa que la gente al instalar el JRE instala también el plugin del navegador. Y si tú tienes en tu equipo el plugin del navegador instalado, eres vulnerable a ese tipo de ataques.

diciembre 17, 2012 | Registered CommenterAbraham

"...Importa que la gente al instalar el JRE instala también el plugin del navegador."

Eso no es necesariamente cierto. Yo tengo instalado el JRE y no el plugin del Navegador. Puesto que mi JRE es un 64bits, y Chrome solo acepta JRE de 32bits, simplemente no se instala en el navegador.

Esa "gente" que instala el JRE no son únicamente usuarios domésticos. Por lo tanto no se puede juzgar la seguridad de un lenguaje, en términos absolutos, por los potenciales problemas de los applets ejecutándose en el ordenador "de casa".

Se puede afirmar que "Los applets de Java en un navegador pueden ser inseguros"; pero no que "Java es inseguro".

Por cierto, se acaban de publicar nuevas versiones de JavaSE, tanto para la versión 1.6 como para la 1.7, que resuelven varios de esos problemas de seguridad, entre otros, y no parece que sea noticia.

diciembre 17, 2012 | Registered Commenterchoces

La gente de la calle no va a hacer diferencias entre "Applets" y todo lo demás. Para ellos es Java y punto. Y ellos, no van a andar instalando JREs de 64 bits, ni desactivando el plugin. Además hay muchos expertos de seguridad que recomiendan que "a no ser que estes seguro que lo necesitas, desistala Java". Y lo hacen con razón. Esta situación, como ya he dicho montón de veces, es crítica si uno cree que JavaFX realmente es el futuro del escritorio y quiere ser un competidor a soluciones como flash.

diciembre 17, 2012 | Registered CommenterAbraham

Java ha sido desde siempre un producto gratuito. La "gente de la calle", que jamás ha pagado un céntimo por usar el JRE, no ha contribuido, ni mucho ni poco, ni a la gestación de Java como lenguaje, ni a definir sus especificaciones, ni a implementarlas, ni a nada.

Pretender a estas alturas que el uso que haga la "gente de la calle", defina lo que es seguro o inseguro para todo el lenguaje, es una visión muy estrecha.

Java es lo que es gracias a su uso empresarial, que es quien paga las facturas de su desarrollo, directa o indirectamente. Y su uso empresarial no es el principal vector de ataque, mediante applets.

JavaFX es el sustituto de Swing, es el User Interface del lenguaje Java, no otro "aditivo" para navegadores de Internet.

diciembre 17, 2012 | Registered Commenterchoces

¿Java? ¿Cuál Java? El plugin de Java para los navegadores ES INSEGURO y RECOMIENDO firmemente desinstalarlo. Y la culpa es 100% de Oracle y su mal manejo del mismo, no de los browsers. De hecho, todos los browsers serios (Firefox, Chrome) continuamente están poniendo en lista negra (bloqueando) al plugin de Java, porque Oracle no soluciona las serias vulnerabilidades de seguridad de su maldito plugin en tiempo y forma. ¿Conocen la diferencia entre un plugin, una plataforma, un entorno de servidor, un entorno móvil, y un entorno de escritorio? ¿Aún confunden Java el lenguaje, Java la plataforma, las applets, el J2ME, y el JavaScript? $DEIDAD nos libre.

Y aún así si el plugin para navegadores de Java fuera seguro (que no lo es), no recomiendo usarlo en absoluto. Es lento, no es abierto, no es estándar, y tiene y sufre de todas las limitaciones y problemas de otros plugins para navegadores, como el de Flash, el de Acrobat, y del Media Player. El camino en la web es HTML5 y sus estándares asociados. Los plugins son el pasado, la web cambió, ya ni siquiera se accede a la web exclusivamente desde una PC, por el contrario, hoy es más común usar la web desde dispositivos móviles y de consumo, donde hay otros navegadores y no existe el soporte de plugins. RIP Java Plugin. Bienvenido HTML5.

diciembre 17, 2012 | Unregistered Commentergorlok

Entre tanto enlace en el cuerpo de la noticia, me olvidé los dos más importantes.

JavaHispano Podcast - 145 - Noticias octubre de 2012
Otra vulnerabilidad en Java, y esta vez afecta a Java 5, 6 y 7

Abraham,
Tal como comentábamos en el podcast, todos los bug de seguridad (por lo menos, los que yo recuerdo) siempre se relacionan con java en los browser's, (el plugin).
Plugin que, por otra parte (y al igual que el de flash y el de activex), tienen los días contados, ya sea por decisión de los fabricantes de los navegadores, por la mala prensa obtenida (y nadie está diciendo que esta haya sido injustificada), por políticas de sistemas (como es el caso en algunas empresas). O en el caso especifico de Java por su falta de presencia en Android, iPhone, iPad, Windows RT y demás plataformas pertenecientes a la última generación de dispositivos.

Por lo que (y 100% de acuerdo con choces) deberíamos decir "Los applets de Java en un navegador pueden ser inseguros" y no que "Java es inseguro".

Navegadores que (por otro lado) tienen fallas de seguridad mas allá de los applets (como se muestra en los enlaces de Chrome, Firefox, Safari y en el video de IE).

En cuanto a esto de que java es la principal causa de infecciones de PC's y que el problema se soluciona con actualizaciones automáticas de siclos cortos, al estilo de Chrome.....

No coincidimos, en especial por dos motivos.

Para empezar esto es en Windows. En Ubuntu las actualizaciones del OpenJDK se bajan desde el gestor de actualizaciones de manera automática y sin ser discriminadas del resto de las actualizaciones del OS o de cualquier otra de las aplicaciones de los repositorios (LibreOffice, MySQL, Firefox, Flash Player, etc.).
Microsoft tiene la misma política, pero acotada a los productos propios (.Net, Microsoft Office, Media Player, Internet Explorer y demás ) dejando al resto de los fabricantes de software a la buena de dios. Por lo que si tanto le molestan los fallos de seguridad de terceros, deberían ofrecerles a estos un soporte como el que les ofrece Canonical a los de su OS, o el que guardan para ellos mismos.

Por otra parte, un siclo corto de actualizaciones (casi diario como es el caso de Crome) no es garantía de que resuelvas los problemas de manera inmediata. De hecho puede generar más problemas de los que resuelva, como es justamente el caso de Crome, el navegador con mas boletines de seguridad de los 5 más utilizados. Aunque siendo justos con Crome, la mayoría de estos son heredados directamente de WebKit.

diciembre 17, 2012 | Registered Commenterefrigerio

@gorlok

En casi todas las actualizaciones de JavaSE se resuelven problemas de seguridad.

"Java SE 7u10
This releases brings in key security features and bug fixes. Oracle strongly recommends that all Java SE 7 users upgrade to this release. "

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Lo mismo se aconseja para las actualizaciones de JavaSE 1.6.38

diciembre 17, 2012 | Registered Commenterchoces

Los Mac de Apple han conseguido una cuota de mercado significativa, Windows sigue siendo el rey, pero un rey más débil, si mañana tuvieras que hacer una aplicación nativa cross-platform ¿con qué lo harías? podría ser C++ con algún toolkit multiplataforma, Java se inventó precisamente como alternativa a ese enfoque, el WORA, lo del web vino después.

Doy la razón a Abraham, lo LAMENTABLE es que cualquiera que haga hoy una aplicación Java de escritorio (Swing, SWT, JavaFX) DEBE de incluir una JVM en la distribución de la aplicación en buena parte por lo que estamos hablando aquí, es decir debe dejar de suponer que hay una JVM instalada.

La administración pública de España por cierto usa applets de Java para temas críticos (firma electrónica, generación de informes etc).

diciembre 17, 2012 | Registered Commenterjmarranz

@jmarranz,

El arrastrar el JRE como parte del instalador o el crear uno propio a la medida de la aplicación con Excelsior JET, son opciones de toda la vida para aplicaciones GUI.

Y tan validas como utilizar JWS (aclarando en la página de descarga que solo se necesita el JRE y no el plugin para los navegadores).

No obstante, insisto,
Problemas de seguridad existen en todos los softwares (en especial en los browser's), y a nadie se le ocurre calificar a estos como inseguros y que por tanto deban dejarse de lado.

diciembre 17, 2012 | Registered Commenterefrigerio

@choces curiosa política tienes con respecto a los usuarios finales: básicamente que les den por saco. Los usuarios finales son el objetivo de las aplicaciones JavaFX, que pretende ser una especie de Adobe AIR. Así que Oracle no los deja de lado, al menos de palabra. Por otro lado, teniendo cuenta que "por nuestra culpa", incluyendo aquí a Oracle, Sun y toda la comunidad Java, cientos de millones de personas del planeta tienen instalada una máquina virtual en su equipo que les hace vulnerables porque esta desactualizada. Ahora no podemos decirles simplemente "que os jodan a todos; no nos importa lo que os pase porque ahora sólo usamos Java para aplicaciones web". Debemos, Oracle debe, no dejarles tirados. No es justo para ellos.

@efrigerio Chrome es, con diferencia, el navegador más seguro. Buena prueba es un buen rendimiento en las competiciones Pwn2Own. Dos claves para ello: las actualizaciones casi diarias, y el programa de Google de pagar recompensas elevadas a quien descubre una vulnerabilidad. Lo primero, limita considerablemente la ventana de oportunidad para infectar equipos en base a vulnerabilidades de Chrome. En unos pocos días, la inmensa mayoría de los navegadores se van a actualizar, por lo que una vulnerabilidad en este navegador sólo tiene una vida de unos pocos días. No merece mucho la pena romperse la cabeza buscandolas cuando se van a explotar durante tan poco tiempo. Y si encuentras una, sobre todo teniendo en cuenta el poco tiempo de vida que va a tener, al hacker le sale mucho más rentable desde el punto de vista económico venderse la Google que a la mafia Rusia o explotarla el mismo. Ésas son las dos claves de la seguridad en Chrome. Ésas son las formas de hacer las cosas.

¿Y que hace Oracle con Java?. Actualizaciones cada varios meses, por lo que tenemos ventana de oportunidad para infección de meses, y no sólo no paga a quien descubrió vulnerabilidades, sino que además a menudo ignora a esta gente. Estos son dos problemas gordos que tenemos y que se pueden resolver. El tercero, mucho más jodido, son los cientos de millones de personas que ya tienen un JRE antiguo instalado en su equipo y no lo actualizan porque no saben para qué le sirve. El problema es que esa gente no se va a aportar a un futuro hipotético JRE que se actualice a diario a lo Chrome.

diciembre 17, 2012 | Registered CommenterAbraham

@jmarranz

Cualquiera que haga hoy en día una aplicación en Java, debe plantear unos requisitos mínimos de VM instalada, al margen de cuestiones de seguridad, porque no creo que nadie desarrolle aplicaciones para que se ejecuten hasta en JavaSE 1.0

Eso mismo sucede con .NET sin ir más lejos. ¿Nunca te ha sucedido que te pones a instalar una aplicación en Windows, y te dice: "No tiene usted instalado .NET v2.0"?, que es cuando se te queda cara de tonto, cuando sabes que sí tienes instalado .NET v.4.0

diciembre 17, 2012 | Registered Commenterchoces

@Abraham

Mi "política" respecto de los usuarios finales no es la que dices, sino otra muy diferente: que se actualicen, que es gratis. Y si no lo hacen, aún siendo gratis, entonces que se aguanten. ¡Es así de simple!. Porque información sobre lo que es Java tienen de sobra, si quieren buscarla.

Te recuerdo que la versión anterior JavaSE 1.7.9 se adelantó sobre la fecha prevista, precisamente porque había una vulnerabilidad que ya estaba afectando a los sistemas.

diciembre 17, 2012 | Registered Commenterchoces

Nota aparte,
El tema de Crome y las alertas de seguridad que yo manejo, salen de esta página.
http://www.icic.gob.ar/

..........

Resumamos un poco.

Algo en lo que todos parecería, estamos de acuerdo es que los applet´s (y por extensión el plugin para los browser's), no son recomendables, no tienen futuro, y más vale huir de ellos.

También parecería haber coincidencia en que de no contar con soporte para los tablet / teléfonos (y por extensión de funcionalidades como Multi-touch, geolocation, y demás) dentro del JSE, el futuro de java en GUI no se ve muy brillante que digamos.
Y curiosamente, no he escuchado a Oracle ni a nadie del JSP o del OpenJDK, dar una buena señal al respecto.

Pero de ahí a decir que "Es Java inseguro" cuando todos los bug de seguridad no afectan a las aplicaciones swing / swt de toda la vida. Hay un trecho bastante grande.

Y esto es independiente de si estas aplicaciones se basan en JWS, arrastran un JRE con el instalador (algo que es bastante común), o crean un ejecutable "nativo" para cada plataforma con Excelsior JET o con el "empaquetamiento nativo" de JavaFX 2.2

Otra aclaración,
Lo de "Es Java inseguro" no va contra Abraham, ya que es algo que he leído y escuchado infinidad de veces en desenas de portales (al igual que esto de meter a los applet´s y al desktop en la misma bolsa). Y por lo cual, me pareció interesante ofrecer otra mirada.

diciembre 17, 2012 | Registered Commenterefrigerio

Eduardo, las alertas de seguridad no importan. Importa la gente que se infecta con él.

Ando liado y no tengo tiempo para seguir discutiendo…pero visto lo visto creo que vamos a grabar un podcast sobre "seguridad en Java". ¿Quién se apunta? Aunque tendrá que ser ya el año que viene jejeje

diciembre 17, 2012 | Registered CommenterAbraham

@efrigerio

Sé que vas a enseñarme esa hacha afilada que guardas bajo la mesa... pero me arriesgaré :P

http://docs.oracle.com/javafx/2/events/gestures.htm#CHDDHFJJ
http://fxexperience.com/2012/10/building-the-javaone-kiosks-park-1/

diciembre 17, 2012 | Registered Commenterchoces

Iupi!!!
Algo mas para leer.
:o)

Pregunta.
¿Funciona en Android, en iPhone, en iPad, en Surface RT?

XD

De todos modos, lo que buscaba, estaba más en desmitificar esto de que "Java es inseguro" solo porque "los applets son inseguros"

En cuanto al hacha, ya sabes,
Sigo esperando a que alguien de Oracle ponga la cabeza.

:(

Pero (y no sé porque se me ocurre), ese día, habrá varias manos en alto.

diciembre 17, 2012 | Registered Commenterefrigerio

PD:

De la propuesta de Abraham
¿Alguien se apunta?

Un Saludo,

diciembre 17, 2012 | 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>