Developpez.com

Le Club des Développeurs et IT Pro

Java : correction de 19 vulnérabilités et désactivation de SSL 3.0

Il n'y aura plus de mises à jour publiques pour la version 7

Le 2015-01-22 17:25:46, par Michael Guilloux, Chroniqueur Actualités
Oracle a publié de nouvelles mises à jour de sécurité pour Java afin de corriger 19 vulnérabilités et désactiver le support par défaut pour SSL 3.0, une version obsolète du protocole de communication sécurisé qui est vulnérable aux attaques.

Même si le nombre d'attaques qui exploitent les vulnérabilités de Java a été régulièrement en baisse au cours de la dernière année, les exploits Java restent parmi les principaux vecteurs d'attaque contre les utilisateurs du Web, selon le dernier rapport de sécurité de Cisco. Ces correctifs pourront donc limiter les attaques via les exploits Java.

Quatorze des 19 vulnérabilités corrigées dans Java affectent les déploiements des clients et peuvent être exploitées à partir de pages Web grâce à des applets Java malveillantes ou des applications Java Web Start. Quatre d'entre elles ont le score de sévérité maximale(10) dans le système de score de vulnérabilité commune (CVSS) et deux autres pouvant conduire à un compromis total du système sont de sévérité 9,3.

Les nouvelles mises à jour de sécurité permettent de corriger des vulnérabilités qui « vont de la lecture et l'écriture de données locales à la prise de contrôle totale du système d'exploitation, y compris l'exécution de code arbitraire », a déclaré John Matthew Holt, CTO de Waratek, la firme de sécurité d'applications Java, via e-mail.

Une des mises à jour de sécurité dans Java est la désactivation du protocole SSL 3.0 par défaut en réponse à la vulnérabilité de POODLE découverte en octobre. La faille permet, par des attaques de l'homme du milieu, de déchiffrer des informations sensibles comme les cookies d'authentification à partir d'une connexion chiffrée avec SSL 3.0.

POODLE a aussi affecté le protocole TLS à cause de la possibilité de forcer le passage à SSL 3.0 lorsque le client et le serveur supportent le protocole vieillissant.

Toutefois, si SSLv3 est absolument nécessaire, Oracle a indiqué dans les nouvelles de version de Java la possibilité de le réactiver.

Les versions nouvellement patchées de Java sont 5.0u81, 6u91, 7u75/7u76 et 8u31, mais les mises à jour de Java 5 et 6 ne sont disponibles que pour les clients d'Oracle avec des contrats de support à long terme.

Par ailleurs, c'est aussi la dernière mise à jour publique de sécurité pour Java 7. Les utilisateurs qui ont la mise à jour automatique activée seront migrés vers Java 8; et seuls les utilisateurs disposant de contrats de support à long terme seront en mesure de télécharger les prochains correctifs de sécurité de Java 7.

Source : Oracle CPU

Et vous ?

Qu’en pensez-vous ?
  Discussion forum
