Log4shell : les jours d’après

Citan Abonné

Le 21/12/2021 à 16h11

#1

“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.”

Merci pour cette illustration si saillante et malheureusement courante du monde du propriétaire (je n’ose dire représentative, car après tout il y a aussi des brebis galeuses dans l’open source qui mettent la majorité des features en premium, mais je le pense néanmoins très fort xd).

Et surtout, MERCI pour l’article. J’avais entendu parler forcément (notamment ici) mais je m’étais pas renseigné plus que ça, c’est top d’avoir une explication pédagogique + une étude d’INpact.

Derived

Le 21/12/2021 à 17h07

#1.1

Le propriétaire, mais surtout le custom.

Les ESN travaillent majoritairement avec du Java comme backend d’API, pour créer des applications spécifiques aux besoins d’un client, qui n’existent nulle part ailleurs : pas possible bien souvent d’utiliser des composants sur étagère libres ou non, il faut passer par des développements custom.

Raknor Abonné

Le 21/12/2021 à 17h16

#1.2

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.

boogieplayer

Le 21/12/2021 à 17h56

#1.3

Raknor

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.

+1 Rien à ajouter.

Dyfchris

Le 21/12/2021 à 16h33

#2

Merci pour l’article :)

Sheeris

Le 21/12/2021 à 16h43

#3

Pour Log4j 1.2.x Debian/Ubuntu on fait un fix pour le CVE-2019-17571, cette même version n’as même pas JMSAppender (donc utilisation du CVE-2021-4104 impossible).

Oxygen Abonné

Le 21/12/2021 à 18h46

#3.1

Idem chez RHEL également

iFrancois Abonné

Le 21/12/2021 à 16h51

#4

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

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 16h58

#5

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).

Sheeris

Le 21/12/2021 à 17h03

#6

SIaelrod a dit:

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).

Rajoute le port 1389 (port utilisé dans des PoC) car la majorité des tentatives n’utilise pas le port LDAP (389) ou LDAPS (636).

jotak Abonné

Le 21/12/2021 à 17h06

#7

Ce qui me scie le plus dans cette histoire, c’est que la faille existe depuis presque 10 ans, rendant vulnérables les plus grosses boites de la tech, bancaires, les gouvernements etc. et malgré la simplicité de la faille et son exploitation, aucun audit de sécurité ne l’a repérée?
Je sais pas, j’imagine que rien qu’un nom de classe “JndiLookup” devrait allumer deux ou trois warnings chez les infosec, non?

Raknor Abonné

Le 21/12/2021 à 17h21

#7.1

log4j est une lib déclarée en dépendance. Le code est donc compilée (.jar)
Le lookup est une feature builtin, cad qu’il n’y a pas besoin de l’invoquer lors de l’utilisation du logger. Juste l’utilisation de la lib suffit.

Aucune société n’audite les dépendances, elles sont nombreuses.

jotak Abonné

Le 21/12/2021 à 17h25

#7.2

Raknor

log4j est une lib déclarée en dépendance. Le code est donc compilée (.jar)
Le lookup est une feature builtin, cad qu’il n’y a pas besoin de l’invoquer lors de l’utilisation du logger. Juste l’utilisation de la lib suffit.

Aucune société n’audite les dépendances, elles sont nombreuses.

Euhhh… auditer les dépendances c’est la base, y’a tellement de choses qui passent par là, les supply chain attacks notamment. J’aimerais savoir sur quoi tu t’appuies pour dire “aucune société n’audite les dépendances” ?

Raknor Abonné

Le 21/12/2021 à 17h47

#7.3

jotak

Euhhh… auditer les dépendances c’est la base, y’a tellement de choses qui passent par là, les supply chain attacks notamment. J’aimerais savoir sur quoi tu t’appuies pour dire “aucune société n’audite les dépendances” ?

Si on parle d’un progiciel : c’est déjà une gageure d’auditer le progiciel en lui-même. A moins de signer un NDA ou si c’est exigé par contrat (par ex, d’intégration), c’est peu probable que l’éditeur fournisse le code source, qui permettrais à l’utilisateur de “revendre” le progiciel (ou simplement, le cracker). D’autant qu’il a intérêt à obfusquer ses binaires (pour ralentir le reverse).
Donc en tant qu’acheteur final, difficile de budgéter une équipe de reverse pour juste valider la sécurité d’un logiciel.

De même qu’en tant qu’éditeur, on va juste s’assurer que les binaires de dépendances ont bien été fourni par le développeur (signature, hash, canal de téléchargement sûr). Même pour des dépendances open-source, quel budget et quels délais consacrer pour vérifier ces dépendances nombreuses?
Combien de vuln ont été reportées par des chercheurs en sécurité travaillant chez Google, IBM, etc etc??? Pas mal.
Combien de vuln ont été reportées par des ESN (très gros utilisateurs de dépendances dans leurs projets)? 0?

jotak Abonné

Le 21/12/2021 à 17h53

#7.4

Raknor

Si on parle d’un progiciel : c’est déjà une gageure d’auditer le progiciel en lui-même. A moins de signer un NDA ou si c’est exigé par contrat (par ex, d’intégration), c’est peu probable que l’éditeur fournisse le code source, qui permettrais à l’utilisateur de “revendre” le progiciel (ou simplement, le cracker). D’autant qu’il a intérêt à obfusquer ses binaires (pour ralentir le reverse).
Donc en tant qu’acheteur final, difficile de budgéter une équipe de reverse pour juste valider la sécurité d’un logiciel.

De même qu’en tant qu’éditeur, on va juste s’assurer que les binaires de dépendances ont bien été fourni par le développeur (signature, hash, canal de téléchargement sûr). Même pour des dépendances open-source, quel budget et quels délais consacrer pour vérifier ces dépendances nombreuses?
Combien de vuln ont été reportées par des chercheurs en sécurité travaillant chez Google, IBM, etc etc??? Pas mal.
Combien de vuln ont été reportées par des ESN (très gros utilisateurs de dépendances dans leurs projets)? 0?

Dans mon message auquel tu as répondu, je citais justement les big techs, les banques, etc. Évidemment c’est de leur part que je m’étonne de n’avoir pas, ou mal, audité une lib comme log4j. Pas de la petite PME du coin ;-)
Les grosses ESN, je sais pas comment ils approchent la sécurité, mais j’imagine qu’ils doivent pas faire trop à la légère non plus surtout lorsqu’ils sont sur du stratégique / défense etc.

the_Grim_Reaper Abonné

Le 22/12/2021 à 12h56

#7.6

jotak

Dans mon message auquel tu as répondu, je citais justement les big techs, les banques, etc. Évidemment c’est de leur part que je m’étonne de n’avoir pas, ou mal, audité une lib comme log4j. Pas de la petite PME du coin ;-)
Les grosses ESN, je sais pas comment ils approchent la sécurité, mais j’imagine qu’ils doivent pas faire trop à la légère non plus surtout lorsqu’ils sont sur du stratégique / défense etc.

faut-il vraiment répondre ?

Je vois peu d’ESN qui vont aller faire ce genre de choses, excepter, peut être, éventuellement, celles qui en plus proposent des SOC au clients.

Mais très honnêtement, c’est beau l’espoir …

Quand tu vois que certaines ESN savent moins bien que leur client comment fonctionnent leurs progiciels …

Citan Abonné

Le 22/12/2021 à 11h43

#7.5

