Ouille !

Cette faille combine des caractéristiques qui la rendent dangereuse :

• elle n'est pas sur un logiciel lui-même, mais sur une bibliothèque
• elle rend vulnérable la plupart des logiciels qui utilisent cette bibliothèque, avec une surface d'attaque assez importante et difficile à circonscrire (= toute chaîne contrôlée par l'attaquant susceptible de se retrouver dans les logs d'une façon ou d'une autre)
• si j'ai bien compris, dès que l'attaquant peut soumettre une chaîne, il a le choix entre plusieurs vecteurs d'attaque : ldap, dns ou autre (les exploits actuels et les réponses se concentrent sur ldap)
• c'est une dépendance java, donc liée statiquement et pas dynamiquement dans les logiciels (contrairement à une faille openssl qui est patchée une fois pour toute sur nos Linux en mettant à jour le paquet RPM ou DEB)

Le délai de correction sera donc assez long : il faut que la bibliothèque soit mise à jour puis que chaque logiciel qui l'utilise soit mis à jour (sachant qu'une partie de ces logiciels ne sont de toute façon plus maintenus !)

Pour se protéger en attendant que ça soit correctement patché quelqu'un de plus compétent que moi m'a proposé d'ajouter le drapeau suivant sur les lignes de commande : -Dlog4j2.formatMsgNoLookups=true (je n'ai pas testé si ça avait un impact réel ou non).

Cet exploit incite à la sobriété numérique dans les développements : il repose sur une fonction qui est déployée partout mais pour laquelle on a trouvé aucun exemple public d'utilisation légitime :

This feature is not used as far as we've been able to tell searching github and stackoverflow, so it's unnecessary for every log event in every application to burn several cpu cycles searching for the value.

source : bugtracker log4j