iFrancois a dit:

J’ai toujours détesté le Java pour de bonnes raisons, ça en fait une de plus

La meme et je l’ai toujours détesté pour ses problème de sécurité xD, et j’ai toujours détesté apache (open office, httpd, etc).

Perso pour réduire le problème j’ai fermé en sortie les ports relatif a ldap sur mon router/server (ils était déjà fermé en entrée), histoire de réduire la surface d’attaque (et que les attaque utilisent ldap).

Raknor a dit:

C’est même pire que ça. Ca concerne également des systèmes embarqués, qui utiliserait du Java Embedded avec du Windows CE. Log4j peut avoir été embarqué et la GUI pourrait exposer des vecteurs d’exploitation.

Des bornes, des automates, des appliances pourraient présenter la vuln, juste par obsolescence (produit non supportés, non maintenus, constructeurs disparus…). Le problème va au-delà de la question du propriétaire.

D’ailleurs, si je reprends la citation: “Un cas très simple pour comprendre : vous avez acheté une fortune un progiciel écrit en Java. Il est tellement cher que vous n’avez pas souscrit aux mises-à-jour et donc vous avez une vieille version qui marche très bien, qui fait ce qu’elle a à faire, mais en Java 7. Ce vieil applicatif ne peut donc loguer qu’avec la version 2.12.x de log4j avec votre vieux Java : si vous faites la mise-à-jour vers la 2.17.0 de log4j, votre applicatif va se planter au démarrage.”

90% des cas, l’acheteur n’a aucune idée de ce qu’il y a dans le progiciel. Ca m’est déjà arrivé en plein audit, que l’admin sys découvre avec nous qu’un progiciel, c’était un tomcat et postgresql derrière (ça s’affiche pourtant dans les processus). Alors parler de MAJ log4j, oubliez.

Par ailleurs, le progiciel pourrait être tellement vieux, que l’éditeur pourrait simplement ne plus le supporter. Même dans le libre, si log4j 1.x n’est même pas mis à jour, il en serait de même pour des logiciels Open en version non supportés (qui fera les tests?). Là est bien entendu la faute de l’utilisateur (logiciel obsolète).

Je ne sais pas pourquoi, ce que ce soit cet article, ou le précédent traitant du sujet, on retombe sur une saillie sur le propriétaire.

J’ai meme vu aussi le cas ou j’avais un logiciel qui était édité par une boite qui n’avais plus le code source (après une vente) et que les deux dev qui l’avais fait son mort ou a la retraite et qu’aucune doc n’existe, donc il est purement impossible de modifié le logiciel, et ce logiciel est le point le plus important de la boite ou je l’ai vu, il leur est donc simplement impossible de le retirer et sont obligé de le gardé (au vu du prix investi).

La pour le coup je sais même pas si leur logiciel est vulnérable et ils ont refusé qu’on en recrée un (on propose toujours un pack avec les sources) pour qu’il puisse modifié le logiciel par un concurrent ou autre dev.

Je suis a peu près certaine que beaucoup de boite/logiciel sont dans le même cas.

Baldurien a dit:

Tu veux dire que des failles de sécurité qu’on retrouve partout (pas qu’en dans des bibliothèques écrites en Java) c’est une bonne raison ? Dans ce cas là, autant arrêter l’informatique :o

Disons que Java comme notre feu flash, a un nombre impressionnant de vulnérabilité critique et une plus que mauvaise image quand on parle de la sécurité.
En effet les autres language aussi ont ce problème j’en convient.
Mais java est plus lent que les language concurrent et n’apport rien (si on exclus le multiplateforme qui a l’époque était quasi impossible sans java).

Baldurien a dit:

C’est pareil que pour Windows et ses “failles” : plus qu’il y a d’utilisateurs, et plus on découvre des vulnérabilités (critiques ou pas). Cela ne veut pas dire qu’il n’y en a pas, et à mon avis, c’est plutôt la réactivité à corriger le problème. ça et la communication.

Quant aux lenteurs de Java, il serait temps de se mettre à jour hein. Java n’est pas plus lent qu’un autre langage, et y a que les langages types C/C++/Rust qui font mieux pour des raisons simples : pas besoin de charger une VM…

Tu trouveras différents benchmark ici : https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html Have fun à troller ton langage détecté favori.

Bon après j’imagine que ça ne t’empêchera pas de continuer à le penser… Les biais cognitifs, le ressenti, tout ça… :)

Beaucoup de dev ont utilisé java il y a 20 ans par effet de mode, et une bonne grosse partie des software écrit en java sont bien plus lent qu’il n’aurais du l’être car il utilise un language qui n’est pas optimal pour leurs opération.

