Discussion :

[Stéphane le calme]

Les utilisateurs de Java 6 s'exposent à un exploit zero day,
les experts recommandent de migrer vers Java 7

De nombreux experts en sécurité s’accordent à dire que les entreprises devraient migrer vers Java 7. En effet, Timo Hirvonen, analyste senior chez F-Secure, a reporté que le code d’un exploit d’une vulnérabilité précédemment corrigée a été introduit dans le kit de l’exploit Neutrino, le trojan bancaire dont l’architecture rappelle celle de Zeus. « Un hacker peut exécuter du code sur le système et l’infecter d’un malware. Vous pourriez obtenir un lien dans vos spams qui vous conduirait au kit Neutrino ou vous ferait visiter des sites infectés » confie-t-il.

La vulnérabilité CVE-2013-2463, a été corrigée en juin dernier lorsqu’Oracle a publié son plus récent Critical Patch Update pour Java 7 Update 25. Le CVE révèle la présence de la vulnérabilité dans les versions antérieures à Java SE 6 Update 45 qui permettrait aux hackers d’affecter la confidentialité, l’intégrité et la disponibilité via des vecteurs inconnus liés à 2D.

Pour Adam Gowdiak de Security Explorations, « la faille exploitée est assez sérieuse puisqu’une corruption de la mémoire peut généralement entraîner une compromission complète de la sécurité Java. ». Il rejoint la cohorte des experts qui encouragent la migration vers Java 7.

Wolfgang Kandek, le responsable technologique chez la firme de sécurité Qualys, affirme quant à lui que « dans son essence, il s’agit d’une vulnérabilité zéro day implicite mais dont nous n’avons pas le correctif sous la main. Nous observons que Java 6 est encore installé à des taux très élevés comptant pour un peu plus de la moitié des utilisateurs Java, ce qui veut dire que de nombreuses organisations sont vulnérables. Les entreprises devraient migrer vers Java 7 aussi vite que possible. »

Rappelons qu’Oracle a suspendu les mises à jour gratuites sur Java 6 ; ceux qui voudraient installer la version la plus récente Java 6 Update 51 vont donc devoir mettre la main à la poche.

Sources : blog Qualys, Oracle, CVE

Et vous ?

Qu'en pensez-vous ?

[Spleeen]

Et la migration vers un autre langage c'est pour quand ?

[LSMetag]

Oracle est littéralement en train de couler Java... C'est malheureux.

[berceker united]

Désinstallé depuis quelque mois vu que j'en ai clairement pas l'utilité. Trop de problème de ce genre. Pourquoi garder une VM ayant éventuellement des problèmes de sécurité si vous ne l'utilisez pas.

[nacrotic]

Apres open Office, Oracle s'efforce de faire couler Java ... et ils sont sur la bonne voie. Apres on passe à MySQL ?

[guillaume07]

c++ et c# s'impose désormais comme les deux seuls langage mainstream

[ryann]

Est-ce que toutes ces failles existaient avant 2009 et le rachat de Sun par Oracle ?

Et est-ce qu'elles ont pu être exploitées en toute impunité pendant toutes ces années ?

En gros, est-ce qu'il y a des configurations à risque - os + navigateurs.

[LSMetag]

c++ et c# s'impose désormais comme les deux seuls langage mainstream

N'oublie pas PHP non plus ^^.

Mais c'est vrai que depuis l'aquisition par Oracle, on assiste à un enchaînement de failles de sécurité, à un manque d'écoute des développeurs, et une politique commerciale sur un langage à la base libre et open source.

De quoi définitivement écarter le développeur que je suis de Java, que j'utilisais encore il n'y a pas si longtemps.

Avec .NET, certes on paye (et encore, pas forcément en utilisant les version Express des IDE ou SharpDevelop), mais la qualité de service est là.

Sur Java, depuis Oracle, on a l'impression d'avoir un travail d'amateurs arrogants. Et comme Java a été industrialisé, les cycles de développement ont été rigidifiés. "Une faille critique 0 days exploitée ? Bon ben on va voir si ça tient dans le planning de la prochaine version qui sort dans 3 mois..."

[Uther]

Et la migration vers un autre langage c'est pour quand ?

c++ et c# s'impose désormais comme les deux seuls langage mainstream

Ces remarques n'ont pas de sens.

C'est l'utilisation de java sous forme d'applet ou des outils similaires comme Java Web Start qui pose problème. Ce n'est juste pas comparable à d'autres langages, vu qu'ils ne permettent pas de faire l'équivalent.
En tant que langage de programmation, Java n'est pas moins sur à programmer que le C# et il l'est beaucoup plus que C++.

Enfin, de ce que je peux constater, Java n'est clairement pas en voie de disparition bien au contraire.

[icexplorer]

Ces remarques n'ont pas de sens.

C'est l'utilisation de java sous forme d'applet ou des outils similaires comme Java Web Start qui pose problème. Ce n'est juste pas comparable à d'autres langages, vu qu'ils ne permettent pas de faire l'équivalent.
En tant que langage de programmation, Java n'est pas moins sur à programmer que le C# et il l'est beaucoup plus que C++.