Faire un audit de sécurité ? Examiner un produit open source pour l’évaluer avant de l’utiliser ? Faire de la veille pour MAJ quand failles ? Nanmého t’es pas un peu fou ? On a pas le temps pour ces conneries…

X mois après… “CHEF C’est la CRRRIIIIIIISE”

Bah ouais, comme toujours quand on agit pas en professionnel, on se mange le retour de flamme…

SebGF Abonné

Le 21/12/2021 à 17h10

#8

Sheeris a dit:

Rajoute le port 1389 (port utilisé dans des PoC) car la majorité des tentatives n’utilise pas le port LDAP (389) ou LDAPS (636).

Auquel j’ajouterai à titre perso : tout port non utilisé doit être bloqué par défaut dans les deux sens.

the_Grim_Reaper Abonné

Le 22/12/2021 à 12h14

#8.1

la base .. ce qui n’est pas explicitement autorisé est interdit.

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 17h11

#9

Sheeris a dit:

Rajoute le port 1389 (port utilisé dans des PoC) car la majorité des tentatives n’utilise pas le port LDAP (389) ou LDAPS (636).

Ajouté merci du conseil. je me doute que certain essayeront de changer le port mais la majorité des “hackeur” de 13 ans qui utiliseront tel quel (qui comprennent meme pas la notion de port) seront bloqué.
Je me doute que c’est un pensement sur une fracture ouverte mais c’est mieux que rien.

SebGF Abonné

Le 21/12/2021 à 17h23

#10

J’ai pu constater de mon côté qu’elle est activement exploitée, les logs de mon serveur web perso dégueulent de tentatives d’injection via l’URL (heureusement, aucun runtime derrière pour répondre).

Jean_G Abonné

Le 21/12/2021 à 19h55

#10.1

(reply:1919139:Sheepux)
J’ai aussi regardé sur mon petit serveur perso et effectivement il y a des traces à partir du 10. Je ne m’inquiétais pas plus que cela car tout est en PHP (comme chez Facebook, qui est une des rares grandes sociétés qui semble ne pas être touchée). Après, mettons-nous à la place d’un attaquant (mafia, état) qui aurait connaissance de la faille avant la divulgation : je n’aurai pas arrosé tout partout pour attaquer avec celle-ci, car elle ne serait pas restée secrète très longtemps. Donc il est possible que des attaques aient eu lieu avant le 9, mais beaucoup plus discrètement. On en apprendra peut-être plus dans quelques temps.

SebGF Abonné

Le 21/12/2021 à 20h44

#10.2

Jean_G

(reply:1919139:Sheepux)
J’ai aussi regardé sur mon petit serveur perso et effectivement il y a des traces à partir du 10. Je ne m’inquiétais pas plus que cela car tout est en PHP (comme chez Facebook, qui est une des rares grandes sociétés qui semble ne pas être touchée). Après, mettons-nous à la place d’un attaquant (mafia, état) qui aurait connaissance de la faille avant la divulgation : je n’aurai pas arrosé tout partout pour attaquer avec celle-ci, car elle ne serait pas restée secrète très longtemps. Donc il est possible que des attaques aient eu lieu avant le 9, mais beaucoup plus discrètement. On en apprendra peut-être plus dans quelques temps.

Une faille non divulguée est effectivement du pain béni pour les attaquants, donc je pense que durant le temps où elle fut discrètement exploitée ça a certainement provoqué quelques belles brèches.

Sheepux Abonné

Le 21/12/2021 à 21h38

#10.3

Jean_G

(reply:1919139:Sheepux)
J’ai aussi regardé sur mon petit serveur perso et effectivement il y a des traces à partir du 10. Je ne m’inquiétais pas plus que cela car tout est en PHP (comme chez Facebook, qui est une des rares grandes sociétés qui semble ne pas être touchée). Après, mettons-nous à la place d’un attaquant (mafia, état) qui aurait connaissance de la faille avant la divulgation : je n’aurai pas arrosé tout partout pour attaquer avec celle-ci, car elle ne serait pas restée secrète très longtemps. Donc il est possible que des attaques aient eu lieu avant le 9, mais beaucoup plus discrètement. On en apprendra peut-être plus dans quelques temps.

Le vrais sujet a en tirer est la rapidité à une faille d’être appropriée par Internet et la nécessité d’être capable de redéployer des versions corrigées trés rapidement. Rien qu’en interne c’était le bordel; entre dsi qui ne voulait pas risquer un plantage applicatif (régression) et CDS de dev qui ne suivaient pas les consignes SSI et se limitaient aux quelques actions qu’ils avaient glané par eux même,(dans notre cas le fait d’utiliser la variable d’env nolookup qui n’etait finalement qu’un paliatif partiel)
Bref que du fun. En tout cas une chouette expérience de niveau de crise majeure. Tout un REX à faire en interne.

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 17h27

#11

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.

Citan Abonné

Le 22/12/2021 à 11h27

#11.1

Et à ce genre d’histoire, d’un côté j’ai envie de lâcher un bon gros “CHEH” pour les incompétents qui ont osé planter pareille épine dans leur boîte, de l’autre je plains les employés de ladite boîte qui sont donc dirigés, au moins partiellement, par des incompétents avérés. Et je prie pour la survie des malheureux qu’on chargerait un jour de développer une solution de remplacement en reprenant les données (vu que bien souvent la solution propriétaire souhaitant te conserver les couilles dans l’étau ne prévoit aucun chemin de migration des données, voire même a développé son format bien propriétaire et verouillé sans specs ni api).

Baldurien Abonné

Le 21/12/2021 à 17h32

#12

iFrancois a dit:

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

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

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 17h38

#13

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).

tryde

Le 21/12/2021 à 17h39

#14

“qui maintient éveillé des équipes IT”
You don’t say! Depuis lundi dernier en tant que responsable indus agence je passe mon temps à glaner les infos de la centaine de projets, de leurs dépendances, à compiler tout ça, produire des guide de correction (quand on peut!), balancer des centaines de mails de rappel, et la moitié des gens est en congé…

De belles vacances en perspectives !

bilbonsacquet Abonné

Le 21/12/2021 à 17h42

#15

SebGF a dit:

J’ai pu constater de mon côté qu’elle est activement exploitée, les logs de mon serveur web perso dégueulent de tentatives d’injection via l’URL (heureusement, aucun runtime derrière pour répondre).

Idem, et ce très rapidement après la sortie de la faille.

Par contre, au taf, on a pas mal d’appli qui étaient vulnérables… certaines ont purement et simplement été arrêtées.

Je me souviens d’un CRM Sage bâti sur du .net ET du Tomcat… (allez comprendre…), il y a de grandes chances qu’il soit vulnérable…

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 17h51

#16

bilbonsacquet a dit:

Idem, et ce très rapidement après la sortie de la faille.

Par contre, au taf, on a pas mal d’appli qui étaient vulnérables… certaines ont purement et simplement été arrêtées.

Je me souviens d’un CRM Sage bâti sur du .net ET du Tomcat… (allez comprendre…), il y a de grandes chances qu’il soit vulnérable…

Pareille chez nous les deux logiciel vulnérable (non facilement fixable) ont été arrêtée.
Car l’entreprise fait passé la mise a jours des clients (revenu) une fois les clients qui nous on contacté mis a jour (logique vous me direr) on verra ce qu’on fait de ces deux outils.

Sheepux Abonné

Le 21/12/2021 à 18h01

#17

“De nombreux signalements ont été émis dès le 13 décembre”
Dès le Vendredi 10 décembre à midi on a vu passer des tentatives d’exploitation (petit filtre jndi+ldap dans les logs de l’ensemble du parc)