9 commentaires
  • ternel
    Expert éminent sénior
    C'est pourtant assez simple à comprendre.

    Les sociétés sont heureuses de ne pas devoir migrer leurs applications vers un java récent, minimisant leur coup de développement.
    Tant que le contrat de LTS est moins cher que la migration, elles sont contentes. (pas les développeurs, par contre )

    Du coup, pourquoi se priver de faire payer ce contrat?

    Par contre, s'ils font aussi payer pour les versions courantes, le langage cessera d'être utilisé, vu que d'autres seront gratuits, pour des fonctionnalités à peu près équivalentes.
    le 23/01/2015 à 13:15
  • adiGuba
    Expert éminent sénior
    Envoyé par Traroth2
    Une remarque qui n'est pas spécifique à Java : je trouve étrange que pouvoir accéder en toute sécurité à des anciennes versions d'un logiciel soit considéré comme un privilège qui nécessite un paiement. Que faut-il comprendre concernant les nouvelles versions ?
    Bah la maintenance d'un logiciel a un coût.
    Je ne vois rien d'extraordinaire à demander une compensation financière pour cela...

    a++
    le 23/01/2015 à 11:32
  • adiGuba
    Expert éminent sénior
    Envoyé par Traroth2
    Mis bizarrement, ils ne font payer que pour les anciennes versions...
    C'est normal car il est difficile de supporter plusieurs produits, qu'il soit gratuit ou pas.
    Donc les éditeurs ont tendance à mettre en avant la dernière version de leur produit, et poussent les gens à l'utiliser.

    Toutefois pour X raisons il y a beaucoup de boites qui ne veulent pas migrer vers les nouvelles versions, car cela peut impliquer pas mal de travail (et donc de l'argent).
    Et cela crée donc une demande pour avoir des mises à jours sur les anciennes versions...

    a++
    le 23/01/2015 à 13:31
  • thelvin
    Modérateur
    Envoyé par Traroth2
    En gros, l'imperfection logicielle devient un véritable business-model !
    L'imperfection de toute chose a toujours été un business model, l'idée étant qu'on trouve à peu près normal de payer plus que ce qu'on a déjà payé, pour obtenir mieux que ce qu'on a déjà.
    le 23/01/2015 à 14:45
  • Traroth2
    Membre émérite
    Une remarque qui n'est pas spécifique à Java : je trouve étrange que pouvoir accéder en toute sécurité à des anciennes versions d'un logiciel soit considéré comme un privilège qui nécessite un paiement. Que faut-il comprendre concernant les nouvelles versions ?

    J'ai l'impression qu'on s'achemine de plus en plus vers un monde informatique où les imperfections des produits commercialisés rapportent beaucoup d'argent. Tout le business de l'antivirus est basé là-dessus depuis longtemps, mais désormais, les mises à jour de sécurité pour les anciennes versions de Java ou de Windows, par exemple, qui ne sont nécessaires qu'à cause des défauts existants dans les versions précédentes, deviennent payantes. Et pourquoi est-ce qu'on continue à utiliser ces anciennes versions, en particulier pour Java (puisque les nouvelles versions sont gratuites) ? Parce que la compatibilité ascendante peut également présenter un risque. Là aussi, il s'agit d'une imperfection, ou du moins d'une possibilité d'imperfection. En gros, l'imperfection logicielle devient un véritable business-model !
    le 23/01/2015 à 10:49
  • Traroth2
    Membre émérite
    Envoyé par adiGuba
    Bah la maintenance d'un logiciel a un coût.
    Je ne vois rien d'extraordinaire à demander une compensation financière pour cela...

    a++
    Mis bizarrement, ils ne font payer que pour les anciennes versions...
    le 23/01/2015 à 12:31
  • hwoarang
    Membre chevronné
    Envoyé par Traroth2
    Parce que la compatibilité ascendante peut également présenter un risque. Là aussi, il s'agit d'une imperfection, ou du moins d'une possibilité d'imperfection. En gros, l'imperfection logicielle devient un véritable business-model !
    En meme temps, meme pour des objets physiques, c'est vrai. Il suffit d'aller dans un garage avec une voiture qui a quelques années et avant meme qu'on ait fini d'expliquer le probleme, le garagiste sait ce qu'il y a. Pourquoi ? Parce que c'est toujours la meme panne qui résulte d'un défaut de conception. Et on trouve normal de payer pour ca...

    Pour revenir à Java, il faut reconnaitre que maintenir la derniere version est normal. Maintenir les anciennes parait beaucoup moins évident. Donc, compte tenu du surcout, je trouve pas illogique de faire payer pour les evolutions. En tout cas, tant qu'on n'oblige pas à mettre à jour ces versions...
    le 23/01/2015 à 15:23
  • ymajoros
    Membre habitué
    Envoyé par leternel
    Les sociétés sont heureuses de ne pas devoir migrer leurs applications vers un java récent, minimisant leur coup de développement.
    En pratique, ne pas mettre à jour augmente la dette technique. Il faudra bien un jour faire la mise à jour. Le risque est lui quasi inexistant, avec une batterie de tests sérieuse, des déveoppeurs compétents et un java compatible arrière depuis toujours.

    J'ai vu des mises à jour de jvm foirer, elles rentraient toutes dans 2 catégories. La première : mise à jour majeure et outils qui manipulent directement les classes (dans serveur d'applications, etc.) sans que ces outils ne supportent la dernière version. C'est prévisible et maîtrisable. La deuxième : code tellement tordu qu'il n'aurait jamais dû être écrit, qui marche par hasard sur une version spécifique. Et c'est plus rare (quelques collectors). Des bugs avérés de la JVM introduits dans une nouvelle version et qui impacte vraiment du code ? Ça arrive, mais ça reste le plus souvent un fantasme. Le risque d'un upgrade de jvm est nettement inférieur au risque de ne pas le faire régulièrement.
    le 27/01/2015 à 15:45
  • Logan Mauzaize
    Rédacteur/Modérateur
    Envoyé par ymajoros
    En pratique, ne pas mettre à jour augmente la dette technique. Il faudra bien un jour faire la mise à jour. Le risque est lui quasi inexistant, avec une batterie de tests sérieuse, des déveoppeurs compétents et un java compatible arrière depuis toujours.
    Se rendre compte du risque et l'évaluer, ca se fait même sans une batterie de tests. Mais ca ne finance pas les modifications à apporter.

    Envoyé par ymajoros
    J'ai vu des mises à jour de jvm foirer, elles rentraient toutes dans 2 catégories. La première : mise à jour majeure et outils qui manipulent directement les classes (dans serveur d'applications, etc.) sans que ces outils ne supportent la dernière version. C'est prévisible et maîtrisable.
    Genre migrer de version de serveur d'application, changer de version de BCEL, etc. ? Prévisible et maitrisable oui. Assumable financièrement, c'est autre chose.

    Envoyé par ymajoros
    La deuxième : code tellement tordu qu'il n'aurait jamais dû être écrit, qui marche par hasard sur une version spécifique. Et c'est plus rare (quelques collectors). Des bugs avérés de la JVM introduits dans une nouvelle version et qui impacte vraiment du code ? Ça arrive, mais ça reste le plus souvent un fantasme. Le risque d'un upgrade de jvm est nettement inférieur au risque de ne pas le faire régulièrement.
    Pour ma part, je peux citer deux cas :
    • Nécessiter d'utiliser les API sun.*. Biensûr le risque était connu, mais entre rien et une fonctionnalité reposant sur un code non pérenne, le choix est rapide.
    • Changement d'implémentation des substring. Avant Java 7, le même tableau de char était réutilisé. Désormais il s'agit d'une vraie copie. L'impact sur les performances peut-être très important en fonction de ce que tu fais des chaines découpées et des sous-chaines.

    Il y eu pas mal de petits changements sous le capot entre Java 6 et 7 (à cause du passage à OpenJDK ?). Et il y a fort à parier qu'avec le remaniement des dépendances des packages de l'API (projet Jigsaw), il y aura surement beaucoup de modifs impactantes et surement invisibles dans un premier temps.
    le 30/01/2015 à 23:35
  Poster une réponse