Les 0 et 1 ne sont pas sécurisés ! Il faut se servir des Infos entre les 1 et 0 de noc Chers informaticiens 
2 « J'aime »
Vous avez raison. C’est juste un raccourci… Et je suis heureux d’apprendre que comme log4Net, log4j est beaucoup moins utilisé.
Ceci n’est pas juste… Tout d’abord .Net n’est pas un langage mais un framework. Le langage c’est c# ou vb ou ce que vous voulez d’autre qui respecte la CLI.
Pour .Net comme pour Java (qui est aussi un framework), les librairies du Framework peuvent contenir des failles. Ce n’est pas parce que c’est fourni par un éditeur que c’est exempt d’anomalies malheureusement.
2 « J'aime »
Petite correction, .NET n’est pas un langage, mais un Framework, il comprend C#, F# et VB .NET
Java n’est pas un Framework (n’inversons pas les rôles) mais un langage (orientée objet) à part entière, ce qui relève du Framework sont ici : Java (langage) — Wikipédia
Je persiste: certes c’est un langage dans le sens où il a une syntaxe spécifique, mais je langage seul ne fait rien puisqu’il ne compile pas en natif et qu’il lui faut un framework pour tourner (et le JDK pour compiler). C’est d’ailleurs expliqué dans l’article que vous mettez en copie. En d’autres terme le Framework et le langage portent le même nom.
Là tu confonds JVM et framework. Avec le compilateur officiel, le Java se compile effectivement pas en binaire natif, il se compile en binaire pour le bytecode de la JVM, mais tu peux quand même tout a fait faire un programme en Java n’utilisant aucune fonction des frameworks « officiels » Java (bon, tu iras pas loin hein, mais tu peux) et le compiler pour l’exécuter dans une JVM, sans aucune dépendance à la moindre librairie Java d’un framework.
Et à l’inverse tu peux compiler du Java en natif (ou du bytecode adapté à une autre VM, comme celle de .NET par exemple), même s’il utilise des fonctions des frameworks officiels (auquel cas, il faut par contre aussi compiler en natif les librairies de ces framework). Ce n’est pas parce que le compilateur officiel ne le fait pas que ce n’est pas possible. Techniquement, tous les langages sont compilables en natifs. Pour Java, c’est ce que propose par exemple le compilateur du projet GNU (GCJ), qui peut compiler de façon classique vers du bytecode JVM, mais aussi vers du natif pour différentes architectures (et il peut également transpiler du bytecode JVM vers du natif, ce qui permet de produire des librairies natives à partir de librairies déjà compilées en bytecode même sans avoir leur sources).
L’autre exemple classique, c’est Android. Android utilise le langage Java, mais n’utilise ni les frameworks officiels ni le bytecode officiel (VM Dalvik puis Android Runtime, qui a son propre bytecode). C’est pour ça que Google avait été attaqué par Oracle, qui lui reprochait justement de détourner le langage Java.
Bref, le langage Java est bien indépendant dans frameworks « officiels » Java développés par Sun puis Oracle, même si le plus souvent ils sont utilisés ensemble.
1 « J'aime »
Je ne suis pas d’accord sur les termes utilisés mais c’est pas grave.
ce qui me marque c’est ça : « Dès que la vulnérabilité et la manière de l’exploiter ont été rendues publiques » les cybercriminelle ce sont jetés dessus.
Alors pourquoi rendre la faille publique ??? et surtout, est-ce que l’historique de cette faille est tout bonnement une belle histoire pour justifier l’action des cybercriminelles en leur donnant le feu vert.
ça me rappelle des mises en scène de l’Histoire qui sont devenus vrais alors qu’elles n’ont aucun fondement. Après Java on sait qu’en général c’est truffé de failles.
Parce que le code est open source, donc en regardant les modifications du code, on peut voir qu’une faille a été corrigée, même s’il n’y a pas de communication officielle à son sujet.
Et parce qu’en l’absence de communication officielle à son sujet, les millions de gens qui utilisent cette librairie, directement ou indirectement, ne sauront pas qu’il faut la mettre à jour, et seront donc vulnérable à l’exploitation de la faille.
En l’occurrence, ce n’est PAS une faille de Java.
1 « J'aime »
ok pour Java, j’avais compris que cela utilisait le moteur de java.
Le problème est que maintenant que tout le monde sait qu’il faut mettre à jour il est sûr et certains que la faille sera exploitée. après je comprends une décision est très souvent à double tranchant.
Sur un truc aussi utilisé que log4j, y avait pas le choix. La faille aurait été détectée dès la mis en ligne du correctif, et il y aurait en bien plus de monde resté vulnérable qu’aujourd’hui.
Oui, log4j est en Java, et l’exploit utilise une fonctionnalité offerte par Java EE, un framework Java très utilisé notamment pour les applications web.
Mais la faille ne se situe pas au niveau de Java ou de Java EE, les fonctions utilisées fonctionnent comme attendu, c’est une mauvaise utilisation par log4j qui crée la vulnérabilité (vulnérabilité qui est d’ailleurs atténuée avec les versions récentes du runtime Java officiel, qui par défaut bloque certains accès à des ressources distantes).
1 « J'aime »
A part pour les développeurs, y’en a qui installent encore Java sur leur machine?
C’est un nid a bactéries ce truc 
Heureusement qu’aucune personne n’ai eu la bonne idée de le mettre sur des équipements réseaux. Bon courage aux collègues qui bossent sur des services infra 
Bah tous ceux qui utilisent des applications développées en Java…
Sauf que cette faille est connue depuis 2016 (cf l’article, conférence Blackhat).
Et le fait qu’elle soit rendue publique, c’est une chose, mais elle a sans doute été exploitée en toute discrétion depuis des années …
Comme sans doute d’autres failles en ce moment même, pas encore dévoilées au grand jour.
Alors, c’est certain que quand une vulnérabilité aussi importante et facilement exploitable se retrouve avec une telle visibilité ça craint, mais d’un autre côté, j’ai l’impression que c’est un peu la seule façon de faire en sorte que tout le monde se bouge.
Et je ne parle pas que des développeurs de l’application concernées, mais aussi des admins et autres qui doivent mettre à jours les services utilisant ladite appli.
Edit : D’ailleurs, les patchs sortis avant la version 2.17 de log4j ne semblent pas particulièrement efficaces :
https://logging.apache.org/log4j/2.x/
Bref …
1 « J'aime »
L’exposition des librairies et des licences est pourtant une obligation légale en LGPL / GPL (même si Apache est plus permissif)! 
Et dans tous les cas la responsabilité est sur l’éditeur du soft, donc ils doivent informer leurs utilisateurs de la faille et mettre en place les actions correctives!
Tout comme .net ou n’importe quel autre framework…
C’est un peu une caricature de dire « C’est un nid a bactéries ce truc ». Le potentiel de problème est certes relativement élevé, mais c’est inhérent à la puissance du langage et à toutes les librairies et autres extensions associées qui exploitent cette puissance (log4j dans le cas présent).
On peut retrouver le même problème dans pas mal de choses. Le webgl est le premier truc qui me vient à l’esprit, ou l’accès bas niveau depuis un service web laisse la potentiellement le porte ouverte à de jolis problèmes.
Oui tu n’as pas tord … mais en même temps avec cette com le nombre d’attaques a explosé et ça a généré une panique absolument pas nécessaire… résultats des courses il y en a qui passent leurs soirées et weekends à mettre en place des workarounds et il faudra qu’ils y repassent encore quand les éditeurs auront sortis des patchs. Vu la période (Noël) tu comprendras…qu’ils apprécient 
Vous vous êtes emmêlés les pinceaux !
-
On ne parle pas du langage java, lais d’un module de logging (journalisation) nommé Log4J, on peux l’installer sur son ordinateur, ou pas !
-
C’est très réducteur, et cela fait surtout très cliché de dire que « C’est un nid a bactéries ce truc », on peut dire la même chose avec n’importe quel Framework, langage etc…
Mode Associé du Diable activé
Ah l’injection, c’est décidément mon hack préféré.