Jean_G Abonné

Le 21/12/2021 à 18h24

#17.1

Je parlais des signalements publics, je n’ai pas (encore) accès aux logs de ta boîte Sérieusement, je n’ai pas (pour l’instant) vu passer de publications signalant des attaques plus tôt, mais on risque de faire encore pas mal de découvertes, la faille a très bien pu être exploitée par des équipes bien renseignées avant même la publication officielle. Et à partir du 9, c’est devenu open bar… Mais félicitations à la fois pour le filtre et pour avoir vu aussi vite des traces d’attaques !

Sheepux Abonné

Le 21/12/2021 à 19h20

#17.2

Jean_G

Je parlais des signalements publics, je n’ai pas (encore) accès aux logs de ta boîte Sérieusement, je n’ai pas (pour l’instant) vu passer de publications signalant des attaques plus tôt, mais on risque de faire encore pas mal de découvertes, la faille a très bien pu être exploitée par des équipes bien renseignées avant même la publication officielle. Et à partir du 9, c’est devenu open bar… Mais félicitations à la fois pour le filtre et pour avoir vu aussi vite des traces d’attaques !

Disons que dans une certaine grande entreprise qui gère des trains on a –“quelques sites”– exposés. On est passé en gestion de crise dès les annonces et on a vu arriver quelque truc rapidement. On a même pu voir évoluer les tentatives en direct.

Gom Abonné

Le 21/12/2021 à 18h16

#18

Merci beaucoup pour cet article clair et aussi détaillé. Même en ayant fuit le java depuis 20 ans, j’ai réussi à comprendre :)

fry

Le 21/12/2021 à 18h22

#19

yep, merci pour l’article :)

Baldurien Abonné

Le 21/12/2021 à 18h32

#20

SIaelrod a dit:

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).

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… :)

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 20h02

#21

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

Le 21/12/2021 à 20h09

#22

jotak a dit:

Dans mon message auquel tu as répondu, je citais justement les big techs, les banques, etc. Évidemment c’est de leur part que je m’étonne de n’avoir pas, ou mal, audité une lib comme log4j. Pas de la petite PME du coin ;-) Les grosses ESN, je sais pas comment ils approchent la sécurité, mais j’imagine qu’ils doivent pas faire trop à la légère non plus surtout lorsqu’ils sont sur du stratégique / défense etc.

Pour bosser dans une grosse ESN chez un client classifié Secret UE, c’est la même méthode qu’ailleurs, ils l’ont pas venu venir et vont devoir arrêter plein de logiciel stratégique qui pourrait même retarder des dossiers client a des millions d’euros…
Quand la team qui va devoir réparer ce joyeux bordel est venu me dire cela, pour nous prévenir que côté support utilisateur, va falloir être très pédagogue pour calmer la grogne a la rentrée ^^’

RaphAstronome Abonné

Le 21/12/2021 à 20h15

#23

Pour ma part des attaques dans les logs depuis le 10 mais presque aucun site utilise Java.

L’un d’eux sur un extranet était vulnérable mais j’avais mis un code d’accès au niveau du serveur web (un peu comme un htaccess mais au niveau du VirtualHost). Sans ce code pas de sollicitation du java qu’il y a derrière. N’empêche que j’étais bien content d’avoir mis cela en place même si cela fait régulièrement râler certains car deux codes (le code pour l’accès + leur login/pass pour l’appli).

Par contre autre soucis que j’ai eu : arriver à calmer certains qui paniquent et veulent tout couper alors que leur site est entièrement en PHP sans un gramme de java.

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 20h15

#24

Envol a dit:

Pour bosser dans une grosse ESN chez un client classifié Secret UE, c’est la même méthode qu’ailleurs, ils l’ont pas venu venir et vont devoir arrêter plein de logiciel stratégique qui pourrait même retarder des dossiers client a des millions d’euros… Quand la team qui va devoir réparer ce joyeux bordel est venu me dire cela, pour nous prévenir que côté support utilisateur, va falloir être très pédagogue pour calmer la grogne a la rentrée ^^’

Et ce qui me terrifie le plus c’est

Les devs qui implémentes des librairies sans savoir ce qu’elle sont, ni vérifié leur dernière update ou quoi puis oublie et, donc le nombre de logiciels vulnérable que le développeur lui même a oublier et qui répondra via blog que ces logiciels sont non vulnérable.

Les boites ouvertement touchée qui diront ne pas l’être pour ne pas devoir mettre a jours les logiciel client (qui eux ne verront rien et les croiront).

C’est ces deux points qui me terrifie le plus.

Envol

Le 21/12/2021 à 20h18

#24.1

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.

Raknor Abonné

Le 21/12/2021 à 21h01

#24.2

C’est un peu le principe de la POO.

Quand un editeur peut soustraiter (le sous traitant lui-même peut soustraiter etc etc)…, c’est compliqué de savoir si on est vuln ou pas.

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 20h26

#25

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.

Raknor Abonné

Le 21/12/2021 à 21h04

#25.1

C’est le B-A-BA de la gestion de conf et de suivi de l’obsolescence.
Sauf que suivre, mettre à jour et tester, ça coute.

Quand t’as une lib qui sert à 6-7 projets simultanément, la mettre à jour implique une cascade de conséquences.

Si ça se faisait facilement, on le ferait déjà…

anagrys Abonné

Le 21/12/2021 à 21h50

#25.2

Raknor

C’est le B-A-BA de la gestion de conf et de suivi de l’obsolescence.
Sauf que suivre, mettre à jour et tester, ça coute.

Quand t’as une lib qui sert à 6-7 projets simultanément, la mettre à jour implique une cascade de conséquences.

Si ça se faisait facilement, on le ferait déjà…

Gros +1, en général, les libs obsolètes, on ne les traîne pas parce-que ça nous fait plaisir mais plutôt par manque de temps pour faire (et gérer) la mise à jour, surtout si elle n’apporte rien de visible.

Comme le fait de changer de langage… dans la plupart des projets existants, le langage est plus ou moins imposé par ce qui est connu dans la société, ce qui est disponible sur le marché, ce qui bénéficie d’un gros écosystème, ou d’un bon support. Dans ma (grosse) boîte, clairement, on trouve du Java, du .Net et du C pour ce qui est le plus critique. Un peu de Python par ci par là et quelque trucs plus exotiques, mais on ne va pas réécrire un soft qui a commencé sa vie en Java il y a 20 ans juste pour le plaisir de le réécrire (on galère déjà assez pour lui faire quitter Java8 !)
Et là, je ne parle que des dév internes. Quand tu as des comportements spécifiques en Java dans tes bases Oracle, pas sûr que tu sois motivé pour tout changer (un exemple parmi d’autres).

Après, je peux me tromper, mais une appli qui embarque une version vulnérable de log4j sans l’utiliser (cas présenté plus haut) est-elle vulnérable à cette faille ? Il me semble qu’il faut qu’un message compromis soit traité par le moteur de la librairie de logging - et que le serveur distant soit accessible, ce qui est peu fréquent dans un SI fait correctement.

Zone démilitarisée

Le 21/12/2021 à 20h48

#26

Il s’agit à la base d’une ~~librairie~~ bibliothèque écrite en Java pour des applications Java. Son rôle est de permettre une gestion unifiée et cohérente des logs applicatives, comme son nom l’indique (log4j signifiant « Log For Java »).

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

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 20h51

