Posté par Samuel (site web personnel) .
Évalué à 10.
Dernière modification le 10 décembre 2021 à 22:22.
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.
Posté par _kaos_ .
Évalué à 7.
Dernière modification le 11 décembre 2021 à 04:15.
c'est une dépendance java, donc liée statiquement et pas dynamiquement dans les logiciels
Ça dépend complètement de la manière dont on génère puis exécute un jar dans son environnement. La liaison est dynamique, la résolution du classpath peut faire qu'une version embarquée masquera le reste.
Il n'y a pas que les "fat jar", dans la vie… et un jar n'est en plus qu'un zip, quelque part.
Posté par _kaos_ .
Évalué à 10.
Dernière modification le 11 décembre 2021 à 04:28.
Plus précisément, la notion de liaison statique/dynamique n'existe pas en java. Il n'y a pas d'édition de lien à aucun moment de la compilation.
C'est toujours, tout le temps, dynamique (si on veut). Le packaging en revanche se charge d'apporter (ou non) la bonne version de la librairie avec le programme lui-même.
C'est une force et une faiblesse, surtout si mal compris/utilisé.
Bon, ceci étant, ça ne change rien au fond du problème, vu que c'est pas forcément quelque chose de compris :)
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
De ce que j'ai compris, le but etait surtout son usage dans la configuration de log4j. Vu que log4j vient avec un mécanisme de configuration en XML assez fin, tu peux aussi utiliser ça pour faire le routage de tes logs via une source en LDAP sans toucher au logiciel de base, et de façon uniforme sur tous. Le souci, c'est que ce mécanisme qui est ok dans la config s'est retrouvé aussi exposé dans le code (ce qui est ok aussi), puis exposé à des chaines utilisateurs (ce qui est moins ok).
Mais avoir une fonction "log(toto)", je peux voir comment ça parait innocent. Donc pris séparément, je peux voir pourquoi personne n'a rien vu.
Le souci, c'est le mix de tout ça, lié avec la transparence réseau de java (qui a du être oublié, depuis que Scott Mc nealy ne fait plus de keynotes sur le sujet)
Et la sobriété, tout le monde est pour, sauf quand il s'agit de retirer les fonctions dont on a besoin. La, c'est indispensable bien sur et seul des codeurs nazis voudraient retirer les choses, cf le niveau de certaines discussions passées sur GNOME ou systemd pour l'audace de simplifier l'interface ou de ne pas supporter la sobriété numérique d'avoir 3000 lignes de bash qu'on peut bidouiller de partout pour l'init.
This feature is not used as far as we've been able to tell searching github and stackoverflow.
Je sais que c’est difficile à croire, mais il y a du code ailleurs que sur GitHub et des développeurs ailleurs que sur StackOverflow.
La légende raconte même qu’il y aurait des montagnes de code dormant dans des endroits totalement privés, accessibles seulement par une poignée de développeurs affiliés avec les endroits en question. Ces codes seraient notamment à la soure de ce qu’on appelle les « logiciels propriétaires ».
Bref, tout ça pour dire que se baser sur une recherche GitHub pour conclure péremptoirement que la fonctionnalité n’est pas utilisée, je trouve ça ridicule au point d’en être embarrassant.
a feature we all disliked yet needed to keep due to backward compatibility concerns
En tout cas, Log4j est un nouvel exemple de ces projets libres que tout le monde est bien content d’utiliser pour pas un rond tout en crachant à la gueule des développeurs dès qu’il y a un problème.
En tout cas, Log4j est un nouvel exemple de ces projets libres
que tout le monde est bien content d’utiliser pour pas un rond
tout en crachant à la gueule des développeurs dès qu’il y a un
problème.
Alors je pense que tu as raison, mais, même quand on paye, c'est pas cool de cracher à la gueule des devs.
Ensuite, au delà de la question de ne pas payer, il y a aussi la question du cout et de payer suffisament. De ce que je vois, les particuliers, en général, ça ne suffit pas.
On peut regarder le budget de gitea sur opencollective, on parle de l'ordre de la dizaine de milliers d'euros, mais c'est tout juste de quoi payer l'hebergement, et une machine, et l'argent pour les goodies.
On peut pas vraiment financer une personne à temps plein sur ça.
Et la, les membres de l'équipe donnent de l'argent aussi.
Donc faut s'orienter vers les entreprises, et la, tu as 2 cas.
Soit tu as un produit directement utilisable (exemple, redis, elastic search, etc), et tu montes ta propre boite.
Soit tu as un produit qui est sous forme de bibliothéque (style QT, ou log4j), et c'est beaucoup plus compliqué. QT s'en sort via le fait que c'est un gros projet et des histoires autour de la license.
Log4j, bah, personne ne va payer directement le dev pour ça car c'est trop petit. C'est comme bash ou openssh, c'est vu comme suffisament fondamental et ça fait parti de la plateforme que tu vises.
Du coup, tu as une autre solution, c'est de vendre ça comme un tout. Personne ne paye pour la maintenance de ls en particulier. Mais des gens payent des entreprises pour leur OS (RHEL, Suse, ubuntu), qui vont à leur tour payer des gens pour s'occuper des composants (exemple, Karel Zak pour coreutils, qui bosse chez RH).
Du coup, tu peux vendre ça sous forme de "Linuxfr applicatif java entreprise serveur pro version". Tu dis aux gens de cibler ça sur une version stable. mais les devs, ils aiment bien les nouvelles versions. Les versions qui corrigent des bugs, ou permettent de simplifier leur code. Donc il y a une incitation à mettre à jour.
De toute façon, y a des tests et de la CI, alors pourquoi ne pas mettre ça en bundle ?
Et puis si de toute façon, tout est dispo upstream, pourquoi tu va prendre une plateforme vu que tu utilises pas ?
Et puis, quid si le vendeur décide de prendre une autre bibliothéque, une qui fait moins de choses ? mais toi, tu as besoin de 1% de fonction en plus, mais on veut pas rajouter ça ?
Du coup, tu prends une autre lib sous license libre. Il y aura toujours plus en dehors du périmètre limité de ce qui est supporté. Et si on te laisse pas prendre une lib externe, tu te retrouves à recoder ça en interne, ce qui est pire car plus couteux, et en général moins bon.
Du coup, tout conspire à pousser à prendre la version upstream, vu que c'est du code, on veut que ça marche mais on veut aussi rajouter des fonctions rapidement et que ça bouge. Donc les gens embarquent la lib.
C'est différent du réseau ou d'un serveur, ou on veut que ça soit solide, sans avoir une tonne de fonctionnalité rapidement.
Faire payer la stabilité, on sait faire, les gens comprennent. On sait d'autant plus faire que pas grand monde ne veut le faire gratuitement (s'occuper du vieux code).
Mais la, vu que log4j est embarqué partout, même en payant, ça n'aurais rien changé.
Bref, tout ça pour dire que se baser sur une recherche GitHub pour conclure péremptoirement que la fonctionnalité n’est pas utilisée, je trouve ça ridicule au point d’en être embarrassant.
Tu le cite toi même. Ils ne disent pas que personne ne s'en sert, mais qu'ils n'ont trouvé aucun cas d'usage sur github et stackoverflow. Je ne vois pas ce qu'il y a de ridicule ou embarrassant là dedans. Ça ne dit pas que ça n'est pas utilisé, mais ça donne une info hors gros biais lié à leur source de recherche, ça semble très peu utilisé.
Pourquoi s'emballer et monter sur ses grands chevaux pour ça ?
Ils ne disent pas que personne ne s'en sert, mais qu'ils n'ont trouvé aucun cas d'usage sur github et stackoverflow
Il y a une différence entre « la fonctionnalité n’est pas utilisée par qui que ce soit sur GitHub et StackOverflow », et « la fonctionnalité n’est pas utilisée, sur la base d’une recherche exhaustive sur deux pauvres sites ».
Ça ne dit pas que ça n'est pas utilisé
C’est très exactement ce qu’ils prétendent.
Pourquoi s'emballer et monter sur ses grands chevaux pour ça ?
Et merde, j’ai encore oublié que je n’étais là que pour répondre à des trucs techniques sur OpenPGP, pas dire ce que je pense. Je me suis cru sur un réseau social, toutes mes excuses.
Posté par barmic 🦦 .
Évalué à 4.
Dernière modification le 12 décembre 2021 à 13:17.
Ils disent ce qu'ils ont fait comme recherche. Se foutre d'eux pour ça je trouve ça ridicule.
C'est le mot github qui t'a trigger je présume, mais tu n'a pas besoin de cracher sur quiconque s'en sert pour autant. Comme tu le dis ce n'est pas le centre du monde tout ça tout ça, donc il n'y a pas de besoin que tu le défend corps et âme.
Surtout si c'est pour apporter aussi peu de fond ensuite.
N'hésite pas à apporter d'autres méthodologies (d'autant qu'il y en a) pour déterminer si la fonctionnalité est utilisée ou pas ce sera probablement plus intéressant.
Plus simplement, j'aurais suggéré de rapidement leur remonter ton cas d'usage privé qui n'apparait pas sur github si stackoverflow afin qu'ils puissent en tenir compte …
Tu crois que ça n'est pas utilisé sur GitHub ni SO mais que ça serait très utilisé ailleurs ? Non c'est (quasiment) pas utilisé parce que c'est (quasiment) inutile.
De ce que j'ai compris, c'est aussi une fonctionnalité utilisable aussi dans la config xml de log4j. Donc même en ayant tout le code du monde dans github, tu pourrais ne pas savoir si c'est utilisé.
Il y a quelques années, lors d'une pycon.fr à Paris (donc ça date), j'avais discuté avec un autre membre AFpy des communautés java et python, et le contraste entre la taille des meetups java et des meetups python à l'époque était assez saisissants (genre du 1 pour 10 en faveur de java).
On était arrivé à la conclusion qu'il y avait beaucoup de codeurs java en entreprise. Et le corollaire, c'est qu'il y a énormément de code java derrière un firewall.
Donc oui, ne rien avoir sur github/SO, quand tu as une fonctionnalité utilisable dans le code et dans la configuration dans un des langages les plus utilisés dans les bases de code proprio, ça ne veut pas dire grand chose.
StackOverflow n'a rien avoir avec le fait que du code soit libre ou pas. Pour prendre un vraie décision il faut aller plus loin (regarder les mailing list, le bug tracker par exemple), mais une fonctionnalité dont personne ne se pose la moindre question semble avoir un usage très limité.
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).
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 !)
Russie RU-ITRESHENIYA, Bangladesh BD-ROOTLAYER-20190805, Microsoft, Singapour/Chypre, Pays-Bas Moneroj-VPS ou NFORCE_ENTERTAINMENT, Grèce EUGENIDES-GR, États-Unis DIGITALOCEAN-167-71-0-0, Australie APNIC-ERX-146-56-0-0, Brésil DIQUA12, Allemagne Tor-Exit, Chine ALISOFT… Cet appel au voyage et à la rêverie.
En effet. Nous n'utilisons pas log4j pour les couches applicative et je n'arrive pas à mixer notre configuration avec celle de log4j…
Les tentatives ont commencé le 10. Et ksh
% journalctl -u tomcat9 | grep jndi | wc -l
204
Après une première analyse, nous ne semblons pas impacté. C'est la première fois cela dit qu'une attaque cible nos sites avec précision et qui aurait potentiellement pu fonctionner.
https://twitter.com/eastdakota/status/1469800951351427073
Cloudflare: "Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure."
Merci pour ce schéma, très clair.
Si je comprends bien : en intervenant sur (au moins) une de ces 5 étapes, on peut se prémunir de l'attaque Log4Shell ? L'idéal étant sans doute d'agir sur toutes, pour avoir ceinture et bretelles et …
Et me vient donc une question : l'étape 5 n'est-elle pas désactivée, par défaut ? Il me paraît inconcevable, pour des raisons évidentes de sécurité, que la configuration par défaut soit d'autoriser l'exécution d"un code Java venant de l'extérieur !
Si je comprends bien : en intervenant sur (au moins) une de ces 5 étapes, on peut se prémunir de l'attaque Log4Shell ? L'idéal étant sans doute d'agir sur toutes, pour avoir ceinture et bretelles et …
Oui, surtout que, par exemple, les URL au niveau de l'étape 1 peuvent être très diverse (donc difficile à bloquer), genre construire des url avec des ${lowercase:L,lowercase:D… ou du base64 décoder plus tard.
Et me vient donc une question : l'étape 5 n'est-elle pas désactivée, par défaut ? Il me paraît inconcevable, pour des raisons évidentes de sécurité, que la configuration par défaut soit d'autoriser l'exécution d"un code Java venant de l'extérieur !
Il me semble que c'est bloquer après java 8 mais qu'il y a quand même moyen de contourner le blocage dans certains cas. Ensuite, même s'il n'y a pas d'exploitation de code, il est possible de leaker les secrets (par exemple, en incluant les variables d'environnements qui peuvent contenir des mots de passe dans le domaine et en regardans les logs dns).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Ouille !
Posté par Samuel (site web personnel) . Évalué à 10. Dernière modification le 10 décembre 2021 à 22:22.
Cette faille combine des caractéristiques qui la rendent dangereuse :
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 :
source : bugtracker log4j
[^] # Re: Ouille !
Posté par _kaos_ . Évalué à 7. Dernière modification le 11 décembre 2021 à 04:15.
Ça dépend complètement de la manière dont on génère puis exécute un jar dans son environnement. La liaison est dynamique, la résolution du classpath peut faire qu'une version embarquée masquera le reste.
Il n'y a pas que les "fat jar", dans la vie… et un jar n'est en plus qu'un zip, quelque part.
Matricule 23415
[^] # Re: Ouille !
Posté par _kaos_ . Évalué à 10. Dernière modification le 11 décembre 2021 à 04:28.
Plus précisément, la notion de liaison statique/dynamique n'existe pas en java. Il n'y a pas d'édition de lien à aucun moment de la compilation.
C'est toujours, tout le temps, dynamique (si on veut). Le packaging en revanche se charge d'apporter (ou non) la bonne version de la librairie avec le programme lui-même.
C'est une force et une faiblesse, surtout si mal compris/utilisé.
Bon, ceci étant, ça ne change rien au fond du problème, vu que c'est pas forcément quelque chose de compris :)
Matricule 23415
[^] # Re: Ouille !
Posté par Misc (site web personnel) . Évalué à 10.
De ce que j'ai compris, le but etait surtout son usage dans la configuration de log4j. Vu que log4j vient avec un mécanisme de configuration en XML assez fin, tu peux aussi utiliser ça pour faire le routage de tes logs via une source en LDAP sans toucher au logiciel de base, et de façon uniforme sur tous. Le souci, c'est que ce mécanisme qui est ok dans la config s'est retrouvé aussi exposé dans le code (ce qui est ok aussi), puis exposé à des chaines utilisateurs (ce qui est moins ok).
Mais avoir une fonction "log(toto)", je peux voir comment ça parait innocent. Donc pris séparément, je peux voir pourquoi personne n'a rien vu.
Le souci, c'est le mix de tout ça, lié avec la transparence réseau de java (qui a du être oublié, depuis que Scott Mc nealy ne fait plus de keynotes sur le sujet)
Et la sobriété, tout le monde est pour, sauf quand il s'agit de retirer les fonctions dont on a besoin. La, c'est indispensable bien sur et seul des codeurs nazis voudraient retirer les choses, cf le niveau de certaines discussions passées sur GNOME ou systemd pour l'audace de simplifier l'interface ou de ne pas supporter la sobriété numérique d'avoir 3000 lignes de bash qu'on peut bidouiller de partout pour l'init.
[^] # Re: Ouille !
Posté par gouttegd (site web personnel) . Évalué à 10.
Je sais que c’est difficile à croire, mais il y a du code ailleurs que sur GitHub et des développeurs ailleurs que sur StackOverflow.
La légende raconte même qu’il y aurait des montagnes de code dormant dans des endroits totalement privés, accessibles seulement par une poignée de développeurs affiliés avec les endroits en question. Ces codes seraient notamment à la soure de ce qu’on appelle les « logiciels propriétaires ».
Bref, tout ça pour dire que se baser sur une recherche GitHub pour conclure péremptoirement que la fonctionnalité n’est pas utilisée, je trouve ça ridicule au point d’en être embarrassant.
Et ça ne correspond pas vraiment à ce que dit un développeur de Log4j sur Twitter :
En tout cas, Log4j est un nouvel exemple de ces projets libres que tout le monde est bien content d’utiliser pour pas un rond tout en crachant à la gueule des développeurs dès qu’il y a un problème.
Monde de merde, tiens.
[^] # Re: Ouille !
Posté par Misc (site web personnel) . Évalué à 5.
Alors je pense que tu as raison, mais, même quand on paye, c'est pas cool de cracher à la gueule des devs.
Ensuite, au delà de la question de ne pas payer, il y a aussi la question du cout et de payer suffisament. De ce que je vois, les particuliers, en général, ça ne suffit pas.
On peut regarder le budget de gitea sur opencollective, on parle de l'ordre de la dizaine de milliers d'euros, mais c'est tout juste de quoi payer l'hebergement, et une machine, et l'argent pour les goodies.
On peut pas vraiment financer une personne à temps plein sur ça.
Et la, les membres de l'équipe donnent de l'argent aussi.
Donc faut s'orienter vers les entreprises, et la, tu as 2 cas.
Soit tu as un produit directement utilisable (exemple, redis, elastic search, etc), et tu montes ta propre boite.
Soit tu as un produit qui est sous forme de bibliothéque (style QT, ou log4j), et c'est beaucoup plus compliqué. QT s'en sort via le fait que c'est un gros projet et des histoires autour de la license.
Log4j, bah, personne ne va payer directement le dev pour ça car c'est trop petit. C'est comme bash ou openssh, c'est vu comme suffisament fondamental et ça fait parti de la plateforme que tu vises.
Du coup, tu as une autre solution, c'est de vendre ça comme un tout. Personne ne paye pour la maintenance de ls en particulier. Mais des gens payent des entreprises pour leur OS (RHEL, Suse, ubuntu), qui vont à leur tour payer des gens pour s'occuper des composants (exemple, Karel Zak pour coreutils, qui bosse chez RH).
Du coup, tu peux vendre ça sous forme de "Linuxfr applicatif java entreprise serveur pro version". Tu dis aux gens de cibler ça sur une version stable. mais les devs, ils aiment bien les nouvelles versions. Les versions qui corrigent des bugs, ou permettent de simplifier leur code. Donc il y a une incitation à mettre à jour.
De toute façon, y a des tests et de la CI, alors pourquoi ne pas mettre ça en bundle ?
Et puis si de toute façon, tout est dispo upstream, pourquoi tu va prendre une plateforme vu que tu utilises pas ?
Et puis, quid si le vendeur décide de prendre une autre bibliothéque, une qui fait moins de choses ? mais toi, tu as besoin de 1% de fonction en plus, mais on veut pas rajouter ça ?
Du coup, tu prends une autre lib sous license libre. Il y aura toujours plus en dehors du périmètre limité de ce qui est supporté. Et si on te laisse pas prendre une lib externe, tu te retrouves à recoder ça en interne, ce qui est pire car plus couteux, et en général moins bon.
Du coup, tout conspire à pousser à prendre la version upstream, vu que c'est du code, on veut que ça marche mais on veut aussi rajouter des fonctions rapidement et que ça bouge. Donc les gens embarquent la lib.
C'est différent du réseau ou d'un serveur, ou on veut que ça soit solide, sans avoir une tonne de fonctionnalité rapidement.
Faire payer la stabilité, on sait faire, les gens comprennent. On sait d'autant plus faire que pas grand monde ne veut le faire gratuitement (s'occuper du vieux code).
Mais la, vu que log4j est embarqué partout, même en payant, ça n'aurais rien changé.
Nous, on pensait que ça pouvait être un traineau.
[^] # Re: Ouille !
Posté par gouttegd (site web personnel) . Évalué à 8.
J’ai oublié le mandatory XKCD.
[^] # Re: Ouille !
Posté par barmic 🦦 . Évalué à 4.
Tu le cite toi même. Ils ne disent pas que personne ne s'en sert, mais qu'ils n'ont trouvé aucun cas d'usage sur github et stackoverflow. Je ne vois pas ce qu'il y a de ridicule ou embarrassant là dedans. Ça ne dit pas que ça n'est pas utilisé, mais ça donne une info hors gros biais lié à leur source de recherche, ça semble très peu utilisé.
Pourquoi s'emballer et monter sur ses grands chevaux pour ça ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouille !
Posté par gouttegd (site web personnel) . Évalué à 4.
Il y a une différence entre « la fonctionnalité n’est pas utilisée par qui que ce soit sur GitHub et StackOverflow », et « la fonctionnalité n’est pas utilisée, sur la base d’une recherche exhaustive sur deux pauvres sites ».
C’est très exactement ce qu’ils prétendent.
Et merde, j’ai encore oublié que je n’étais là que pour répondre à des trucs techniques sur OpenPGP, pas dire ce que je pense. Je me suis cru sur un réseau social, toutes mes excuses.
[^] # Re: Ouille !
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 12 décembre 2021 à 13:17.
Ils disent ce qu'ils ont fait comme recherche. Se foutre d'eux pour ça je trouve ça ridicule.
C'est le mot github qui t'a trigger je présume, mais tu n'a pas besoin de cracher sur quiconque s'en sert pour autant. Comme tu le dis ce n'est pas le centre du monde tout ça tout ça, donc il n'y a pas de besoin que tu le défend corps et âme.
Surtout si c'est pour apporter aussi peu de fond ensuite.
N'hésite pas à apporter d'autres méthodologies (d'autant qu'il y en a) pour déterminer si la fonctionnalité est utilisée ou pas ce sera probablement plus intéressant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouille !
Posté par xavier Granveaux . Évalué à 2.
Plus simplement, j'aurais suggéré de rapidement leur remonter ton cas d'usage privé qui n'apparait pas sur github si stackoverflow afin qu'ils puissent en tenir compte …
[^] # Re: Ouille !
Posté par ff9097 . Évalué à 1.
Tu crois que ça n'est pas utilisé sur GitHub ni SO mais que ça serait très utilisé ailleurs ? Non c'est (quasiment) pas utilisé parce que c'est (quasiment) inutile.
[^] # Re: Ouille !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Si c'est inutile alors on peut virer…
--->[]“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ouille !
Posté par Misc (site web personnel) . Évalué à 3.
De ce que j'ai compris, c'est aussi une fonctionnalité utilisable aussi dans la config xml de log4j. Donc même en ayant tout le code du monde dans github, tu pourrais ne pas savoir si c'est utilisé.
Il y a quelques années, lors d'une pycon.fr à Paris (donc ça date), j'avais discuté avec un autre membre AFpy des communautés java et python, et le contraste entre la taille des meetups java et des meetups python à l'époque était assez saisissants (genre du 1 pour 10 en faveur de java).
On était arrivé à la conclusion qu'il y avait beaucoup de codeurs java en entreprise. Et le corollaire, c'est qu'il y a énormément de code java derrière un firewall.
Donc oui, ne rien avoir sur github/SO, quand tu as une fonctionnalité utilisable dans le code et dans la configuration dans un des langages les plus utilisés dans les bases de code proprio, ça ne veut pas dire grand chose.
[^] # Re: Ouille !
Posté par barmic 🦦 . Évalué à 3.
StackOverflow n'a rien avoir avec le fait que du code soit libre ou pas. Pour prendre un vraie décision il faut aller plus loin (regarder les mailing list, le bug tracker par exemple), mais une fonctionnalité dont personne ne se pose la moindre question semble avoir un usage très limité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ouille !
Posté par bbo . Évalué à 5.
Visiblement, c'est uniquement disponible sur log4j2 >= 2.10.0
[^] # Re: Ouille !
Posté par bbo . É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 :) ↩
# Logs LinuxFr.org
Posté par Benoît Sibaud (site web personnel) . Évalué à 10. Dernière modification le 11 décembre 2021 à 13:09.
Russie RU-ITRESHENIYA, Bangladesh BD-ROOTLAYER-20190805, Microsoft, Singapour/Chypre, Pays-Bas Moneroj-VPS ou NFORCE_ENTERTAINMENT, Grèce EUGENIDES-GR, États-Unis DIGITALOCEAN-167-71-0-0, Australie APNIC-ERX-146-56-0-0, Brésil DIQUA12, Allemagne Tor-Exit, Chine ALISOFT… Cet appel au voyage et à la rêverie.
[^] # Re: Logs LinuxFr.org
Posté par YBoy360 (site web personnel) . Évalué à 1.
En effet. Nous n'utilisons pas log4j pour les couches applicative et je n'arrive pas à mixer notre configuration avec celle de log4j…
Les tentatives ont commencé le 10. Et
ksh
% journalctl -u tomcat9 | grep jndi | wc -l
204
Après une première analyse, nous ne semblons pas impacté. C'est la première fois cela dit qu'une attaque cible nos sites avec précision et qui aurait potentiellement pu fonctionner.
# En vrac
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Mageia https://advisories.mageia.org/CVE-2021-44228.html
…
premier signalement à BlackHat 2016 https://twitter.censors.us/th3_protoCOL/status/1469644923028656130
répondre à l'attaque par une bombe zip https://twitter.censors.us/shipilev/status/1469407591629524998
débat sur le manque de financement / soutien aux mainteneurs de paquets largement utilisées https://twitter.censors.us/campuscodi/status/1469723936950730759 ou https://twitter.censors.us/bagder/status/1469761130503487492 ou https://twitter.censors.us/bert_hu_bert/status/1469772892980363267
motif utilisé dans les adresses de courriel https://twitter.censors.us/lean0x2f/status/1469233245715849218
motif utilisé dans les SSID https://twitter.censors.us/hackerfantastic/status/1469481775172829192
attaque contre Minecraft https://twitter.censors.us/_JohnHammond/status/1469255402290401285
attaque contre Tor https://twitter.censors.us/SwiftOnSecurity/status/1469453353822339073
[^] # Re: En vrac
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
[^] # Re: En vrac
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Et une liste de logiciels concernés ou non (pratique pour avoir les statuts) :
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
[^] # Re: En vrac
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
https://twitter.com/eastdakota/status/1469800951351427073
Cloudflare: "Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure."
# Un schéma pour comprendre
Posté par HL . Évalué à 5.
Source : GovCert.ch - Licence CC BY 4.0.
[^] # Re: Un schéma pour comprendre
Posté par windu.2b . Évalué à 2.
Merci pour ce schéma, très clair.
Si je comprends bien : en intervenant sur (au moins) une de ces 5 étapes, on peut se prémunir de l'attaque Log4Shell ? L'idéal étant sans doute d'agir sur toutes, pour avoir ceinture et bretelles et …
Et me vient donc une question : l'étape 5 n'est-elle pas désactivée, par défaut ? Il me paraît inconcevable, pour des raisons évidentes de sécurité, que la configuration par défaut soit d'autoriser l'exécution d"un code Java venant de l'extérieur !
[^] # Re: Un schéma pour comprendre
Posté par claudex . Évalué à 3.
Oui, surtout que, par exemple, les URL au niveau de l'étape 1 peuvent être très diverse (donc difficile à bloquer), genre construire des url avec des ${lowercase:L,lowercase:D… ou du base64 décoder plus tard.
Il me semble que c'est bloquer après java 8 mais qu'il y a quand même moyen de contourner le blocage dans certains cas. Ensuite, même s'il n'y a pas d'exploitation de code, il est possible de leaker les secrets (par exemple, en incluant les variables d'environnements qui peuvent contenir des mots de passe dans le domaine et en regardans les logs dns).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Bis repetita
Posté par Colargol (site web personnel) . Évalué à 3.
https://www.zdnet.fr/actualites/une-deuxieme-vulnerabilite-de-log4j-decouverte-et-un-nouveau-patch-publie-39934151.htm
[^] # Re: Bis repetita
Posté par barmic 🦦 . Évalué à 4.
C'est normal. Une fois que la lumière est mise sur un projet là dessus, elle est bien plus auditée pendant quelques temps.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bis repetita
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Et depuis il y a une nouvelle nouvelle version 2.17.0 https://logging.apache.org/log4j/2.x/ et https://issues.apache.org/jira/browse/LOG4J2-3230?jql=project%20%3D%20LOG4J2%20AND%20fixVersion%20%3D%202.17.0
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.