grimch/log4j-cve-2021-44228-workaroundSolution de contournement à usage général pour la vulnérabilité log4j CVE-2021-44228
Ce projet propose une solution de contournement générique pour la vulnérabilité log4j CVE-2021-44228, qui peut être utilisée si vous n'avez pas d'alternative à court terme pour reconstruire votre projet respectif ou pour patcher les jars log4j-core.
L'idée derrière cela est assez simple : nous forçons le chargeur de classes à charger une version "vide" de la classe JndiLookup en utilisant l'option java runtime "-Xbootclasspath/a".
Par conséquent, l'ensemble de la solution de contournement ne consiste qu'en cette seule classe "org.apache.logging.log4j.core.lookup.JndiLookup.java" et n'a aucune autre dépendance.
Il y a aussi un pom.xml pour faciliter la compilation et la mise en jar via Maven, mais vous pouvez également faire la même chose simplement en utilisant votre JDK préféré, avec les commandes "javac" et "jar".
Notez que cette version vide de la classe "JndiLookup" ne peut pas être compatible avec l'implémentation originale de log4j2, car cela échouerait dans certaines situations de chargement de classes.
Lors de l'application de la solution de contournement, vous verrez le message suivant :
"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 continuera de fonctionner sans problème néanmoins, simplement sans utiliser de recherche JNDI - voilà - la recherche JNDI a été désactivée !
Une fois que vous avez compilé la classe et créé le fichier jar, ajoutez simplement l'option "-Xbootclasspath/a:" au début de votre commande Java et pointez vers le répertoire où vous avez placé le fichier jar (par exemple log4j-workaround-1.0-SNAPSHOT.jar). Voir la section de preuve de concept pour un exemple de la façon de faire cela.
Une commande Java à laquelle vous appliqueriez cette solution de contournement pourrait lancer n'importe quoi (Weblogic, Tomcat, fat jar construit par Spring, ...).
Vous pouvez ignorer ce qui suit si vous êtes simplement intéressé par la solution de contournement, mais pas par la vérification qu'elle fonctionne vraiment.
Pour valider l'approche, j'ai ajouté un dossier "POC", qui contient un autre projet Maven. Je n'ai pas voulu utiliser de tests unitaires, mais plutôt rester proche des configurations de production, qui utilisent un lancement explicite en ligne de commande de fat jars ou un lancement de conteneur comme celui de Tomcat avec lequel je l'ai validé.
La preuve de concept a deux classes, "POC.java" pour tester la solution de contournement en ligne de commande et "POCServlet.java" pour tester la même chose dans un serveur d'applications.
Les deux scénarios tentent de journaliser "${jndi:ldap://localhost/test}", à cause de quoi log4j essaierait de se connecter à ldap sur votre hôte local sans la solution de contournement appliquée et échouerait avec connexion refusée.
Pour exécuter la POC en ligne de commande (une fois que vous l'avez construite dans Maven) :
Allez dans le répertoire "target\log4j-workaround-1.0-SNAPSHOT\WEB-INF" et exécutez (si vous êtes sur une ligne de commande Windows) :
java -Xbootclasspath/a:..\..\..\..\target\log4j-workaround-1.0-SNAPSHOT.jar -classpath classes;lib\* com.github.grimch.log4j_workaround.poc.POC
Pour exécuter la POC avec Tomcat :
Pourquoi utiliser "-Xbootclasspath" du tout et ne pas simplement placer le jar de contournement comme première entrée dans le classpath "normal" ? Eh bien - certains conteneurs vous permettent d'influencer le chargement de classes de telle sorte que les fichiers jar dans l'archive de l'application déployée aient la priorité sur ceux du classpath système. Ce qui est dans le bootstrap classpath en revanche a la priorité sur tout le reste.
Si vous êtes sûr cependant de ne rien utiliser de tel (par exemple "prefer-application-packages" dans Weblogic") alors vous pouvez également opter pour l'alternative "-classpath".