#27

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.

Jean_G Abonné

Le 21/12/2021 à 22h23

#28

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

voui, voui, à une différence près : log est le terme anglais correct, alors que librairie est un anglicisme, d’usage incorrect. Soit on dit library, soit on dit bibliothèque. Je ne suis pas opposé à l’anglais, je suis opposé aux anglicismes. Nuance.

Moi aussi !!

Baldurien Abonné

Le 21/12/2021 à 22h30

#29

SIaelrod a dit:

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.

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.

jotak Abonné

Le 21/12/2021 à 22h38

#29.1

Globalement d’accord avec ça, la vision de Java comme un langage qui serait un nid de failles est imho une vision très éculée, ceci dit il y a quand même des langages réputés plus secure, comme rust (en fait je vois que lui mais sans doute y en a-t-il d’autres). Mais c’est beaucoup moins mainstream dans tous les cas. Dans les langages mainstream, je n’en vois pas qui saute aux yeux.

Gardons à l’esprit aussi que la majorité des CVE vient toujours de ce bon vieux buffer overflow, qui est plutôt l’appanage de c/c++.

jotak Abonné

Le 21/12/2021 à 22h32

#30

anagrys a dit:

Après, je peux me tromper, mais une appli qui embarque une version vulnérable de log4j sans l’utiliser (cas présenté plus haut) est-elle vulnérable à cette faille ? Il me semble qu’il faut qu’un message compromis soit traité par le moteur de la librairie de logging - et que le serveur distant soit accessible, ce qui est peu fréquent dans un SI fait correctement.

Tout à fait.
Encore faut-il vérifier que les dépendances elles-mêmes n’utilisent pas log4j. Dans tous les cas, si on l’a dans son classpath, mieux vaut la mettre à jour (une lib de log c’est pas le plus difficile à mettre à jour en général) ou virer la classe JndiLookup (ne serait-ce aussi que pour se prémunir des futurs usages)

Baldurien Abonné

Le 21/12/2021 à 22h34

#31

janiko a dit:

voui, voui, à une différence près : log est le terme anglais correct, alors que librairie est un anglicisme, d’usage incorrect. Soit on dit library, soit on dit bibliothèque. Je ne suis pas opposé à l’anglais, je suis opposé aux anglicismes. Nuance.

Moi aussi !!

On dit bibliothèque quand c’est open source, et qu’on peut se servir gratuitement (en l’échange d’une carte, appelée LICENCE).
Et on dit librairie quand c’est payant.

Ce n’est pourtant pas compliqué !

Exemple : log4j2 est une bibliothèque Open Source, IBM WebSphere MQ est une librairie.

(sur ce, je sors)

Freeben666 Abonné

Le 22/12/2021 à 14h26

#31.1

N’importe quoi. Ça vient juste de l’anglais “library”, souvent mal traduit en “librairie” en français, au lieu de “bibliothèque”. Aucune notion de payant/gratuit/libre là dedans…

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 22h41

#32

Raknor a dit:

C’est le B-A-BA de la gestion de conf et de suivi de l’obsolescence. Sauf que suivre, mettre à jour et tester, ça coute.

Quand t’as une lib qui sert à 6-7 projets simultanément, la mettre à jour implique une cascade de conséquences.

Si ça se faisait facilement, on le ferait déjà…

Pourquoi crois tu que je milite pour qu’une réponse logicielle soit développée en interne pour suivre les dépendances de manière automatisée ?

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 21/12/2021 à 22h44

#33

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.

jotak Abonné

Le 21/12/2021 à 23h08

#33.1

J’aimerais quand même bien savoir quels langages tu considères comme secure ou pas, autant pour rust je comprends, mais pour moi tous les autres (java, c, c++, c#, php, js, python…) sont à peu près dans le même sac. Donc la comparaison avec flash, comment dire… si on va dans ce sens, on jette tout aux orties et on ne garde que rust. C’est ça l’idée ? 🙂

Freeben666 Abonné

Le 22/12/2021 à 14h28

#33.2

Oui enfin là, log4shell ce n’est pas une vulnérabilité du langage Java en soit, mais une mauvaise configuration par défaut dans un projet codé en Java.

Krystanos

Le 22/12/2021 à 14h35

#33.3

Freeben666

Oui enfin là, log4shell ce n’est pas une vulnérabilité du langage Java en soit, mais une mauvaise configuration par défaut dans un projet codé en Java.

Certes, mais le bordel créé par Oracle autour de Java fait qu’on se retrouve avec du Java 7 qui date de 2011. Le problème de Java, c’est pas Java, c’est Oracle.

Quant aux problèmes de dépendances, je dirais que Java est mieux loti que Node, Python ou autre langages avec un SDK encore plus limité et qui dépend encore plus de contributions tiers.

Mais Java pâtit ici de son énorme part de marché.

Baldurien Abonné

Le 21/12/2021 à 23h25

#34

SIaelrod a dit:

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…

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.

Tu ne réponds pas à ma question.

Flash est un logiciel propriétaire et dont l’utilité est devenue moindre avec le temps (comme les applets Java) vu que Javascript permet de faire beaucoup plus de choses maintenant. Y a même des émulateurs Nintendo 64 ou Flash en Javascript, c’est dire !

Vu que utilité moindre + cout de maintenance de l’éditeur + problème de sécurité lié au sandboxing plugin/navigateur/runtime, c’est pas étonnant que l’éditeur ait arrêté. On parle d’Adobe : si Javascript et CSS3 permettent de faire tout ce que permettait Flash, Flash n’a alors plus d’intérêt.

Et dire qu’un langage est plus vulnérable qu’un autre, ce n’est pas ce que je ne dis pas.

Je te demande de fournir un exemple de langage qui correspond à tes critères de sécurité.

J’imagine que si tu parles de langage, c’est que tu développes un tant soit peu ? que tu connais un minimum le sujet ?

Je dis ça car j’aimerai bien comprendre ce ressenti à mon sens absurde vis à vis de Java, sur l’aspect sécurité - les lenteurs, c’est encore un autre sujet (et hors sujet par rapport à l’article :)).

Surtout quand le langage même a des structures (mémoire via gc, évaluation des branches, etc) qui sécurise la machine virtuelle…

Chocolat-du-mendiant Abonné

Le 22/12/2021 à 03h23

#35

Il me semble que pour la sécurité de Java, c’est surtout le plugin des navigateurs qui était critique.
Comme Flash (et d’autres), souvent laxiste sur la sécu, et sans possibilité pour le navigateur de contrôler ce qu’il faisait.
La faille principale étant souvent l’utilisateur qui lui donnait des trucs louche à faire tourner.
Ils ont compris, un peu tard, qu’un utilisateur lambda n’a pas à savoir faire la différence entre un gif animé et un programme Flash, ou Java, qui peut faire beaucoup plus de choses en plus de lui afficher une pub rigolote.

Je suis pas dev, mais j’ai cru comprendre que le pb n’est pas le “langage Java” en lui-même, mais globalement “Java” quand on essaye de lui faire faire des choses qu’il fait mal.
Dans le trillion de failles qui ont frappés Java, il y en peut-être sur le langage lui-même, mais l’essentiel doit être sur le plugin ou sur la JVM qui laissait faire des trucs qui n’étaient pas prévu par ses concepteurs.

cjackpasbete

Le 22/12/2021 à 03h56

#36

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

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 22/12/2021 à 05h17

#37

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.

fofo9012 Abonné

Le 22/12/2021 à 07h23

