Java : Oracle publie des correctifs d'urgence
Pour colmater les failles de sécurité critiques de la plateforme

0PARTAGES

1  0 
Après la découverte de deux failles de sécurité dans l’environnement Java exploitables via les plugins des navigateurs, la réponse d’Oracle ne s’est pas longtemps fait attendre. Oracle publie, encore une fois, un correctif d’urgence pour pallier le problème.

Les deux vulnérabilités affectent le composant 2D de Java SE. Elles ne s’appliquent pas cependant aux serveurs Java, aux applications de bureau Java ou aux applications embarquées Java. Elles n’affectent pas non plus le serveur Oracle.

Les failles sont utilisées en particulier pour injecter des « ransomware », des codes malveillants qui se propagent typiquement de la même manière que les vers informatiques. Les documents de l’utilisateur sont alors verrouillés et une demande de paiement est exigée en échange de la clé permettant de les déverrouiller.

La compagnie a prévu d’inclure un stabilisateur pour la faille de référence CVE-2013-1493 le 16 avril 2013 et recommande toutefois de garder les paramètres de sécurité de Java au plus haut niveau.

Java 7 Update 17 et Java 6 Update 43 sont disponibles en téléchargement ou peuvent être installés via les mises à jour automatiques.

Télécharger Java 7 Update 17 et Java 6 Update 43.

Source : Blog Oracle

Et vous ?

Pensez-vous que ce patch sera suffisant cette fois pour colmater les failles dans la sécurité de Java ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Hinault Romaric
Responsable .NET https://www.developpez.com
Le 06/03/2013 à 2:35
Citation Envoyé par la.lune Voir le message
Une heure après la publication de cet article Oracle a publié une mise à jour de sécurité, le Java 1.7 update 17. Mais cet article on se réfère d'une source qui parle de de java 1.7 update 15, donc une version avant l'avant-dernière version. L'essentiel mettez à jour vos systèmes.
http://www.oracle.com/technetwork/java/javase/downloads/index.html

A vrai dire si oracle continue dans ce sens il pourra sans doute colmater tous les fuites sur la sécurité dont sa machine virtuelle est exposé.
Java 7 update 15 est sortie dimanche dernier. Oracle est passé directement à Java 7 update 17, sans expliquer pourquoi.
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 06/03/2013 à 10:39
Citation Envoyé par Hinault Romaric Voir le message
Java 7 update 15 est sortie dimanche dernier. Oracle est passé directement à Java 7 update 17, sans expliquer pourquoi.
L'update 15 c'était le 19 février ! Mais, IMHO, la.lune faisait référence a ton lien Reuters qui date du 14 Janvier !

Il n'en reste pas moins qu'Oracle semble désormais réagir rapidement !

a+
Philippe
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 06/03/2013 à 10:56
Citation Envoyé par Eugène-Sam Voir le message

Pensez-vous que ce patch sera suffisant cette fois pour colmater les failles dans la sécurité de Java ?
Je ne joue pas aux devinettes.
Avatar de wax78
Modérateur https://www.developpez.com
Le 06/03/2013 à 11:03
Avatar de herve4
Membre habitué https://www.developpez.com
Le 06/03/2013 à 11:30
La notion d' "urgence" pour le correctif java est une notion plutôt relative, je trouve. La détection du problème ne date pas d'hier...

J' espère que ce correctif sera suffisant pour la suite des evenements...
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 06/03/2013 à 14:06
Citation Envoyé par herve4 Voir le message
La notion d' "urgence" pour le correctif java est une notion plutôt relative, je trouve. La détection du problème ne date pas d'hier...

J' espère que ce correctif sera suffisant pour la suite des evenements...
C'est clair hier le patch était déjà à disposition

Sur quoi tu te bases pour dire que les deux failles étaient connues par Oracle depuis longtemps ? De son côté Oracle indique que les problèmes lui ont été remontées début février ! Tu aurais souhaité qu'ils retardent la sortie du patch 15 qui corrigeait des failles dites activement exploitées ?