Enfin java a toujours été un nit a problème de sécurité car quand il a été développé il n’avais pas la sécurité a l’esprit, beaucoup de language souffre de cette tare et ce n’est pas un soucis qui est fixable via une update.

Java (et tout autre anciens language non conçu avec la sécurité a l’esprit ou reposant sur un système impossible a corriger simplement) pour moi doit être évité/remplacer dans “tous projet qui ne le requiers pas en vue de critère objectif” et doit être replacé par des languages “moderne conçu avec la sécurité a l’esprit” de manière progressive.

Envol a dit:

Chez mon client, on m’as clairement expliqué que c’est le 1er point : la bibliothèque a été intégré dans la conf de projet java interne utilisé par défaut, donc présent dans plein de logiciel même s’il en avait pas besoin ^^’

Bon il y a probablement d’autre endroit où c’est mieux gérer mais c’est pas parce-que c’est (très) sensible que c’est forcément mieux gérer. On va plus te faire chier juste pour pas que la merdé qui est faite ressorte trop vite.

Pas rassurant tout ça pour la suite, mais un vraie Eldorado pour les hackeurs.

Dans mon cas je milite dans la boite pour qu’on ai un suivi (via logiciel) des librairies externe utilisée, histoire en deux point : 1 relancé les clients en cas de mise a jours critique d’une librairie, 2 nous aider nous dev a suivre les updates des librairie externe, car c’est humainement impossible de suivre manuellement autant de librairie, entre les mise ajours de fonctionnalité / sécurité.

Suffi de se tourné coté linux (son coté code ouvert permet de le voir plus vite), (Ubuntu ou fedora) ou on voit qu’il y a 6 ou 7 version différentes de la même librairie car tel ou tel soft la requiert cela démontre un problème généralisé dans la gestion des lib tiers de tous le secteur (le mien y compris).

Il n’y a pas de réponse simple, mais simplement ignorer le problème ne le règlera pas.

Une libraire est bien une bibliothèque, et les logs sont des journaux.

librairie et log, les français on beau avoir traduit les termes “Anglais” ne nous impose pas d’utilisé les version française.

Du cous nos librairy et nos logs, sont fix désormais.

Baldurien a dit:

Je suis curieux de savoir de quel(s) langage(s) (sans ‘u’, language c’est en anglais) tu parles ?

L’autre souci que j’ai c’est cette notion de conçu avec la sécurité à l’esprit : est-tu capable de définir des critères objectifs permettant de dire que “oui ce langage est pensé comme tel” ?

Par exemple, est-ce que forcer à l’initialisation d’une variable est un critère de sécurité ?

Java

void foobar() {

  int i;
  System.out.println(i); // erreur: i not initialized -> compilation échoue
}

C et C++

void foobar() {

  int i; 
  /*
   * en fonction du compilateur, un warning. gcc ne levait pas d'erreur à l'époque,
   * donc la compilation passe et le programme tourne même s'il affichera n'importe
   * quoi.
   */
  printf("i=%d", i); 
}

PHP

function foobar() {

  echo $i; // PHP - un warning, pas une erreur -> le programme tourne
}

Javascript

function foobar() {

  var i; // Javascript (remplacé par let et const, mais je ne suis pas expert)
  console.log(i); // undefined -> le programme tourne
}

Si oui, des 4 langages, seul Java remplit ce critère.

Sachant que là, il s’agit du langage. C’est-à-dire de ce qu’il considère comme erreur potentielle (une variable non initialisée en C peut facilement mener à une segfault, alors pourquoi ce n’est pas obligatoire ?)

Idem pour l’évaluation des branches : si ton langage ne t’impose pas de terminer toutes tes branches avec un return ou son équivalent dans le langage, ça revient plus ou moins même problème que la variable non initialisé.

Ce qui n’empéche pas de faire des erreurs de développement : bien sûr qu’il y a des failles dans Java, mais c’est le cas de tous les langages, même celui pensé avec la meilleure sécurité du monde.

Par exemple, tu peux faire du SQL dans pas mal de langages, … et tu retrouves malgré tout encore et toujours des injections SQL car non utilisation de PreparedStatement (quand c’est disponible, ex: php 4 n’avait pas ça) ou tout simplement non vérification des paramètres d’entrée.

Or pourtant, la validation des paramètres c’est plus ou moins la base de la sécurité dans les programmes : tu as un truc qui ressemble à un identifiant ? Assures toi que ça ait le bon format (nombre, etc).

