¿Cómo puedo volcar en Java (IBM Java) los valores predeterminados para verificar el valor predeterminado de lo siguiente?
"com.sun.jndi.rmi.object.trustURLCodebase" "com.sun.jndi.cosnaming.object.trustURLCodebase"Algo como esto, pero para los parámetros anteriores:
java -XX:+PrintFlagsFinal -versionEsto es para una revisión de mitigación CVE-2021-44228 .
Idealmente, esto se puede verificar en cmd y no es necesario ejecutar el código de prueba.
Aquí está mi intento de código de prueba que no se muestra (muestra Nulo):
import java.util.Properties; class TiloDisplay { public static void main(String[] args) { Properties prop = System.getProperties(); printProperties(prop); } public static void printProperties(Properties prop) { prop.stringPropertyNames().stream() .map(key -> key + ": " + prop.getProperty(key)) .forEach(System.out::println); System.out.println("CVE check part ========================================== " ); System.out.println("CVE check for:: com.sun.jndi.ldap.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.ldap.object.trustURLCodebase")); System.out.println("CVE check for:: com.sun.jndi.rmi.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.rmi.object.trustURLCodebase")); System.out.println("CVE check for:: com.sun.jndi.cosnaming.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.cosnaming.object.trustURLCodebase")); System.out.println("Cross Check: " + prop.getProperty("java.version")); } }Compilar y ejecutar:
javac DisplayApp.java -source 1.8 -target 1.8 java TiloDisplayCVE-2021-44228 crea una gran superficie de ataque dependiendo de la imaginación del atacante y un RCE es solo uno de ellos.
Le recomiendo encarecidamente que evite tener una conclusión falsa confiando en una característica de JVM dirigida a un determinado vector de ataque; hay más vectores. Simplemente cambie log4j-core a 2.15.0 o configure la propiedad del sistema log4j2.formatMsgNoLookups=true .
Respondiendo a la letra de la pregunta :
No parece que las propiedades del sistema en cuestión tengan ningún valor por defecto. Si lo hicieran, podría consultar con:
java -XshowSettings:properties -version Tenga en cuenta que las banderas -X no son estándar, aunque IBM Java es compatible con esta (verificado Semeru 11).
En cuanto al contexto :
Las implementaciones (al menos en OpenJDK ) consultan los valores de las propiedades, y el valor predeterminado es false si las propiedades no están configuradas, por ejemplo,
// System property to control whether classes may be loaded from an // arbitrary URL code base String trust = getPrivilegedProperty( "com.sun.jndi.ldap.object.trustURLCodebase", "false"); trustURLCodebase = "true".equalsIgnoreCase(trust); Por lo tanto, ni -XshowSettings ni la verificación programática en la pregunta son útiles para saber con certeza cuál es el comportamiento predeterminado de su JVM para estas funciones, o si la versión de JVM que está ejecutando usa estas propiedades si las configura explícitamente.
Estoy de acuerdo con el punto de Volkan , pero también me gustaría verificar que estas funciones JNDI (peligrosas) estén deshabilitadas independientemente del exploit Log4j. Desafortunadamente, necesitamos otra forma de hacerlo, idealmente una implementación independiente.
Supongo que desactivar esta función evitará la ejecución remota de código (RCE) usando JNDI , no solo el que usa Log4j 2:
log4j2.formatMsgNoLookups -> set to true "com.sun.jndi.rmi.object.trustURLCodebase" -> set to false "com.sun.jndi.cosnaming.object.trustURLCodebase" -> set to falseActualice Log4J2 a 2.17.1 y actualice Java a una versión superior a Java 8u121.
El comando
jps -lvmgenerará sus procesos Java en ejecución con sus parámetros.
Consulte también esta respuesta a Obtener los parámetros de una JVM en ejecución .
La actualización a Log4j 2.15.x no es suficiente. Hay otro exploit (consulte Segunda vulnerabilidad de Log4j descubierta, parche ya lanzado ) y ya se ha publicado una nueva versión Log4j 2.16, deshabilitar la configuración JNDI predeterminada ( Descargar Apache Log4j 2 ) y actualizar a la versión 2.16 es más importante ahora.
Pero hay muchos clones de Log4j, código personalizado que usa las mismas clases de Log4j y es por eso que es importante verificar la configuración de JVM, especialmente para versiones anteriores de JDK como antes de 6u211, 7u201 y 8u191 y deshabilitar la configuración de JNDI + RMI . Se presentó más sobre esto en Black Hat en 2016. Consulte Un viaje desde la manipulación JNDI/LDAP hasta la tierra de ensueño de la ejecución remota de código .