Sigue la incertidumbre tras el parche de Java.
Aún no se ha asentado el polvo que levantó el último 0-day en Java y su posterior parche, cuando desde varios frentes ya se están dando detalles de nuevos problemas y vulnerabilidades. Incluso ha sido probado que esta última actualización no soluciona correctamente el fallo. Tres problemáticos "titulares" para Oracle después de la rápida respuesta al último incidente y sus medidas contra los applets no firmados.
Nuevo exploit de Java se vende por 5.000 dolares
Por un lado, Brian Krebs anunciaba en su blog, solo un día después de la publicación del parche, que en un foro privado ya se estaba vendiendo un exploit para una vulnerabilidad desconocida de Java. Según Krebs, el conocido administrador del foro ofrecía a un segundo comprador (ya había sido vendido un vez) una copia del exploit. Este se ofrecía tanto en código fuente como listo para ser usado. El precio era de 5.000 dólares. Se aseguraba que el exploit era funcional con la última versión de Java publicada el día anterior y que además era exclusivo, ya que no se encontraba en ningún kit de exploits.
Poco después, según Krebs, el mensaje fue eliminado. Tampoco existen pruebas de concepto conocidas para este supuesto exploit, así que hay que tomar la noticia con cautela.
Confirmado: Java solo ha solucionado uno de los bugs
Tal y como ha sido analizado por varios investigadores, y según define la vulnerabilidad el NIST (CVE-2013-0422), el exploit de Java que se encontró utilizaba dos fallos de diseño para ejecutarse. En primer lugar, hace uso del método público getMbeanInstantiator para obtener una referencia a objetos MbeanInstantiator privados. Después, a través del método findClass, acceder a clases en teoría restringidas.
Posteriormente, utilizaba la API de Reflection de forma recursiva para aprovechar un fallo en la limpieza en la pila de llamadas (como ha sido analizado recientemente) y poder crear las instancias de las clases obtenidas en el paso anterior.
Tras la publicación del parche, el equipo de Immunity realizó un análisis del código corregido, y ha comprobado que el primero de los pasos todavía puede llevarse a cabo. Oracle solo ha bloqueado el sistema para eludir las restricciones de Java, dejando el problema de carga de clases restringidas en el código. En el post publican una prueba de concepto que permite cargar, a través del proceso descrito, clases restringidas arbitrarias en la última versión de Java.
Este fallo no es explotable de por sí, pero combinado con otra vulnerabilidad que permitiera eludir las restricciones de Java significaría que podría seguir explotándose como hasta ahora.
Además aclaran por qué, al contrario que se afirmaba al principio, el fallo no puede explotarse en la versión 6 de Java.
Java 7 Update 11 es vulnerable
Y lo dice Adam Gowniak, el CEO de Security Explorations, que ha descubierto 49 vulnerabilidades en Java durante 2012. En un mensaje a la lista de correo Full Disclosure, asegura que se han encontrado dos nuevas vulnerabilidades que permiten el salto de la sandbox en la última versión de Java. Identificadas como fallos 51 y 52, ya han sido reportadas a Oracle junto con pruebas de concepto funcionales, y están siendo investigadas por la compañía.
Aunque no ha dado detalles técnicos, asegura que no están relacionadas con el fallo en MbeanInstantiator descrito arriba, pero sí "inspiradas" en el.
Más información:
New Java Exploit Fetches $5,000 Per Buyerhttp://krebsonsecurity.com/
Confirmed: Java only fixed one of the two bugs.http://immunityproducts.
CVE-2013-0422 – aka: Java 2013 0day 1 – and inofficial patchhttp://schierlm.users.
[SE-2012-01] Java 7 Update 11 confirmed to be vulnerablehttp://seclists.org/
Vulnerability Note VU#625617http://www.kb.cert.org/vuls/
Aún no se ha asentado el polvo que levantó el último 0-day en Java y su posterior parche, cuando desde varios frentes ya se están dando detalles de nuevos problemas y vulnerabilidades. Incluso ha sido probado que esta última actualización no soluciona correctamente el fallo. Tres problemáticos "titulares" para Oracle después de la rápida respuesta al último incidente y sus medidas contra los applets no firmados.
Nuevo exploit de Java se vende por 5.000 dolares
Por un lado, Brian Krebs anunciaba en su blog, solo un día después de la publicación del parche, que en un foro privado ya se estaba vendiendo un exploit para una vulnerabilidad desconocida de Java. Según Krebs, el conocido administrador del foro ofrecía a un segundo comprador (ya había sido vendido un vez) una copia del exploit. Este se ofrecía tanto en código fuente como listo para ser usado. El precio era de 5.000 dólares. Se aseguraba que el exploit era funcional con la última versión de Java publicada el día anterior y que además era exclusivo, ya que no se encontraba en ningún kit de exploits.
Poco después, según Krebs, el mensaje fue eliminado. Tampoco existen pruebas de concepto conocidas para este supuesto exploit, así que hay que tomar la noticia con cautela.
Confirmado: Java solo ha solucionado uno de los bugs
Tal y como ha sido analizado por varios investigadores, y según define la vulnerabilidad el NIST (CVE-2013-0422), el exploit de Java que se encontró utilizaba dos fallos de diseño para ejecutarse. En primer lugar, hace uso del método público getMbeanInstantiator para obtener una referencia a objetos MbeanInstantiator privados. Después, a través del método findClass, acceder a clases en teoría restringidas.
Posteriormente, utilizaba la API de Reflection de forma recursiva para aprovechar un fallo en la limpieza en la pila de llamadas (como ha sido analizado recientemente) y poder crear las instancias de las clases obtenidas en el paso anterior.
Tras la publicación del parche, el equipo de Immunity realizó un análisis del código corregido, y ha comprobado que el primero de los pasos todavía puede llevarse a cabo. Oracle solo ha bloqueado el sistema para eludir las restricciones de Java, dejando el problema de carga de clases restringidas en el código. En el post publican una prueba de concepto que permite cargar, a través del proceso descrito, clases restringidas arbitrarias en la última versión de Java.
Este fallo no es explotable de por sí, pero combinado con otra vulnerabilidad que permitiera eludir las restricciones de Java significaría que podría seguir explotándose como hasta ahora.
Además aclaran por qué, al contrario que se afirmaba al principio, el fallo no puede explotarse en la versión 6 de Java.
Java 7 Update 11 es vulnerable
Y lo dice Adam Gowniak, el CEO de Security Explorations, que ha descubierto 49 vulnerabilidades en Java durante 2012. En un mensaje a la lista de correo Full Disclosure, asegura que se han encontrado dos nuevas vulnerabilidades que permiten el salto de la sandbox en la última versión de Java. Identificadas como fallos 51 y 52, ya han sido reportadas a Oracle junto con pruebas de concepto funcionales, y están siendo investigadas por la compañía.
Aunque no ha dado detalles técnicos, asegura que no están relacionadas con el fallo en MbeanInstantiator descrito arriba, pero sí "inspiradas" en el.
Más información:
New Java Exploit Fetches $5,000 Per Buyerhttp://krebsonsecurity.com/
Confirmed: Java only fixed one of the two bugs.http://immunityproducts.
CVE-2013-0422 – aka: Java 2013 0day 1 – and inofficial patchhttp://schierlm.users.
[SE-2012-01] Java 7 Update 11 confirmed to be vulnerablehttp://seclists.org/
Vulnerability Note VU#625617http://www.kb.cert.org/vuls/
No hay comentarios:
Publicar un comentario