Enfin, de ce que je peux constater, Java n'est clairement pas en voie de disparition bien au contraire.

Je plussoie, d'autant plus qu'actuellement le java se dirige de plus en plus pour les développements côté serveur (les clients légers on en voit de moins en moins, les applets n'en parlons pas).

Sinon conseil pour les étudiants, avant de dire des anneries allez faire un tour du côté des offres d'emploi pour constater quels sont les langages "mainstream"...

[LSMetag]

Ces remarques n'ont pas de sens.

C'est l'utilisation de java sous forme d'applet ou des outils similaires comme Java Web Start qui pose problème. Ce n'est juste pas comparable à d'autres langages, vu qu'ils ne permettent pas de faire l'équivalent.
En tant que langage de programmation, Java n'est pas moins sur à programmer que le C# et il l'est beaucoup plus que C++.

Enfin, de ce que je peux constater, Java n'est clairement pas en voie de disparition bien au contraire.

Cessons un peu la mauvaise foi. Vous dites souvent "oui mais ça ne concerne que les applets et JWS" ou "Java n'est pas fait pour faire du web".

Je regrette mais si Oracle multiplie les failles de sécurité dans des outils que Java propose depuis longtemps, il n'a pas d'excuse. Java a des outils pour le Web qui sont susceptibles d'être utilisés puisque disponibles. Il n'y a que vous qui décrétez que Java n'est pas fait pour faire du Web, pas ses développeurs.

De nombreux sites sont pourvus d'Applets (JWS est plus rare). Et pendant qu'Oracle respecte tranquillement ses cycles de développement, beaucoup d'Applets sont consultées. Parfois des failles signalées plus d'un an plus tôt ne sont toujours pas à l'ordre du jour niveau correction.

En .NET, on a l'équivalent avec WPF, qui permet de faire des sortes d'applets, et le défunt Silverlight. Pour des outils similaires, on a beaucoup moins de failles signalées. Après est-ce parce que les experts ne se concentrent que sur Java ? Et concernant Javascript, les failles proviennent du développeur.

Expliquez-moi pourquoi Oracle a décidé de retarder Java 8 d'un an pour corriger Java 7 ? N'est-ce pas un aveu d'erreur ?

Avant le rachat de Sun par Oracle, on entendait peu parler de problèmes de sécurité. Avec Java 7 et la fin de Java 6, ça a été l'explosion.

[icexplorer]

@LSMetag : tu confonds certaines choses...

Ce que je dis n'engage que moi mais mettons les choses au clair.

Personne ne dit que "Java n'est pas fait pour faire du web", au contraire, il est fait pour le web, et le développement du langage est clairement dirigé de ce côté. Côté serveur hein...

En revanche il n'est pas fait (ou plutôt mal fait) pour le web côté client (applets...). Mais honnêtement, quels sont ces "nombreux" sites qui les utilisent encore aujourd'hui ? Le site des impôts peut-être ? Ensuite ?

Concernant les failles de sécurité il est normal qu'ils retardent la sortie de java 8, microsoft avait eu le même problème avec windows xp sp2 à l'époque (qui a fait retarder vista...) je ne vois pas en quoi c'est choquant.

Et ne va pas croire qu'avec Sun il y avait moins de failles, puisque c'est généralement le code ancien qui est touché (développé chez Sun), qui par extension touche aussi les nouvelles versions.
A mon avis si ces failles font surface maintenant, c'est surtout une histoire de gros sous, mais bon c'est une autre histoire...

[LSMetag]

@icexplorer

Oui mais faire du Java côté serveur dépend de serveurs d'application qui sont finalement des applications tierces.

Tandis que le web client est inclus dans Java de base.

Oui je vois des chats IRC en ligne fonctionnant en applets java, des sites scientifiques avec des applets java pour les graphiques et les simulations, le site des impôts en effet (cible de choix) et d'autres que j'ai vu passer mais oublié...

Beaucoup de failles de sécurité ont été levées sous Java 7. Alors étaient-elles déja là avant ou pas ?

Il y a quelques années j'avais fait un petit jeu en 3D (JOGL) en utilisant ce modèle :

http://www.avengina.org/?target=itp

Pareil je songeais à utiliser JOGL de cette manière pour faire des visualisations 3D, à buts industriels ou commerciaux. Je ne peux désormais plus envisager ce genre de solution avec Java.

[Uther]

Nous relevions juste que le langage Java n'était pas mort, loin de là.

Maintenant, Java en tant qu'applet est il est vrai sur le point de disparaitre, mais le mouvement avait déjà commencé bien avant les failles de sécurités à répétitions. Aujourd'hui, JavaScript permet de faire quasiment tout ce que les applet java permettent de faire sans dépendance a installer coté client.
Et le peu qui manque est en train d'arriver avec les dernières API "HTML5"

[cryo94]

Je regrette mais si Oracle multiplie les failles de sécurité dans des outils que Java propose depuis longtemps, il n'a pas d'excuse. Java a des outils pour le Web qui sont susceptibles d'être utilisés puisque disponibles.

De nombreux sites sont pourvus d'Applets (JWS est plus rare). Et pendant qu'Oracle respecte tranquillement ses cycles de développement, beaucoup d'Applets sont consultées. Parfois des failles signalées plus d'un an plus tôt ne sont toujours pas à l'ordre du jour niveau correction.

Oui c'est vrais que si java propose des solutions comme les applets, etc, c'est que c'est fait pour être utilisé.

Mais Java c'est aussi un historique embarqué dans les nouvelles versions.
Historique qui permet de faire de l'ancien malgrès la jeunesse du JDK / JRE téléchargé.

Une application qui a 6 ans de vie ou plus a ses raisons d'avoir des applets. Je n'en vois vraiement pas beaucoup pour un nouveau développement.
C'est comme si , au jour d'aujourd'hui, une personne commencait un nouveau projet avec du php 3 tout en pestant qu'il n'y a quasiment plus de maintenance pour les bugs identifiés dans cette version majeure...

Avant le rachat de Sun par Oracle, on entendait peu parler de problèmes de sécurité. Avec Java 7 et la fin de Java 6, ça a été l'explosion.

Mais c'est vrai que depuis l'aquisition par Oracle, on assiste à un enchaînement de failles de sécurité, à un manque d'écoute des développeurs, et une politique commerciale sur un langage à la base libre et open source.

Une situation merdique ne se fait pas en un jour.
Alors une question dont je n'ai pas la réponse : Est-ce Oracle qui a des dévelopeurs arrogants pourri gatés qui codent n'importe comment et ils sont obligés de faire des patches tout les jours pour corriger ce qu'il font... ou ont-il hérité d'une solution avec des failles qu'ils corrigent de la meilleure façon qu'il peuvent ?

En tout cas communiquer des bugs n'est pas un aveux de faiblesse, je le vois surtout comme un acte responsable dans un environnement où tout les langages se font la guerre. Après chacun prend les décisions en fonction de la façon de voir midi à sa porte.

[Uther]

Heu le côté client en java est loin d'être ridicule si tu prend en compte tout l'éco systeme java ! Des framework comme JSF (+ Primefaces / PrettyFaces / RichFaces) , Struts 2, GWT, ... coté client le language n'est pas trop mal équipé

Tout ce que tu viens de citer c'est des technologies coté serveur.

La seule chose qui évolue encore coté client, c'est JavaFX, mais il peine clairement à décoller.

[cryo94]

Tout ce que tu viens de citer c'est des technologies coté serveur.

La seule chose qui évolue encore coté client, c'est JavaFX, mais il peine clairement à décoller.

Meaculpa je pensais qu'on parlait rendu généré pour le client !
Oui vu comme ca c'est vrais que nous ne sommes pauvre en techno

[Mishulyna]

Avant le rachat de Sun par Oracle, on entendait peu parler de problèmes de sécurité. Avec Java 7 et la fin de Java 6, ça a été l'explosion.

Avant le rachat de Sun par Oracle, Linux était un OS sûr à 100% (pas de virus, trojan, inexpugnable quoi!) ce qui n'est plus le cas maintenant. Je ne dirais pas qu'il n'y avait pas de faille mais trop peu de gens capables de les découvrir et exploiter. Tandis que de nos jours...

Il y a encore des entreprises qui utilisent Java 6? Enfin, c'est une question rhétorique, il me semble avoir lu quelque part qu'il existe toujours des entreprises qui utilisent Windows XP.

[Mishulyna]

Pourquoi garder une VM ayant éventuellement des problèmes de sécurité si vous ne l'utilisez pas.

A moins que l'on est un développeur Java web et on l'utilise à fond...

[Gugelhupf]

Il y a encore des entreprises qui utilisent Java 6?

Oui, il y a encore des entreprises qui utilisent Java 6 (ou qui viennent à peine de migrer vers Java 6), et mêmes des universités qui enseignent avec pour restriction Java 6 (TP et projets étudiants).
Je connais aussi un enseignant qui refuse de passer à Java 7 car la JVM "plante" et serait "rempli de failles"...

La migration possède toujours un "coût". Pour les entreprises c'est :

• Quels seront les changements après migration qui pourront nuire à l'expérience de l'utilisateur ? (changement interface, même une simple icône, l'ergonomie...)
• Combien de temps va prendre la nouvelle mise en production ?
• Combien de ressources seront nécessaires ?
• Est-ce que du nouveau matériel ou licence logiciel sera nécessaire ?
• Est-ce que le budget accordé sera suffisant ?
• ...

Bien sur, d'apparence rien ne va changer (ou peu), alors pourquoi investir du temps et de l'argent ?

Pour les universités c'est pas si différent, les enseignants ne maitrisent pas tous Java 7 (même s'il n'y a pas de gros changements), il y a tout un parc à migrer, des cours à modifier.