CVE-2021-44228 (Log4Shell) : vérifier et corriger

Ce qui est concerné

Seul log4j-core de Log4j 2 est concerné, et seulement de 2.0-beta9 jusqu'au correctif. Log4j 1.x n'est pas concerné par cette CVE, mais il est en fin de vie depuis 2015 et a ses propres failles. Les applications Java construites sur Log4j 2 (serveurs d'applications, moteurs de recherche, applications maison) embarquent la bibliothèque dans leurs propres dossiers, souvent dans un .war ou un .jar autonome, pas comme paquet système.

Le premier correctif, 2.15.0, était incomplet dans certaines configurations (CVE-2021-45046), et deux autres problèmes ont suivi (CVE-2021-45105 et CVE-2021-44832). C'est pourquoi la cible aujourd'hui est 2.17.1 ou ultérieur sur Java 8, 2.12.4 sur Java 7 et 2.3.2 sur Java 6.

Vérifier si un serveur l'a

Cherchez les fichiers log4j-core, puis les archives qui l'embarquent. La version figure dans le nom du fichier :

sudo nice -n 19 ionice -c3 find / -xdev -type f -name 'log4j-core-*.jar' 2>/dev/null

sudo nice -n 19 ionice -c3 find / -xdev -type f \( -name '*.jar' -o -name '*.war' -o -name '*.ear' \) 2>/dev/null \
  | while read -r f; do
      unzip -l "$f" 2>/dev/null \
        | grep -qE 'log4j/core/lookup/JndiLookup\.class|log4j-core-[0-9][^/]*\.jar' && echo "$f"
    done

Pour une application que vous construisez vous-même, demandez à l'outil de build quelle version il embarque réellement :

mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

Pour voir si quelqu'un a essayé, cherchez les lookups dans les journaux d'accès du serveur web (les attaquants en mettent aussi dans les en-têtes, que ces journaux n'enregistrent pas) :

sudo grep -rhiE '\$\{jndi|%24%7Bjndi|\$\{\$\{' --include='*access*' --exclude='*.gz' /var/log/apache2 /var/log/httpd 2>/dev/null | tail -20

Corriger

1. Logiciel d'un éditeur : installez la version de l'éditeur qui embarque Log4j 2.17.1 ou ultérieur.
2. Votre propre application : passez log4j-core (et log4j-api) à 2.17.1 ou ultérieur, ou 2.12.4 sur Java 7, 2.3.2 sur Java 6, reconstruisez et redéployez. Vérifiez avec l'outil de build qu'aucune autre dépendance ne ramène une copie plus ancienne.
3. Redémarrez l'application : une JVM en cours d'exécution garde les anciennes classes jusque-là.
4. Relancez la recherche ci-dessus : il ne doit rester aucun ancien log4j-core, y compris dans les sauvegardes d'applications déployées qui pourraient être redéployées.

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.17.1</version>
</dependency>

Sources

Les faits de cette page viennent de ces sources ; consultez-les pour les mises à jour.

• NVD : CVE-2021-44228
• Catalogue CISA Known Exploited Vulnerabilities : CVE-2021-44228
• Apache Logging Services: Log4j security vulnerabilities
• NVD: CVE-2021-44832