Log4j 2.17.1 corrige l’exécution de code à distance CVE-2021-44832 (mais la situation est moins grave qu’il n’y paraît)

Comme prévu précédemment, une autre vulnérabilité de sécurité touchant la bibliothèque de journalisation Log4j a été publiée vers 19 h 35 GMT, le 28 décembre 2021, sous la référence CVE-2021-44832.

Cette nouvelle vulnérabilité de sécurité CVE-2021-44832 affecte les versions jusqu’à la 2.17.0, que l’on pensait auparavant corrigée. Elle est similaire à CVE-2021-4104, qui touchait la branche 1.x de Log4j.

Impact de CVE-2021-44832

Si vous pouvez rapidement passer à la dernière version corrigée de Log4j, faites-le. Cela dit, nous tenons à souligner que cette vulnérabilité CVE-2021-44832 a reçu un score CVSS moyen de 6,6 et que son exploitation nécessite des conditions préalables particulièrement contraignantes.

CVE-2021-44832 considère Log4j 2.17.0 (et les versions antérieures) comme vulnérable à l’exécution de code si un attaquant parvient à contrôler et modifier le contenu du fichier de configuration de la journalisation, puis à le faire pointer vers une source de données URI distante afin de charger du code Java arbitraire.

Le correctif de la version 2.17.1, également rétroporté vers les anciennes versions de la bibliothèque compatibles avec les JVM, atténue cette vulnérabilité en limitant la source de données JNDI du fichier de configuration au seul protocole Java et en interdisant tout appel réseau distant.

Mesures immédiates à prendre pour corriger CVE-2021-44832

L’équipe Log4j a publié des correctifs pour cette vulnérabilité de sécurité :

• Si vous utilisez Java 8 ou une version ultérieure, passez à Log4j 2.17.1

• Si vous utilisez la branche 2.12.x avec Java 7, passez à Log4j 2.12.4

• Si vous utilisez la branche 2.3.x avec Java 6, passez à Log4j 2.3.2

Une vague de vulnérabilités Log4j divulguées prématurément

La divulgation de cette vulnérabilité s’inscrit dans une tendance de plus en plus préoccupante de divulgations irresponsables concernant Log4j : des chercheurs en sécurité ont divulgué des détails sur les vulnérabilités qu’ils avaient signalées avant que les responsables de la maintenance aient eu le temps de corriger le problème et de publier de nouvelles versions.

Ce phénomène problématique a commencé avec la vulnérabilité d’exécution de code à distance initiale de Log4j, RCE, lorsque des chercheurs ont divulgué des détails et même une preuve de concept de la vulnérabilité sur Twitter et GitHub, plusieurs heures avant l’annonce officielle (voir notre chronologie). Une fois encore, l’existence de cette vulnérabilité a été divulguée sur Twitter plusieurs heures avant la publication officielle par un chercheur en sécurité qui s’attribuait la découverte.

Dans les deux cas, la fuite d’informations, probablement sans intention malveillante, semble avoir entraîné une publication précipitée de la part d’Apache (ce qui pourrait laisser la porte ouverte à d’autres vulnérabilités et bogues dans la nouvelle version). De plus, dans ce cas précis, on peut supposer qu’Apache, s’il avait eu le choix, n’aurait pas précipité une publication à une période de l’année où de nombreuses organisations sont en congés prolongés et donc moins en mesure d’évaluer rapidement le problème et d’y remédier si nécessaire.

La sécurité de l’open source est de plus en plus importante pour le monde entier, et les pratiques de divulgation responsable sont essentielles à la sécurité durable de notre communauté. Nous espérons que les futures divulgations concernant Log4j ou d’autres packages open source pourront être gérées de manière plus sûre.

Comme toujours, chez Snyk, nous restons déterminés à appliquer notre programme de divulgation responsable, tout en restant vigilants face aux menaces émergentes potentielles et en fournissant rapidement des informations concrètes à nos utilisateurs et à l’ensemble de la communauté open source.