c'est une dépendance java, donc liée statiquement et pas dynamiquement dans les logiciels
Comme déjà précisé par kaos, je pense que tu voulais plutôt dire que les applications ne s'appuient pas sur la version fournie par le système mais que chaque application embarque sa propre version de log4j (bundling).
C'est pas lié au fait que ça soit du Java. Juste que le bundling est une pratique courante dans cet écosystème (notamment sur les applications web qui embarquent leurs dépendances dans le WAR).
Mais, même en Java, tu pourrais t'appuyer sur les dépendances systèmes fournies par ta distribution (qui ont des politiques qui poussent à "debundler" les appli Java). Il faut "juste" que ton classpath soit correctement configuré (mais ce n'est pas toujours simple, surtout si tu pars sur un serveur d'application pas toujours packagé dans ta distribution, par exemple Tomcat...) pour que ton appli utilise le log4j système et que tu passes ta dépendance en "provided" côté applicatif.
C'est donc vraiment une politique globale à avoir mais le niveau de coordination entre les équipes systèmes et applicatives serait, je pense, assez compliqué à mettre en œuvre dans un (très) grand nombre d'entreprises (mon expérience n'est pas forcément représentative mais, côté applicatif, je n'ai jamais été encouragé 1 à m'appuyer sur les lib Java déjà empaquetées par l'OS).
Cependant, j'ai quand même l'impression qu'il y aurait exactement le même problème avec une 0-day dans une lib Python/Ruby/Node/Go/Rust/etc "que tout le monde utilise".
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 !)
[^] # Re: Ouille !
Posté par bbo . En réponse au lien Log4Shell: RCE 0-day exploit found in log4j, a popular Java logging package. Évalué à 7.
Comme déjà précisé par kaos, je pense que tu voulais plutôt dire que les applications ne s'appuient pas sur la version fournie par le système mais que chaque application embarque sa propre version de log4j (bundling).
C'est pas lié au fait que ça soit du Java. Juste que le bundling est une pratique courante dans cet écosystème (notamment sur les applications web qui embarquent leurs dépendances dans le WAR).
Mais, même en Java, tu pourrais t'appuyer sur les dépendances systèmes fournies par ta distribution (qui ont des politiques qui poussent à "debundler" les appli Java). Il faut "juste" que ton classpath soit correctement configuré (mais ce n'est pas toujours simple, surtout si tu pars sur un serveur d'application pas toujours packagé dans ta distribution, par exemple Tomcat...) pour que ton appli utilise le log4j système et que tu passes ta dépendance en "provided" côté applicatif.
C'est donc vraiment une politique globale à avoir mais le niveau de coordination entre les équipes systèmes et applicatives serait, je pense, assez compliqué à mettre en œuvre dans un (très) grand nombre d'entreprises (mon expérience n'est pas forcément représentative mais, côté applicatif, je n'ai jamais été encouragé 1 à m'appuyer sur les lib Java déjà empaquetées par l'OS).
Cependant, j'ai quand même l'impression qu'il y aurait exactement le même problème avec une 0-day dans une lib Python/Ruby/Node/Go/Rust/etc "que tout le monde utilise".
+1 ! Quelques bons articles (à mon avis) sur le sujet :
* Let distros do their job (Drew Devault, Alpine)
* The modern packager’s security nightmare (Michał Górny, Gentoo) qui explique les différentes techniques que les développeurs utilisent pour gérer leurs dépendances (static linking, pinning et bundling) et une 2ème partie sur les problèmes que cela pose.
et je ne l'ai donc jamais fait :) ↩