#38

Les macs sont (étaient ?) vulnérable simplement en scannant les wifi à proximité :
https://github.com/YfryTchsGD/Log4jAttackSurface/blob/master/pages/apple.md

Une borne wifi avec le nom qui va bien, un mac scanne les réseaux à proximité, le mouchard de télémétrie d’Apple se déclenche et mémorise le nom des bornes et la position du mac, pour “améliorer les données de localisation”.
Sauf que le mouchard Apple se base sur log4j :facepalm: …

Freeben666 Abonné

Le 22/12/2021 à 14h30

#38.1

Suffisait de changer le nom de son iPhone avec la payload qui va bien pour hacker iCloud ;-)

fofo9012 Abonné

Le 22/12/2021 à 08h22

#39

Baldurien a dit:

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

Il faut connaitre son langage et notamment son niveau d’abstraction :

vers le bas niveau ASM, C, C++ ne pas initialiser une variable est une catastrophe (et source de nombreuses failles). Le dev est plus difficile mais tu peux avoir de super perf ou passer outre certains contrôles.

vers le plus haut niveau C#, Java : Ces langages vont compiler les contrôles à ta place ou initialiser la variable par défaut selon son type. (pour rappel C n’est pas du tout typé :) ) donc tuy gagnes en simplicité sur ce point mais te mange en contrepartie la lourdeur du typage à outrance, des names spaces long comme le bras ou encore coder des getters / setters totalement inutiles.

enfin les scripts contrôleront ça à l’exécution ce qui apporte une grande souplesse (ex ne rien typer) mais révèle certaines erreurs au moment des tests. Par ex en javascript tu as l’instruction eval qui permet de faire n’importe quoi (dans tous les sens du terme :) )

Le Rust est un bon compromis sur ce point : tu as les perfs du C et la sécurité d’un modèle de mémoire infaillible. (bon faut réussir à capter le tas et la pile et compiler son code :) ) Mais le langage est difficile d’accès donc tu ne peux pas tout dev en Rust (sinon bonjour la maintenance quand personne ne connait le langage) il faut le réserver pour les endroits critiques (bibliothèques ou fonctions critiques) .

refuznik Abonné

Le 22/12/2021 à 09h19

#39.1

Tu sais, on utilise encore du Cobol dans pleins d’endroits critique et surtout pour le backoffice jusqu’à maintenant.

YonX

Le 22/12/2021 à 09h25

#40

Je suis de bonne humeur ce matin alors je participe au troll Java et consort .

Pour info, 8ans de java et dans les équipe de support au dev. Je peut dire avec une grande certitude que le soucis se trouve entre la chaise et le clavier! Changer de langage ne changera pas les dev mais ajouterais beaucoup plus de failles dans les applications. J’en ai vu des belles et j’imagine pas ce que ça aurais été en C/C++/Rust, Java à l’avantage d’avoir la JVM qui optimise énormément le code de merde et qui nettoie les saleté.

Un exemple: on doit appeler la BDD, mais renvoyer le résultat uniquement si il y a moins de 100 entrées et en parallèle on met le resultat dans un fichier.

Resultat? On charge la table une fois et on met de côté pour potentiellement renvoyer, on charge une deuxième fois et on compte, on charge une troisième fois pour mettre en fichier.

Avec Java au moins on a pas eu de fuite mémoire.

Comme tous les langages, Java a les problèmes que sa force amène: son universalité. Tu veut chercher des objets stockées dans un LDAP distant? On a la solution. Oui c’est débile, oui c’est dangereux mais certains en avaient besoin donc Java le permet.

J’ai lu a de multiples endroits que les dev logs4j avaient dit que le lookup était débile, mais ça à été demandé et voté donc ils l’ont fait (a prendre avec des pincettes, je suis pas remonté à la source, les mailing list c’est pas ma tasse de thé).

En ce qui concerne Rust, j’en fait en perso depuis 6mois pour des petits projets. J’adore le langage, et il ne remplacera pas Java. C’est pas sa cible tout simplement.

Et comme dit avant, les principales failles Java concernaient les applets, qui était une mauvaise idée, vendue comme une sandbox invulnérable et qui à été bien trop utilisé. Du coup même genre de faille que Docker, flatpak et autres sandbox.

tl;dr: On peut faire du caca avec tous les langages et certains Dev/Client s’en donnent à cœur joie. Le « soucis » et l’avantage de Java est qu’il permet de « tout » faire et certains en profitent pour « mal » faire.

Zone démilitarisée

Le 22/12/2021 à 09h26

#41

Baldurien a dit:

On dit bibliothèque quand c’est open source, et qu’on peut se servir gratuitement (en l’échange d’une carte, appelée LICENCE). Et on dit librairie quand c’est payant.

Ce n’est pourtant pas compliqué !

Exemple : log4j2 est une bibliothèque Open Source, IBM WebSphere MQ est une librairie.

(sur ce, je sors)

IBM WebSphere MQ est une bibliothèque.

Le mot français pour library est bibliothèque, que la licence de celle-ci soit gratuite ou payante. En néerlandais on dit bibliotheek, en espagnol biblioteca, en polonais biblioteka, en portugais biblioteca, en russe библиотека, etc. En allemand on dit Bibliothek ou Library, et en italien on dit biblioteca ou libreria.

Le mot anglais pour librairie est bookshop.

davidBoB Abonné

Le 22/12/2021 à 09h49

#42

Très bon article, merci Jean.
C’est impeccable parce qu’on peut envoyer ce genre d’article à des personnes qui n’ont pas forcément l’envie ou le temps de se documenter ailleurs.

Merci

Wosgien Abonné

Le 22/12/2021 à 10h33

#43

Citan666 a dit:

Merci pour cette illustration si saillante et malheureusement courante du monde du propriétaire (je n’ose dire représentative, car après tout il y a aussi des brebis galeuses dans l’open source qui mettent la majorité des features en premium, mais je le pense néanmoins très fort xd).

Ca c’st le vieux monde. Le nouveau monde c’est:
“Nous utilisons des technologies opensource mais nous sommes incapable d’installer notre soft, nous fournissons du SAAS ou des VM. Nous sommes incapables de patcher les couches basses car nous n’avons plus les (la) ressources qui ont créé la base du logiciel. Mais on est opensource!!!”

Après, le truc c’est que avec un peu de sécu (genre: aucun serveur ne peut initier une communication vers l’extérieur), on a un peu de temps pour patcher.

SIaelrod a dit:

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).

Tu n’es donc pas un programmeur.

La mauvaise image de Java vient:

D’un bashing à une époque où on disait que Java était plus lent que le C sur le calcul. Sauf que dans une appli de gestion, le calcul est rarement nécessaire. Et Java a apporté le support des nombre décimaux, des dates, de l’unicode là où c’était un CALVAIRE en C. Et s’il fallait comparer les perfs de calcul, ceux qui faisaient du C auraient dû se comparer au fortran - ce n’aurait pas toujours eté à l’avantage du C.

D’un bashing lié au garbage collector - qui a été ensuite implémenté dans des bibliothèques C/C++ - car oui, c’est utile. Java ne donne pas le choix de ne pas l’utiliser par contre

De plusieurs versions bien pourries (Java5, Java6 et un peu 7) qui cassaient des compatibilités