Et assures toi que la personne connectée ait bien le droit d’y accéder (surtout avec le RGPD : encore pas mal de sites permettent juste de changer un identifiant pour accéder aux données personnelles du voisin).

Quelque soit la bibliothèque, quelque soit le langage, pour moi le plus important de respecter une bonne hygiène informatique :

• suivre des bonnes pratiques de sécurité pour limiter les failles (je ne suis pas théoricien, mais je pense qu’on peut facilement affirmer qu’il est impossible de démonter l’absence de failles dans une application).


• faire attention aux versions obsolètes car plus de support, plus de correctifs. Donc faire de la veille, automatiser les processus de détections, etc…

Sachant que le premier point est plus dur à obtenir quand la bibliothèque est open source, faite sur du temps libre, et que les contributeurs sont différents : il est difficile de dire que tout contributeur ait le même niveau de compréhension du code existant/des problèmes de sécurité.

TL;DR: ce n’est pas Java le problème. Ou alors si: Java Util Logging (embarqué dans le JDK depuis assez longtemps), c’est quand même pas terrible donc les développeurs Java ne s’en servent pas

Quant à l’aspect performance, c’est comme les critères objectifs sur la sécurité inhérente à un langage : ça se mesure et ça dépend du cas d’utilisation.

Donc si je comprend ton point de vue flash n’aurais jamais du être abandonné ?

qui a pourtant été abandonné pour sa sécurité plus qu’exécrable.

Certain language sont plus vulnérable que d’autre c’est un FAIT.

Ma position de vouloir réduire leur utilisation au maximum est donc une position justifiée et justifiable, même si tu ne la partage pas.

Pour ton exemple du C/C++, fait intéressant elle est lourdement vulnérable au dépassement de mémoire, et c’est d’ailleur JUSTEMENT pour ca que plusieurs projet réécrive les lib en RUST.

cjackpasbete a dit:

Le Java a eu beaucoup de vulnérabilités dues à la réflexion et à la serialization.

Il existe beaucoup de solutions qui scannent les dépendances et les comparent avec une liste de dépendances marquées comme vulnérables. Après, auditer les dépendances une à une… Si le projet utilise springboot, tu es parti pour auditer la moitié du repo maven.

Certains langages comme rust sont intéressants mais vas-y pour former une équipe de 5 bons développeurs. Si tu travailles sur un projet un peu costaud, il sera plus facile et moins cher de former une équipe de dev java. Aussi, l’écosystème autour de Java est bien avancé (CI/CD). Il n’y a pas que le langage dans un projet, mais toute la chaîne.

Finalement, les langage de programmation n’est qu’un outil qui dépend beaucoup de celui qui l’utilise. Par exemple, même avec les meilleurs outils de dentiste, vous n’allez pas vouloir que je vous soigne une carie

d’ou ma phrase, remplacé progressivement, si on commence jamais a remplacé des composant, ou a engager des gens sur des languages plus moderne ca changera jamais.

J’ai jamais demandé qu’on remplace tous ni meme donné de vitesse de remplacement (c’est impossible de tous remplacé de toute facon) mais commencé par les composant les plus critiques, genre une librairie en C++ qui gère des trucs de sécurité qui pourrais être vulnérable a un dépassement de mémoire la réécrire en rust, mais si le code qui gère l’affichage du titre lui n’est jamais remplacé on s’en fous.

Enfin si une équipe de java (par exemple) avait un expert en rust, qui peut compilé du code critique en rust et faire tourné le reste du logiciel en java), ca amène la sécurité qu’implémente rust sans trop réduire l’efficacité de l’équipe.

Et au fur et a mesure des départs et engagement tu peut inversé la tendance et augmenté la proportion de language moderne.

Parfois j’ai l’impression que les dev oublie que rien n’empêche un language d’appeler des composant compilé par un autre langage, et qu’un logiciel compilé avec de multiple langage peut être plus rapide et sécurisé (si bien fait) qu’un language unique pour tout.

OlivierJ a dit:

Ah bon… As-tu des chiffres à l’appui concernant Java qui aurait particulièrement de problèmes de sécurité ?

Oui, et même d’avantage, si on prend des langages comme le C ou le C++ (moins de vérifications de bornes).

Plus lent, non. On n’est plus en 2000. Et pour avoir développé dans pas mal de langages (et commencé avec assembleur et C), j’ai trouvé que le développement en Java, quand on avait de l’expérience, était agréable et efficace, en particulier avec des outils comme Eclipse.

Et visiblement tu regarde jamais la consommation hardware du java, c’est simple, en utilisant d’autre langage j’ai systématiquement moins de consommation ram/CPU avec d’autre language que java.