[MAJ] Log4Shell : quels correctifs faut-il installer ?
Les correctifs s’enchaînent pour Log4j. Aux dernières nouvelles, pour se protéger au maximum, il faut installer la version 2.12.3 sur les environnements Java 7. Et la 2.17 à partir de Java 8.
Quelle différence avec les versions 2.12.2 et 2.16 ? L’élimination d’une faille (CVE-2021-45105) révélée le 18 décembre. Considérée comme importante (7,5 sur l’échelle CVSS), elle peut occasionner dénis de service. Le vecteur est le même que pour la vulnérabilité CVE-2021-44228, qu’on a appelée Log4Shell. En l’occurrence, l’injection de chaînes de caractères en tant que messages ou paramètres. Sur certaines configurations, cela peut déclencher une récursion infinie, un dépassement de pile… et au final le déni de service.
Pour qui n’appliquerait pas la mise à jour, la fondation Apache détaille deux solutions de contournement.
On surveillera l’éventuelle arrivée d’un nouveau patch. Il semble en tout rester au moins un point d’entrée permettant d’exploiter Log4Shell – et donc d’aller jusqu’à l’exécution de code. Le levier : l’énumération de ports sur les interfaces vulnérables, via websockets.
Blumira’s CTO @Owenwarner discovered a new vector for the #Log4j vuln that significantly expands its attack surface.
Anyone with a vulnerable Log4j version on their machine or local private network can potentially trigger the vulnerability. https://t.co/SiXUQaIpOz
— Blumira (@blumirasec) December 17, 2021
Ci-dessous, l’article initial (16 décembre 2021).
Finalement, n’installez pas Log4j 2.15. Tel est désormais le message de la fondation Apache. Initialement, elle recommandait, au contraire, de passer sur cette version, pour juguler la faille CVE-2021-44228, dite Log4Shell.
Pourquoi ce revirement ? Parce que Log4j 2.15 abrite au moins une autre faille. Identifiée CVE-2021-45046, elle est moins critique (score de base : 3,7 sur l’échelle CVSS). Mais peut tout de même, sur certaines configurations personnalisées, entraîner un déni de service. En local uniquement, sauf si on a explicitement autorisé les lookups LDAP au-delà de ce périmètre.
Que conseille maintenant la fondation Apache ? Trois solutions :
- Pour les utilisateurs de Java 7, installer Log4j 2.12.2. L’accès à l’API JNDI y est désactivé par défaut. Et un seul protocole (java) est activé en standard.
- Pour les utilisateurs de Java 8 et éditions ultérieures, passer à Log4j 2.16.0. Le protocole LDAP y reste activé par défaut, mais avec un accès limite aux objets Java. Et seul l’hôte local est autorisé en standard.
- À défaut de mise à jour, appliquer la méthode de contournement consistant à retirer la classe JndiLookup du classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
La fondation Apache n’a pas encore confirmé l’existence d’une autre vulnérabilité que des chercheurs disent avoir détectée dans Log4j 2.15. Pas de détails techniques, mais une affirmation : il existe, dans certaines circonstances, un risque d’exfiltration de données. La vidéo ci-dessous l’illustre.
Photo d’illustration © monsitj – Adobe Stock
