Discussion :

[Katleen Erna]

Des vulnérabiltés découvertes dans Java, déjà patchées par Oracle

Le CERTA (Centre d'Expertise Gouvernemental de
Réponse et de Traitement des Attaques informatiques) vient d'émettre un avis de sécurité révelant la présence de vulnérabilités dans la machine virtuelle Oracle Java (appelée ainsi depuis le récent rachat de Sun Microsystems par Oracle).

D'après le document officiel de l'alerte, les vulnérabilités sont :

- Une erreur dans le code de la classe HeadspaceSoundbank peut provoquer un débordement de mémoire par le biais d'un fichier Soundbank spécialement conçu ;
- Une erreur dans le traitement des images peut provoquer un débordement de mémoire par le biais d'une applet Java spécialement conçue ;
- Plusieurs autres vulnérabilités non précisées sont présentes dans les composants Oracle Java.

Ces failles pourraient permettre l'exécution à distance d'un code malveillant ou bien ouvrir une porte à une attaque par déni de service. Les données confidentielles ne sont donc plus protégées de manière optimale.

Les JVM impactées sont:
- Java SE, JDK/JRE 6 Update 18 et antérieures pour Windows, Solaris, et Linux ;
- Java SE, JDK 5.0 Update 23 et antérieures pour Solaris ;
- Java SE, SDK 1.4.2_25 et antérieures pour Solaris ;
- Java for Business, JDK/JRE 6 Update 18 et antérieures pour Windows, Solaris, et Linux ;
- Java for Business, JDK/JRE 5.0 Update 23 et antérieures pour Windows, Solaris, et Linux ;
- Java for Business, SDK/JRE 1.4.2_25 et antérieures pour Windows, Solaris, et Linux.

Ces informations ont été confirmées par Oracle qui propose des mises à jour de sécurité à cette adresse.

Source : L'alerte du CERTA

[jaimepaslesmodozélés]

Bonsoir,