D’une librairie graphique bien lourde (mais avec l’ancienne librairie graphique, je faisais du Java sur un 486 avec 16Mo de RAM sans problème

Là où Java à imposé une vision plus moderne du dev:

Java ne nécessite pas de tout recompiler à chaque fois et ça marche (coucou borland C++ et la précompilation… ou watcom C)

Java simplifie les injections de plugins

Java proposait du multithread et de la synchro plus simple et portable dès le début

Java proposait la gestion des échanges réseau, du HTTP, du HTML, du XML, des dates, des décimaux de façon intégrée et “cohérente” là où en C/C++ il fallait se battre

Java a une documentation centrale depuis le début

Java a des défauts, mais alors dire qu’il est lent à l’époque Python, Javascript, et après la période PHP pré-7 (à partir du 7, les optimisations PHP sous la pression de FB ont permis de diminuer le nombre de serveurs, souvent en divisant par 2 leur nombre), c’est mal connaître l’outil.

Après, il reste LE problème: quand Java c’était SUN, on avait une certaine confiance dans son avenir gratuit, quand c’est devenu ORACLE, on l’a pas mal perdue…

bidou.bidou Abonné

Le 22/12/2021 à 10h53

#44

Du point de vue de l’administrateur système et réseau, le problème du java c’est que, trop souvent, on a juste un .jar, .war ou un truc java web start. Pas de source, pas de mise à jour (où hors de portée de nos moyens financiers), pour savoir les dépendances incluses, on peut toujours partir à la pêche, mais de toutes façons on ne pourra pas les mettre à jour. C’est souvent très dépendant de la version de java (voire de si on prend l’implémentation libre ou le binaire fourni par Oracle).
Oracle facture désormais très cher quand on a besoin d’une vieille version, et en plus ça engendre plein de failles de sécurité. Les applet java ont été abandonnées, puis le java web start, du coup on se retrouve sans vraie solution de secours.
Sans doute faute d’expérience en java, je trouve souvent plus simple de faire tourner de vieux binaires en reconstituant les librairies dépendantes que d’arriver à faire tourner de vieux logiciels java.

Bon, les applis en php qui passent mal d’une version à l’autre c’est aussi très courant, mais sauf obfuscation on arrive généralement à s’en tirer.

Citan Abonné

Le 22/12/2021 à 11h41

#45

YonX a dit:

Je suis de bonne humeur ce matin alors je participe au troll Java et consort .
Un exemple: on doit appeler la BDD, mais renvoyer le résultat uniquement si il y a moins de 100 entrées et en parallèle on met le resultat dans un fichier. Resultat? On charge la table une fois et on met de côté pour potentiellement renvoyer, on charge une deuxième fois et on compte, on charge une troisième fois pour mettre en fichier. Avec Java au moins on a pas eu de fuite mémoire.

Donc tu fais trois fois la même requête pour des usages différents qui peuvent tous exploiter le jeu de données de ta première requête ? Non seulement je ne vois pas le rapport avec une éventuelle fuite mémoire, mais je trouve que c’est au contraire l’exemple parfait de la contre-efficacité…

S’pas comme ça que tu vas lutter contre la réputation de lenteur de Java, à laquelle je souscris sans faille : les solutions logicielles Java que j’utilise, notamment Confluence et Jira pour pas les citer, demandent toutes des ressources minimales largement plus conséquentes par rapport à leur périmètre fonctionnel si on projette une réalisation similaire dans d’autres langages. Après c’est peut-être propre aux applications web. J’utilise peu de solutions “desktop” (à part LibreOffice, mais mon usage est tellement basique que pour le coup c’est bien fluide ^^).

YonX

Le 22/12/2021 à 14h43

#45.1

Il y a une grosse méprise donc je le répète. Je suis dans l’équipe qui fait, entre autre, le support des Dev. Je les aide quand ils arrivent pas à débug, quand ils comprennent pas les perf et pour tout ce qui tourne autour du dev (git, CI/CD, docker, IDE etc).

Le cas que je t’ai montré viens d’un ticket que je résumerais à « C’est trop lent, le client tombe en timeout, ça à commencé à la migration Docker, c’est de votre faute. ».

Et l’exemple que je donne est bien stupide, crade, tout ce que tu veut. Mais c’est un code que des Dev avaient pondu et livré en Prod.
Donc imaginer ces même dev faire du C/C++ -> fuite mémoire immédiate et « On a cas reboot toutes les X heures » (du vécu encore malheureusement).

Je le redit. Le soucis c’est pas le langage, c’est les Dev la plupart du temps.

Et le cas log4j le montre encore. Si les requêtes extérieures sont filtrés en mode whitelist, la faille est beaucoup moins flippante. Mais dans certains SI on ne filtre que ce qui rentre, « on vas pas ralentir les Dev en imposant une demande d’ouverture à chaque fois ».

Ramaloke Abonné

Le 23/12/2021 à 10h24

#45.2

YonX

Il y a une grosse méprise donc je le répète. Je suis dans l’équipe qui fait, entre autre, le support des Dev. Je les aide quand ils arrivent pas à débug, quand ils comprennent pas les perf et pour tout ce qui tourne autour du dev (git, CI/CD, docker, IDE etc).

Le cas que je t’ai montré viens d’un ticket que je résumerais à « C’est trop lent, le client tombe en timeout, ça à commencé à la migration Docker, c’est de votre faute. ».

Et l’exemple que je donne est bien stupide, crade, tout ce que tu veut. Mais c’est un code que des Dev avaient pondu et livré en Prod.
Donc imaginer ces même dev faire du C/C++ -> fuite mémoire immédiate et « On a cas reboot toutes les X heures » (du vécu encore malheureusement).

Je le redit. Le soucis c’est pas le langage, c’est les Dev la plupart du temps.

Et le cas log4j le montre encore. Si les requêtes extérieures sont filtrés en mode whitelist, la faille est beaucoup moins flippante. Mais dans certains SI on ne filtre que ce qui rentre, « on vas pas ralentir les Dev en imposant une demande d’ouverture à chaque fois ».

Je confirme aussi que (je boss en réseau), c’est TRES courant qu’on se fasse accuser d’avoir un réseau “lent” alors que 95% du temps, c’est l’appli qui est codé avec des palmes (voire pire) et qui, effectivement, fait des “DIZAINES DE MILLIERS” d’appels réseau pour télécharger quelques MO.

Les appels BDD étant particulièrement violents dans certaines applis, j’ai déjà vu en analyse une appli qui faisait une requête réseau par LIGNE de BDD. En gros plutôt que de télécharger la table (“array” il me semble ?), ça téléchargeait ligne à ligne. Et ca le faisait 3 fois de suite ! (une fois pour regarder, une fois pour “valider” ce qu’il faut prendre et une troisième fois pour “récupérer les bonnes entrées”. (en plus c’était IBM le dev…)
A un moment ils ont migrés dans le “cloud” et ils sont passés de ~10-15s de temps de réponse à plusieurs minutes entre un serveur “on prem” et un cloudeur (en plus on était bon côté réseau, il y avait qqchose comme 20ms de latence entre les deux) et qui on a accusé ? Des semaines de taskforce d’incidents à expliquer 40 fois la même chose au responsable applicatif qui ne comprenait rien, et bien sûr appli en prod et livré donc cacahuète pour modifier quoi que ce soit.

Je pense qu’en réseau, l’éloignement de la BDD avec le front/middle c’est le plus criant pour repérer une appli pourri, ça se ressent immédiatement niveau utilisateur.

Raknor Abonné

Le 23/12/2021 à 15h01

#45.3

Ramaloke

Je confirme aussi que (je boss en réseau), c’est TRES courant qu’on se fasse accuser d’avoir un réseau “lent” alors que 95% du temps, c’est l’appli qui est codé avec des palmes (voire pire) et qui, effectivement, fait des “DIZAINES DE MILLIERS” d’appels réseau pour télécharger quelques MO.

Les appels BDD étant particulièrement violents dans certaines applis, j’ai déjà vu en analyse une appli qui faisait une requête réseau par LIGNE de BDD. En gros plutôt que de télécharger la table (“array” il me semble ?), ça téléchargeait ligne à ligne. Et ca le faisait 3 fois de suite ! (une fois pour regarder, une fois pour “valider” ce qu’il faut prendre et une troisième fois pour “récupérer les bonnes entrées”. (en plus c’était IBM le dev…)
A un moment ils ont migrés dans le “cloud” et ils sont passés de ~10-15s de temps de réponse à plusieurs minutes entre un serveur “on prem” et un cloudeur (en plus on était bon côté réseau, il y avait qqchose comme 20ms de latence entre les deux) et qui on a accusé ? Des semaines de taskforce d’incidents à expliquer 40 fois la même chose au responsable applicatif qui ne comprenait rien, et bien sûr appli en prod et livré donc cacahuète pour modifier quoi que ce soit.

Je pense qu’en réseau, l’éloignement de la BDD avec le front/middle c’est le plus criant pour repérer une appli pourri, ça se ressent immédiatement niveau utilisateur.

Les choix d’architecture n’indiquent pas si l’appli est pourrie.
Entre avoir 9 postgresql qui tournent à 10% chacun, , et 1 postgresql qui tourne à 90% (grosse approximation), le cout en terme d’investissement est totalement différent (hors sauvegarde, SLA, HA…) et les contraintes d’exploitation sont différents.

Pareil pour les processus. Entre implémenter des requêtes atomiques ou implémenter des processus généraux, tout dépends des besoins et usages pour indiquer quels concepts à implémenter.
Parce qu’à l’inverse, travailler avec des resultset de plusieurs millions de lignes pour en modifier que quelques-uns, est tout aussi aberrant (quelqu’un parlait d’optimisation de ressources?)
Des jointures pour filtrer la dite table est aussi couteux en perf de bdd.

C’est l’architecte logiciel qui doit identifier les impacts en performaces et proposer des solutions.
Si ça se trouve, dans le contexte de l’application, il aurait fallu avoir des To de ram pour stocker ces resultsets en mémoire… (multithreading, etc…)

Pas de règle général donc, même si dans l’absolu, je suis d’accord, la bdd ne doit pas être loin (plus facile pour isoler un SI d’un autre, moins de contraintes bout en bout dans le SI), mais des contraintes organisationnelles (au moins en termes d’investissement) peuvent être présentes.

Fabimaru Abonné

Le 22/12/2021 à 11h55

#46

Suite à ce fiasco, j’ai exigé et obtenu le remboursement intégral de nos licences log4j

Ayant longtemps été dev C++, j’ai une appréciation positive de la sécurité en Java, étant donné que ça a enlevé la classe de problèmes les plus chiants du C++: la gestion de la mémoire (dépassements de tableaux, utilisation après libération…) qui non-seulement sont-pénibles à investiguer, mais un gros risque. Je préfère un dev peu consciencieux en Java qu’en C++.

Par chez moi, nos softs sont basés sur de l’opensource, et si on devait tout mettre à jour tout le temps il faudrait des gens dédiés à longueur d’année, donc on met à jour que pour la sécu ou les bugs visibles.

Baldurien Abonné

Le 22/12/2021 à 12h30

#47

(quote:1919188:Zone démilitarisée)
IBM WebSphere MQ est une bibliothèque.

Le mot français pour library est bibliothèque, que la licence de celle-ci soit gratuite ou payante. En néerlandais on dit bibliotheek, en espagnol biblioteca, en polonais biblioteka, en portugais biblioteca, en russe библиотека, etc. En allemand on dit Bibliothek ou Library, et en italien on dit biblioteca ou libreria.

Le mot anglais pour librairie est bookshop.

Je vais devoir expliquer la blague : une bibliothèque, tu empruntes, une librairie tu achètes. :)

Citan666 a dit:

Donc tu fais trois fois la même requête pour des usages différents qui peuvent tous exploiter le jeu de données de ta première requête ? Non seulement je ne vois pas le rapport avec une éventuelle fuite mémoire, mais je trouve que c’est au contraire l’exemple parfait de la contre-efficacité…

S’pas comme ça que tu vas lutter contre la réputation de lenteur de Java, à laquelle je souscris sans faille : les solutions logicielles Java que j’utilise, notamment Confluence et Jira pour pas les citer, demandent toutes des ressources minimales largement plus conséquentes par rapport à leur périmètre fonctionnel si on projette une réalisation similaire dans d’autres langages. Après c’est peut-être propre aux applications web. J’utilise peu de solutions “desktop” (à part LibreOffice, mais mon usage est tellement basique que pour le coup c’est bien fluide ^^).

Je me demande quand même si pour Confluence, JIRA et Bamboo (histoire de compléter) ce n’est pas lié à une problématique de coûts : tu paies cela en fonction du nombre d’utilisateurs et ça ne m’étonnerai pas que tu paies aussi en fonction du nombre de processeurs/RAM/etc.

Aussi, j’imagine que ce sont des solutions installées manuellement et dont les configurations ne sont pas forcément mise en phase avec l’utilisation. Les nouvelles licences JIRA passent en mode Cloud si j’ai bien compris, et donc plus d’installation on premise. Pour le meilleur ou pour le pire, va savoir :)

Ceci étant dit, je pense que la partie front - en HTML + Javascript - est quand même bien bugguée et source des lenteurs : sur Firefox, pour éditer une page confluence, ça revenait à chaque fois en début de page. En passant à Edge/Chrome, pas le problème, mais par contre ça laggait sévère pour éditer le document.
J’ai fini par utiliser un éditeur texte.

(quote:1919194:bidou.bidou)
Du point de vue de l’administrateur système et réseau, le problème du java c’est que, trop souvent, on a juste un .jar, .war ou un truc java web start. Pas de source, pas de mise à jour (où hors de portée de nos moyens financiers), pour savoir les dépendances incluses, on peut toujours partir à la pêche, mais de toutes façons on ne pourra pas les mettre à jour. C’est souvent très dépendant de la version de java (voire de si on prend l’implémentation libre ou le binaire fourni par Oracle). Oracle facture désormais très cher quand on a besoin d’une vieille version, et en plus ça engendre plein de failles de sécurité. Les applet java ont été abandonnées, puis le java web start, du coup on se retrouve sans vraie solution de secours. Sans doute faute d’expérience en java, je trouve souvent plus simple de faire tourner de vieux binaires en reconstituant les librairies dépendantes que d’arriver à faire tourner de vieux logiciels java.

Bon, les applis en php qui passent mal d’une version à l’autre c’est aussi très courant, mais sauf obfuscation on arrive généralement à s’en tirer.

A mon avis, ton problème c’est une différence entre avoir le code source (donc open source) et avoir un binaire (donc boite noire).

Tu prends PHP en exemple, mais je ne pense pas que tu te sois amusé à recompiler PHP, probablement une installation via ton système (apt get php, etc). Sachant que tu n’as aucune garanties que le code binaire corresponde à son code source (*)

A mon avis, le problème que tu as - de ne pas avoir le code source - c’est que tu ne peux pas lancer d’audit interne de sécurité.

(*) je sais qu’il existe https://reproducible-builds.org/ mais je ne sais pas si tu peux “marquer” un binaire pour le rattacher à son code source et son environnement de compilation.

Zone démilitarisée

Le 22/12/2021 à 14h02

#47.1

Citan Abonné

Le 22/12/2021 à 16h08

#47.2

Solutions Atlassian toujours utilisées en mode “serveur at home”. Ce qui a d’ailleurs bien dégoûté le Ministère où je travaillais qui ont acheté des licences pour plusieurs milliers d’utilisateurs avant d’apprendre le changement drastique de politique d’Atlassian en mode “allezzz, venez vous faire tenir par les couilles, promis notre étau n’est qu’en acier zyngué à pressoir automatique 10000 bars”.

(Ils étaient déjà assez loin de l’état d’esprit des premières années depuis qu’ils sont devenus les ténors du marché, mais ce tacle à la gorge qu’ils ont fait à toute leur communauté, m’est avis que ça va leur revenir dans la gueule vitesse grand v. Y’a aucun concurrent au niveau en mode “fonctionnalités sur étagère” mais entre payer plein pot en s’enfermant et partir sur une solution concurrente quitte à payer du dev interne/externe pour configurer et enrichir… Je pense vraiment que la majorité préfèrera la deuxième option)

Inodemus

Le 22/12/2021 à 12h45

#48

Citan666 a dit:

Donc tu fais trois fois la même requête pour des usages différents qui peuvent tous exploiter le jeu de données de ta première requête ? Non seulement je ne vois pas le rapport avec une éventuelle fuite mémoire, mais je trouve que c’est au contraire l’exemple parfait de la contre-efficacité…

C’est justement ce que j’ai compris qu’il voulait montrer, vu qu’il parlait de code dégueu juste avant. Il a donné une exemple de code dégueu et inefficace à souhait, et a dit qu’au moins, le fait d’écrire une horreur pareille en Java ne provoque pas de fuite mémoire.

Car un développeur capable de produire ça et qui le ferait en C++ aurait certainement oublié de libérer la mémoire de 2 requêtes sur les 3. Après de toute façon un développeur C++ aussi peu rigoureux n’aurait aucune chance de survie, mais on peut trouver des cas moins extrêmes.

Sa conclusion est donc que la réputation de lenteur de Java vient du fait qu’on peut faire du code dégueu avec sans que ça plante, et donc qu’il y a forcément une plus grande proportion de code dégueu et lent en Java que dans d’autres langages. Surtout auparavant, car maintenant il y a d’autres langages encore plus simples pour faire des horreurs.

Après le Java reste lent par rapport au C/C++ et maintenant Rust, et face au C# dans une moindre mesure. Mais c’est sûr que vu la montée du Javascript, et encore pire, du Python, aujourd’hui on ne peut plus considérer Java comme lent globalement, pas parce qu’il serait devenu plus rapide, mais surtout parce que le reste autour est devenu (beaucoup !) plus lent.

YonX

Le 22/12/2021 à 14h54

#48.1

+1.

Et en ce qui concerne la lenteur et la consommation de Java. C’est un choix d’archi a faire au lancement du projet.

Payer un bon Dev C/C++ et valider que le code est clean est bien plus cher (le temps c’est de l’argent) que d’acheter un nouveau server à 10k€ à ajouter une bonne fois pour toute dans un DC.

Pour de l’embarqué Java c’est pas fait pour, oui je connais Javacard et non merci.
Pour du service, dans des boites qui ont leur propre DC. C’est moins cher, ça fonctionne bien, ça se monitor facilement.
Le conteneur docker minimal dans mon ancienne mission avais 1vCPU et 512mo de RAM. Pour un petit service c’est énorme, dans un SI avec 400+ applications en 2sites 2colonnes avec 20% des server un backup c’est une goutte d’eau.

Citan Abonné

Le 22/12/2021 à 16h10

#48.2

Aaaah ok je comprends mieux. Merci pour l’explication. Je trouve son exemple un peu capillo-tracté quand même, mais pour avoir connu un “développeur expert” qui faisait des trucs encore pire que moi je faisais en tant qu’amateur, je suis obligé de reconnaître que c’est du domaine du possible (j’hésite entre et d’ailleurs)

Au passage… “il y a forcément une plus grande proportion de code dégueu et lent en Java que dans d’autres langages.”
Ce qui peut aussi simplement s’expliquer par le plus grand “volume” de code et de développeurs sur ce langage overall, non ?

Je m’aventure peut-être, n’ayant aucune source à fournir sur ce sujet, mais c’est vaguement l’impression que ça donnait…

“C’est du code que les devs ont livré en prod”.
Eh beh… Mes condoléances, y’a des coups de pied du cul au crâne qui se perdent…

iFrancois Abonné

Le 22/12/2021 à 13h21

#49

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

Ah nan même pas spécialement les failles, juste le langage en lui-même que je trouve absolument atroce, sans parler de l’environnement de développement et des frameworks.

En tout cas avec tous mes softs en .Net Core (voire .Net 6) je dors sur mes deux oreilles

spidermoon

Le 22/12/2021 à 13h48

#50

Aucun de nos serveurs, que ce soit dev, qualif ou prod n’a accès à internet, et seul les ports apache tomcat et sgbs sont autorisés en entrée, après avoir fait une demande d’ouverture de flux, accordée automatiquement si le flux est sur liste blanche, sur autorisation pour les flux gris et refusé pour les flux noir.
Donc même avec la faille, impossible d’aller chercher une charge utile sur un serveur externe.

Freeben666 Abonné

Le 22/12/2021 à 13h59

#51

Ne pas oublier que ce vecteur d’attaque est connu depuis plus de 5 ans… C’est juste la découverte de la mauvaise configuration de sécurité de base dans Log4j qui est récente.

https://www.youtube.com/watch?v=Y8a5nB-vy78

Catégories

Nous suivre

À propos

Log4shell : les jours d’après

Log4J, c’est quoi ?

Version 1 et version 2

JNDI et lookup

Log4shell : LA faille (avant LES failles)

Pourquoi c’est si grave

Et après ? Ça continue ?

Une faille puis des failles vite corrigées mais très vite exploitées

Quelles sont les versions touchées et quelles solutions ?

On en a fini ?

Sommaire de l'article

Introduction

Log4J, c’est quoi ?

Version 1 et version 2

JNDI et lookup

Log4shell : LA faille (avant LES failles)

Pourquoi c’est si grave

Et après ? Ça continue ?

Une faille puis des failles vite corrigées mais très vite exploitées

Quelles sont les versions touchées et quelles solutions ?

On en a fini ?

#Flock freeze l’optimisme

Sites pornos : l’Arcom va permettre un test temporaire du contrôle d’âge avec carte bancaire

AMD fait le plein de nouveautés : EPYC 9005, Ryzen AI « PRO » et Instinct MI325X castré

Le président de Google EMEA annonce son intention de quitter l’entreprise

États-Unis : de la surveillance des plaques d’immatriculation à celle des slogans politiques

À peine créé, l’Appeals Centre Europe déjà critiqué pour ses liens avec Meta

Xbox va bientôt vendre ses jeux sur Android

Core Ultra 200S : Intel présente ses nouveaux processeurs desktop, dès 294 dollars

Avec son Robotaxi, Tesla mise gros sur la conduite autonome

OpenAI ne prévoit pas d’être rentable avant 2029

Commentaires (139)