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 dolares. 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 Buyer
Confirmed: Java only fixed one of the two bugs.
CVE-2013-0422 – aka: Java 2013 0day 1 – and
inofficial patch
[SE-2012-01] Java 7 Update 11 confirmed to be
vulnerable
Vulnerability Note VU#625617
Francisco López