a+
Philippe
Avatar de danielhagnoul
Rédacteur https://www.developpez.com
Le 11/03/2013 à 0:13
Suite à une emmerde, j'ai viré Java à la poubelle il y a deux jours et je ne vois vraiment pas pourquoi je le réinstallerais. Si un logiciel ne peut pas fonctionner sans, tant pis.
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 13/03/2013 à 12:06
A partir de Java 1.7.0 u21 (prévu pour être publié en avril), les Applets devront être signées (par un certificat reconnu par une autorité) pour s'exécuter dans le navigateur de manière "confortable" pour l'utilisateur (oui je sais ce n'est pas très clair comme terme).

Si j'ai bien compris la FAQ en bas de l'article, les Applets non-signées afficheront un nombre plus important de boites de dialogues de sécurité et l'utilisateur pourra plus facilement terminer l'exécution d'un programme en cas de comportement dangereux.
De plus Oracle se réserver le droit de restreindre encore plus le mode d'exécution des applet "self-signed" (avec un certificat temporaire généré par le developpeur lui-même) ou non-signées dans les mises à jour suivantes.

Citation Envoyé par http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html
During the February 19, 2013 Java Critical Patch Update (CPU)1, Oracle announced it’s intentions to deliver a new April 16, 2013 Java CPU release, Oracle Java SE 7 Update 21 (Java SE 7u21). In addition to delivering security remediation, Java SE 7u21 will also deliver some key security features. Most significant is a new requirement that all Java applets and web start applications using the Java plug-in to run in browsers be signed with a trusted certificate for the best user experience. Java supports code signing, but until Java SE 7u21 it was an optional feature. Requiring application code signing provides numerous security benefits to users.

Java SE 7u21 will introduce changes to security levels on the Security Slider within the Java Control Panel encouraging authors and vendors of applications deployed using either Java applets or Java web start technology – applications distributed to end users at runtime via the web browser or network - to sign their code using a trusted certificate. Specifically, all Java code executed within the client’s browser will prompt the user. The type of dialog messages presented depends upon risk factors like, code signed or unsigned, code requesting elevate privileges, JRE is above or below the security baseline, etc. Low risk scenarios present a very minimal dialog and include a checkbox to not display similar dialogs by the same vendor in the future. Higher risk scenarios, such as running unsigned jars, will require more user interaction given the increased risk of exploitation to the desktop.

Even the smallest changes in user experience are sometimes troublesome. We have considered how our changes impact user experience and it is our desire to find the best balance of security and user experience. Given the current climate around Java security in the browser, code signing is a valuable security control for protecting Java users.
Avatar de la.lune
Membre chevronné https://www.developpez.com
Le 13/03/2013 à 13:25
Citation Envoyé par bouye Voir le message
A partir de Java 1.7.0 u21 (prévu pour être publié en avril), les Applets devront être signées (par un certificat reconnu par une autorité) pour s'exécuter dans le navigateur de manière "confortable" pour l'utilisateur (oui je sais ce n'est pas très clair comme terme).
En tout cas c'est une très bonne nouvelle
Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 19/03/2013 à 17:56
Lexsi démystifie les failles du plugin Java
Et sort un guide qui explique comment contrôler la machine d’un utilisateur à distance

Comme la communauté Java, le cabinet indépendant de conseil en sécurité de l’information Lexsi a remarqué les failles dans la sécurité du langage.

Il a publié sur son blog la manière dont la librairie JNA (Java Native Access), qui facilite l’interaction avec la mémoire et l’exécution du code natif, pourrait être utilisée pour injecter du code à distance.

Grâce à cette bibliothèque, la réservation d’un espace mémoire est rendue possible par l’objet Memory.

La structure décrit six types de situations qui semblent présenter des forteresses de prime abord, mais qui peuvent être contournées :

    l’utilisation d’une session graphique déportée type Citrix ou autre ;

    l’ensemble des applicatifs installés sur la machine est à jour ;

    un antivirus dont les définitions sont à jour est installé et actif ;

    l’accès à internet est protégé par des équipements de type WAF, proxy HTTP authentifiant ;

    un système de SRP (Software Restriction Policy) ne permet d’exécuter qu’une application : un navigateur internet ainsi que ses plugins (flash, java) ;

    ce même système ne permet l’écriture des données qu’aux seuls endroits où le navigateur a la nécessité d’écrire des fichiers temporaires (cookie, cache, etc.).


Elle va même jusqu’à fournir le code source et les lignes de commande pour perpétrer une telle action. En quelques lignes de code, un individu peut efficacement et simplement envoyer à distance une charge malveillante de type « meterpreter » de Metasploit en contournant l’ensemble de ces restrictions.

Malgré les efforts d’Oracle pour améliorer la sécurité du langage, le plugin Java reste vulnérable à de nombreux types d’attaques. Les restrictions introduites par la société, notamment le blocage des applets non signés, permettent néanmoins de limiter les risques. Pour ceux qui n’utilisent pas le plugin, les chercheurs conseillent tout simplement de le supprimer.
Source : blog Lexsi

Et vous ?

Que pensez-vous du geste de Lexsi ?
Désactiver la JNA serait-il une solution aux problèmes causés par les failles de sécurité ?
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web