étrange de publier une alerte de sécurité sur une version déjà patchée depuis quelques jours (j'ai fais la mise à jour fin mars, et l'alerte date du 1er avril, c'est dire)
En gros les mecs du Certa ont fait un bête copier/coller du rapport d'Oracle. Enfin bon, c'est le Certa hein.

Quand au nom de la machine virtuelle java, c'était et c'est toujours la Java HotSpot (version de Sun, à ne pas confondre avec celle d'Oracle : JRockit). Le "Oracle Java" est juste un nom... issu de l'imagination des gars du Certa ^^.

Ce que je retiendrais de cette news est surtout la nécessité, pour le grand public, de se débarrasser de la JVM 1.5 (Java 5) pour passer à la 1.6 (Java 6), les mises à jour de la 1.5 étant seulement dispo via le programme Java For Business.
Rhalala, si seulement ça pouvait vraiment arriver...

[_skip]

J'aimerai déjà que nos clients arrêtent avec les 1.4, ce serait déjà bien.

[Uncle Dave]

Bonsoir,

étrange de publier une alerte de sécurité sur une version déjà patchée depuis quelques jours (j'ai fais la mise à jour fin mars, et l'alerte date du 1er avril, c'est dire)
En gros les mecs du Certa ont fait un bête copier/coller du rapport d'Oracle. Enfin bon, c'est le Certa hein.

Normal, le CERTA publie les failles qu'il détecte ainsi que les failles que les éditeurs publie, la mission du CERTA n'est pas tant de détecté les failles de sécu que de les lister, les référencer, indiquer les solutions et les faire appliquer aux systèmes informatique du ministère de la défense

Grosso modo, les avis CERTA c'est la pile des tâches de sécu à traiter par les chef de projet du MINDEF.

[Lyche]

J'aimerai déjà que nos clients arrêtent avec les 1.4, ce serait déjà bien.

Même principe qu'avec IE6.. beaucoup d'applications sont développées sous 1.4 ce qui rend réticentes les entreprises à passer le cap :/

[dams78]

J'aimerai déjà que nos clients arrêtent avec les 1.4, ce serait déjà bien.

+1

[_skip]

Ben oui le problème c'est que ce sont des grosses usines à gaz qui ont été validées dans un environnement 1.4 et un serveur d'application donné, que personne n'ose toucher.

Ils attendront d'être assis, le dos au mur pour retoucher à ces infrastructures car il est impossible de savoir si ça fonctionnerait à 100% après une migration vers un couple serveur-JVM plus récent. Ca demanderait tout un cycle de validation onéreux en temps, ça pourrait créer des situations dont personne ne veut assumer la responsabilité, résultat c'est comme ça depuis 10 ans, et peut être encore identique dans 10.

[CastorJoyeux]

et peut être encore identique dans 10.

8 ans je te prie


Java 1.4 pour buisness est supporté jusque Avril 2018, après, fini les update, si on change de règles pour le passage heure d'été heure d'hiver chez le moindre de leur client, ils l'auront dans le baba . Ceci dit, sun a promis 15 ans de support sur les versions java via leur programme buisness, il est donc assez logique que ces "usine à gaz" puissent ce reposer sur ce délai, y a pas d'urgence pour eux d'en changer.

[_skip]

Bien vu.
Mais je suis même pas sûr que les entreprises dont je parle ait souscrit un plan de support car j'en vois tourner dans une toute vieille release de 1.4 .

[jaimepaslesmodozélés]

Ajoutons que nombre de failles sont exploitables via des applis desktop ou en tant que plugin d'un navigateur, et non dans le cadre d'un serveur d'application type Websphere & co où les opérations sont quand même largement plus contrôlées et maîtrisées .
Rien que pour ça une install 1.4 reste viable (même si avec cette mentalité on passe à côté de gains importants en terme de performances).

[CastorJoyeux]

Il n'y a pas que des mises à jour de sécurité dans les vieilles versions. Il y a aussi les mise à jour de tout ce qui concerne les Locale, les Timezone et les Calendrier. Il se passe pas une année sans qu'un pays dans le monde quelque part décide de changer le moment où il switche entre l'heure d'été et l'heure d'hiver. Ce qui peut poser des problèmes dans des grosses appli qui gèrent des centres de distribution de courrier, par exemple. Ces mises à jour sont donc importantes à ce titre. Il y a aussi le risqe, si le serveur agé de 10 ans tombe en panne, qu'il faille le remplacer par un serveur plus récent pour lequel on ne trouve plus de jvm 1.4 sans devoir la payer à sun (oracle) :p

Bien sur c'est à gérer au cas par cas et il est difficile de jeter la pierre à une société juste parce qu'elle préfère conserver des bases fiable plutot que d'investir dans un systémèe théoriquement meilleur mais pas encore testé

[ymajoros]

Je ne sais vraiment pas comment développer du code en java 1.4 qui ne tournera pas en 1.6, je devrais fort me creuser la cervelle pour trouver. Après, si on ne peut pas valider une mise à jour de la jvm, faut se poser la question de savoir si on peut faire confiance au vieux code qu'on ne peut plus valider.

Avec toutes les mises à jour qu'il y a eu depuis, il y a fort à parier qu'il y a un tas de problèmes connus avec le code qui tourne en 1.4. Une mise à jour vers une version récente, c'est échanger des problèmes connus contre des risques. Si on ne peut pas se le permettre, on n'a vraiment pas de garanties sur ce qui continue à tourner sans mise à jour.

[CastorJoyeux]

tout dépend si on a des problèmes connus avec l'application en cours


Et passer de java 1.4 à java 6 n'est pas aussi immédiat que ça. Même si sun garde la compatibilité, y a tout une série de choses qui on changé de comportement et il est tout a fait possible d'avoir un code qui donne les résultats voulu en 1.4 mais pas en 6, suffit que le code se base sur un des nombreux effets de bord d'une classe qui ont été corrigés

[_skip]

Même si ce n'est pas la réponse à tout, ça souligne encore l'importance d'une bonne batterie de tests unitaires...

[jaimepaslesmodozélés]

+1 pour les tests unitaires. A condition d'en avoir :p

@ymajoros : pour faire du code version N qui ne passe pas en version N+1 (ou plus), il suffit de regarder la bonne vieille Javadoc, les incompatibilités y sont soigneusement consignées (exemple de Java6 : http://java.sun.com/javase/6/webnote...atibility.html)
Après oui, ce n'est pas tout le monde qui va tomber dessus.

[jkakim]

Vous étés plutôt fanatique que ouvert... jusqu'à détourner la discussion !

[jaimepaslesmodozélés]

@CastorJoyeux
pour le coup des timezones à mettre à jour, l'utilitaire de mise à jour desdits timezones est toujours dispo et mis à jour, et fonctionne avec les JVM 1.4+