grimch/log4j-cve-2021-44228-workaroundsolución genérica de mitigación para la vulnerabilidad log4j CVE-2021-44228
Este proyecto proporciona una solución alternativa de propósito general para la vulnerabilidad log4j CVE-2021-44228, que se puede usar en caso de que no tengas la alternativa a corto plazo de reconstruir tu proyecto respectivo o parchear los archivos jar de log4j-core.
La idea detrás de esto es bastante simple: Forzamos al cargador de clases a cargar una versión "vacía" de la clase JndiLookup utilizando la opción "-Xbootclasspath/a" del runtime de Java.
Por lo tanto, toda la solución alternativa consiste únicamente en esta única clase "org.apache.logging.log4j.core.lookup.JndiLookup.java" y no tiene otras dependencias.
También hay un pom.xml para mayor comodidad para compilarlo y empaquetarlo como jar mediante Maven, pero también puedes hacer lo mismo simplemente usando tu JDK preferido, usando los comandos "javac" y "jar".
Ten en cuenta que esta versión vacía de la clase "JndiLookup" no puede ser compatible con la implementación original de log4j2, porque esto fallaría en ciertas situaciones de carga de clases.
Al aplicar la solución alternativa verías el siguiente mensaje:
"WARN JNDI lookup class is not available because this JRE does not support JNDI.
JNDI string lookups will not be available, continuing configuration.
Ignoring java.lang.ClassCastException: class org.apache.logging.log4j.core.lookup.JndiLookup"
Log4j2 seguirá funcionando sin problemas, solo que sin usar ninguna búsqueda JNDI - ¡ahí lo tienes - la búsqueda JNDI ha sido desactivada!
Una vez que hayas compilado la clase y creado el archivo jar, simplemente agrega la opción "-Xbootclasspath/a:<ubicación de tu archivo jar de workaround>" al comienzo de tu comando Java y apunta al directorio donde colocaste el archivo jar (por ejemplo, log4j-workaround-1.0-SNAPSHOT.jar). Consulta la sección de prueba de concepto para un ejemplo de cómo hacer esto.
Un comando Java al que aplicarías esta solución alternativa podría lanzar cualquier cosa (Weblogic, Tomcat, fat jar construido por Spring, ...).
Puedes ignorar lo siguiente si solo estás interesado en la solución alternativa, pero no en cómo verificar si realmente funciona.
Para validar el enfoque, he agregado una carpeta "POC", que contiene otro proyecto Maven. No quise usar pruebas unitarias, sino más bien mantenerme cerca de configuraciones de producción, que usan lanzamiento explícito desde la línea de comandos de fat jars o un lanzamiento de contenedor como el de Tomcat con el que lo validé.
La prueba de concepto tiene dos clases, "POC.java" para probar la solución alternativa en la línea de comandos y "POCServlet.java" para probar lo mismo en un servidor de aplicaciones.
Ambos escenarios intentan registrar "${jndi:ldap://localhost/test}", por lo cual log4j intentaría conectarse a ldap en tu host local sin la solución alternativa aplicada y fallaría con conexión rechazada.
Para ejecutar la POC de línea de comandos (una vez que la hayas construido en Maven):
Ve al directorio "target\log4j-workaround-1.0-SNAPSHOT\WEB-INF" y ejecuta (si estás en una línea de comandos de Windows):
java -Xbootclasspath/a:..\..\..\..\target\log4j-workaround-1.0-SNAPSHOT.jar -classpath classes;lib\* com.github.grimch.log4j_workaround.poc.POC
Para ejecutar la POC con Tomcat:
¿Por qué usar "-Xbootclasspath" y no solo poner el jar de la solución alternativa como la primera entrada en el classpath "normal"? Bueno, algunos contenedores permiten influir en la carga de clases de tal manera que los archivos jar en el archivo de la aplicación desplegada tienen preferencia sobre los mismos en el classpath del sistema. Por otro lado, lo que esté en el bootstrap classpath tiene preferencia sobre todo lo demás.
Sin embargo, si estás seguro de que no estás usando nada similar (por ejemplo, "prefer-application-packages" en Weblogic), entonces también puedes optar por la alternativa "-classpath".