Oracle sort Java 7u13
Un correctif d'urgence pour 50 failles de sécurité, dont 26 critiques

Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux

 Discussion forum

Retrouvez le dossier complet de la rédaction
24/04 - Java 7 : découverte d'une faille de sécurité dans l'API Reflector, permettant de contourner la sécurité Sandbox de la plateforme
27/03 - 94 % d'utilisateurs de Java seraient exposés à des exploits, 75 % exécuteraient un JRE vieux, indique un rapport de Websense
19/03 - Lexsi démystifie les failles du plugin Java et sort un guide qui explique comment contrôler la machine d'un utilisateur à distance
05/03 - Java : Oracle publie des correctifs d'urgence pour colmater les failles de sécurité critiques de la plateforme
04/03 - Java : les correctifs sortent, les failles suivent, "le langage est un désordre qui n'est pas sécurisé" pour AlienVault Labs
29/01 - Failles Java : Oracle s'engage à corriger et à communiquer
21/01 - Java : découverte de deux nouvelles failles dans le correctif d'Oracle, la qualité du code inquiétante pour Security Explorations
15/01 - Oracle sort un correctif d'urgence pour la faille Java, les experts en sécurité sceptiques, maintiennent la désactivation du plugin
11/01 - Faille de sécurité critique dans Java 7 activement exploitée, pouvant être utilisée pour installer des malwares
Sur le même sujet
07/05/2013 - Oracle perfectionne ses outils de développement mobile avec ADF 1.1, pour accélérer la création d'applications Java
13/02/2013 - Oracle va publier en open source le port de JavaFX pour Android et iOS, l'éditeur dévoile sa roadmap pour l'ouverture de JavaFX
Le 05/02/2013, par Hinault Romaric, Responsable Actualités
Mise à jour du 05/02/2013

Oracle s’était engagé il y a quelques jours à corriger Java et à mieux communiquer sur la plateforme de développement.

Alliant l’acte à la parole, l’éditeur vient de publier un correctif d’urgence pour les failles de sécurité qui ont secoué l’écosystème Java ces derniers mois.

Java 7 update 13 apporte des patchs pour environ une cinquantaine de vulnérabilités, dont 26 sont classées critiques. Elles peuvent être exploitées pour exécuter du code arbitraire à distance et installer des applications malveillantes sur le poste d’un utilisateur.

Le correctif était initialement prévu pour le 19 février, mais Oracle a dû rompre avec son cycle de mise à jour habituel parce que l’une des failles était activement exploitée.

Quarante-quatre des failles sont exploitables via des applets Java ou des applications Java Web Start s’exécutant dans le navigateur. Une vulnérabilité affecte le processus de déploiement du client Java. Trois failles touchent à la fois Java côté client et serveur.

Oracle recommande l’application immédiate de cette mise à jour importante. Il est conseillé aux personnes n’utilisant pas le plug-in Java dans le navigateur de le maintenir désactivé.

Télécharger Java 7u13

Source : Oracle


 Poster une réponse

Avatar de LSMetag LSMetag
Membre régulier
le 05/02/2013 11:12
Bien, au moins l'intention est là. Oracle va finir par regagner la confiance de ses utilisateurs en poursuivant de la sorte.
Avatar de ticNFA ticNFA
Membre du Club
le 05/02/2013 12:17
Quid de Java 6 ?
Les premières failles montrant qu'il était aussi concerné (ainsi que Java 5 ?).
Avatar de bouye bouye
Modérateur
le 05/02/2013 12:36
A moins de participer à un programme de support payant auprès d'Oracle, ça m'étonnerai que des maj de sécurité supplémentaires majeures soient publiées pour Java 6 vu qu'on est déjà arrivé dans le mois après lequel le support gratuit arrive à son terme (février 2013). Donc si rien ne sort dans les 3 semaines à venir, c'est qu'il est peut-être temps de changer de version de la JVM.

Le support commercial lui va jusqu'en décembre 2016.
Avatar de tchize_ tchize_
Expert Confirmé Sénior
le 05/02/2013 14:09
Citation:
Envoyé par Hinault Romaric Voir le message
Trois failles touchent à la fois Java côté client et serveur.
Quelqu'un a des détails là dessus, j'ai besoin de savoir si il est nécessaire d'upgrader nos serveurs ou si les vecteurs en question ne nous concernent pas.
Avatar de bouye bouye
Modérateur
le 06/02/2013 23:01
Concernant le blocage par Apple, pourtant plusieurs sources indiquent bien que c’était aussi les applications desktop qui étaient bloquées.
M'est donc plus avis que c’était surtout les applications Web Start, y compris celles tournant hors du navigateur en plus des Applets.

A noter le gros troll a la fin de l'article :

Citation:
Sydney security expert Chris Gatford, of HackLabs, said Java was a "dying technology" and that from a security perspective it had been used by malware writers for quite some time to exploit computer systems.

He said it was a "highly recommended practice" to turn it off.

"So given that it's been around for a while and it has been used as a mechanism to exploit systems, I think it's good that [Apple] are thinking about turning things off that aren't needed," Mr Gatford said.

"This is a little bit of pain for perhaps a better security environment for the average home user because it's probably going to affect them most. It's going to be difficult, there's going to be pain. But ultimately it's better in the long term. But I imagine there's going to be some short term pain and a lot of people squealing.
Avatar de benoit123456 benoit123456
Invité de passage
le 06/02/2013 23:55
Bonjour,

J'utilise un site de bourse en ligne et je n'ai plus les flux en temps réel depuis ce problème.
Que puis je faire ?Pouvez vous m'aider ?

Cdt,
Avatar de bouye bouye
Modérateur
le 07/02/2013 0:43
OS ? Navigateur ? version de Java ?

A part mettre a jours vers 1.7.0_u13 et contacter l’éditeur du soft, du navigateur et/ou de l'OS, pas beaucoup d’idée.
Avatar de bouye bouye
Modérateur
le 11/02/2013 22:57
La mise a jour du 19 février contiendra les autres correctifs de sécurité qui n'ont pas pu être intégrés dans la maj du 1er février compte tenu de l'urgence et de la précipitation dans lesquelles elle a été publiée.

Updates to February 2013 Critical Patch Update for Java SE
Avatar de bouye bouye
Modérateur
le 19/02/2013 22:33
Sortie de la maj de sécurité de mi-février avec :

Attention pour les utilisateurs de Java 6 :

Citation:
Auto-update and Manual Update of JRE 6 will Replace JRE 6 with JRE 7

Since JRE 6 has reached its End of Public Updates, Oracle is taking steps to protect consumer desktops. Oracle will not leave a version of Java installed for which Oracle no longer provide security updates.

In order to do so, when updating from JRE 6, the update mechanism will not only install the latest version of JRE 7 but will also remove the highest version of JRE 6 on the system. This change will happen when the system is updated via the auto-update mechanism or by checking for updates directly from the Java Control Panel. For more information, read the Java SE 7 Update 15 Release Notes.
Avatar de tchize_ tchize_
Expert Confirmé Sénior
le 26/02/2013 22:19
Hohoho J-1 avant de voir les forums à nouveau envahis de "je déteste oracle qui désinstalle java sans prévenir"
Avatar de Népomucène Népomucène
Membre Expert
le 27/02/2013 9:42
Bonjour @Tchize.

Tu viens d'inventer le concept de "gestion préventive de troll"
qui consisterait à tenter de désamorcer une discussion pénible !

Code :
1
2
3
4
5
6
7
8
try {
     Class.forName("net.developpez.DiscussionDriver");
     Discussion discussion = new Discussion();
} catch (TrollException e) {
     e.printTrollStackTrace();
} finally {
     System.gc();
}

On va voir si ça marche
Avatar de Hinault Romaric Hinault Romaric
Responsable Actualités
le 04/03/2013 19:19
Java : les correctifs sortent, les vulnérabilités suivent
« le langage est un désordre qui n’est pas sécurisé » pour AlienVault Labs

Mise à jour du 04/03/2013

Malgré les efforts d’Oracle pour rendre Java plus sécurisé, la plateforme est toujours vulnérable.

Une fois de plus, à la suite des sorties de nouveaux correctifs de sécurité (Java 1.6 update 41 et Java 1.7 update 15) qui corrigent les précédentes failles, de nouvelles vulnérabilités sont découvertes.

Ces failles, comme il est coutume, sont exploitables via les plugins Java exécutés dans le navigateur, pour perpétrer de cyberattaques.



Les pirates injectent en particulier 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é pour les déverrouiller.

Adam Gowdiak, PDG de Security Explorations dit sans détour : « nous ne pouvons affirmer aux utilisateurs qu’il est de nouveau sûr d’utiliser Java ». Jaime Blasco, de la société AlienVault Labs, quant à lui, fait écho en affirmant que « Java est un désordre, il n’est pas sécurisé, vous devez le désactiver ».

Face à ces risques de sécurité, le département américain de la sécurité recommandait aux utilisateurs de désactiver temporairement Java. Apple ayant été touché de plein fouet a réagi avec une mise à jour de son filtre anti-malware XProtect qui désactive Java sur les versions Mountain Lion et Lion d’OS X.

Source : Reuters

Et vous ?

Pensez-vous que Java pourrait à nouveau inspirer confiance ?
Avatar de la.lune la.lune
Membre chevronné
le 05/03/2013 0:47
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/ja...ads/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é.
Avatar de Stéphane le calme Stéphane le calme
Chroniqueur Actualités
le 05/03/2013 16:02
Java : Oracle publie des correctifs d'urgence
Pour colmater les failles de sécurité critiques de la plateforme

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 ?
Avatar de Hinault Romaric Hinault Romaric
Responsable Actualités
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/ja...ads/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 Philippe Bastiani
Membre émérite
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 Traroth2
Expert Confirmé
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 wax78
Modérateur
le 06/03/2013 11:03
Avatar de herve4 herve4
Membre du Club
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 Philippe Bastiani
Membre émérite
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 danielhagnoul
Rédacteur
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 bouye
Modérateur
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 la.lune
Membre chevronné
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 Stéphane le calme
Chroniqueur Actualités
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é ?
Avatar de Traroth2 Traroth2
Expert Confirmé
le 20/03/2013 11:33
Permettre l'exécution de code natif dans une applet est sans doute une mauvaise idée, effectivement. Ca casse un peu l'idée de bac à sable...
Avatar de ticNFA ticNFA
Membre du Club
le 20/03/2013 12:30
Je serais tenter de dire qu'Oracle ne fait pas son boulot. Mais loin d'être spécialiste, je pose plutôt la question : Oracle a-t-il fait son boulot quand on voit cette facilité apparente ?
C'est délirant, non ?
Avatar de Uther Uther
Expert Confirmé Sénior
le 20/03/2013 13:01
Sauf que pour utiliser JNA, il faut avoir donner l'autorisation d’exécuter du code Java non sécurisé. Donc cette société enfonce une porte ouverte, a moins qu'elle ait trouvé un moyen d'utiliser JNA depuis la sandbox, ce qui ne semble pas être le cas.
Si Lexsi viens de découvrir que Java permet de faire appel à du code natif, je m'inquiète vraiment de leur sérieux et je ne leur confierais certainement pas la moindre mission de sécurité.

Citation:
Envoyé par Stéphane le calme
Désactiver la JNA serait-il une solution aux problèmes causés par les failles de sécurité ?
La question n'a pas vraiment de sens.
JNA ne fait pas partie de Java et n'est pas désactivable. C'est juste une bibliothèque native que l'on peux ajouter à son application comme le sont SWT, LWJGL, ...
Et comme il s'agit d'une bibliothèque native elle n'est de toute façon pas utilisable dans un applet si on n'a pas préalablement diminué la sécurité.
Avatar de hwoarang hwoarang
Membre Expert
le 20/03/2013 15:31
Citation:
Envoyé par Stéphane le calme Voir le message
Pour ceux qui n’utilisent pas le plugin, les chercheurs conseillent tout simplement de le supprimer.
En meme temps, supprimer quelque chose qu'on n'utilise pas, c'est un peu le bon sens. Le probleme, c'est plutot pour ceux qui l'utilisent...

Citation:
Envoyé par Traroth2
Permettre l'exécution de code natif dans une applet est sans doute une mauvaise idée, effectivement. Ca casse un peu l'idée de bac à sable...
Bah à partir du moment un un popup demande à l'utilisateur s'il accepte ou non que l'applet accede aux ressources, je vois pas trop le probleme. Apres tout, c'est pareil sur Android. L'utilisateur regarde de quoi a besoin une appli qu'il veut installer et accepte ou non l'installation.
Parce que sinon, dans une applet, il ne serait pas possible d'utiliser pas mal de ressources interessantes comme par exemple les librairies OpenGL. Ce qui enleverait beaucoup de leur intéret...
Avatar de Uther Uther
Expert Confirmé Sénior
le 20/03/2013 16:10
Citation:
Envoyé par hwoarang Voir le message
Bah à partir du moment un un popup demande à l'utilisateur s'il accepte ou non que l'applet accede aux ressources, je vois pas trop le probleme. Apres tout, c'est pareil sur Android. L'utilisateur regarde de quoi a besoin une appli qu'il veut installer et accepte ou non l'installation.
Je suis d'accord, mais par contre, il faut avouer que le message d'avertissement de Sun/Oracle n'est pas assez dissuasif.
Ils auraient du opter pour quelquechose du style de ce que fait Firefox pour les connexion non sécurisées, ce qui éviterait que les utilisateurs cliquent sur "oui" sans réfléchir :
http://support.cdn.mozilla.net/media...-25-5809bb.jpg
Avatar de Philippe Bastiani Philippe Bastiani
Membre émérite
le 20/03/2013 17:58
Citation:
Envoyé par Uther Voir le message
Je suis d'accord, mais par contre, il faut avouer que le message d'avertissement de Sun/Oracle n'est pas assez dissuasif.
Ils auraient du opter pour quelquechose du style de ce que fait Firefox pour les connexion non sécurisées, ce qui éviterait que les utilisateurs cliquent sur "oui" sans réfléchir :
http://support.cdn.mozilla.net/media...-25-5809bb.jpg
Je crois que celà sera la cas sur la prochaine release...
Avatar de gouessej gouessej
Membre confirmé
le 21/03/2013 13:48
Bonjour

Je vous rappelle que JNA (contrairement à JNI) ne fait pas partie de l'API standard Java, c'est une bibliothèque tierce, cela devrait être précisé dans l'article, c'est loin d'être un détail.

P.S : Uther m'a doublé

Citation:
Envoyé par Traroth2 Voir le message
Permettre l'exécution de code natif dans une applet est sans doute une mauvaise idée, effectivement. Ca casse un peu l'idée de bac à sable...
Comment accéder à OpenGL, OpenCL, OpenAL, OpenVG et OpenMAX sans code natif? Actuellement, on ne peut exécuter du code natif que dans une applet signée, pas dans une applet non signée.
Avatar de gouessej gouessej
Membre confirmé
le 21/03/2013 13:57
Citation:
Envoyé par la.lune Voir le message
En tout cas c'est une très bonne nouvelle
Cela sera un obstacle de plus pour les développeurs de jeux vidéo indépendants qui n'ont pas nécessairement les moyens de payer plusieurs centaines de dollars par an pour un certificat dit de confiance. Pour eux, ce n'est pas vraiment une bonne nouvelle. Un pirate peut très bien obtenir ce genre de certificat.
Avatar de Sharcoux Sharcoux
Membre confirmé
le 21/03/2013 16:43
Oui, surtout que je ne suis pas sûr de qui s'intéresse le plus à tes données personnelles entre les petits développeurs indépendants et les riches entreprises de développement qui auront le certificat...

Après, si l'organisme de certification fait bien son travail, ça devrait quand même permettre à l'utilisateur de cerner à quel "degré" de danger il s'expose, non?
Avatar de Uther Uther
Expert Confirmé Sénior
le 21/03/2013 17:12
Les organismes de certification ne font que garantir l'identité de la personne, pas son honnêteté. A la limite ça permet à la justice de remonter à l'adresse de la personne mais je pense que même ça, ça doit être facile a falsifier.

Et si le pirate te vole tes données personnelles, légalement en mettant une clause planquée au milieu de conditions d'utilisations interminable, il n'y a juste rien à faire.
Avatar de bytecode bytecode
Invité de passage
le 21/03/2013 20:52
Bonsoir,

Je souhaite une précision si la faille concerne les applets ou bien on peut l'exploiter sans la réponse de l'utilisateur ?
Parce que un applet qui accède au disque dur si on dit oui au message je vois pas ou est la faille, c'est juste bluffer l'utilisateur lambda qui comme les active x va dire oui sans penser a mal.

Car il me semble que metasploit auto signe les applets générer pour justement être en mesure d’exécuter le meterpreter.

Enfin si vous pouvez m'éclairer.

Merci.
Avatar de Uther Uther
Expert Confirmé Sénior
le 21/03/2013 21:48
En effet, il y a eu, récemment, des failles dans Java qui permettaient d’exécuter du code dangereux sans que l'utilisateur ne soit averti. Mais ces failles ont été corrigées et ne sont plus exploitables si on a une JVM à jour.

L'article cité par contre se contente de présenter l'utilisation de JNA pour essayer de hacker un système sécurisé, mais c'est inutilisable sans accord de l'utilisateur, ou sans l'utilisation d'une faille(corrigées depuis).
Avatar de Stéphane le calme Stéphane le calme
Chroniqueur Actualités
le 27/03/2013 13:34
Mise à jour du 27/03/2013

94 % des utilisateurs de Java seraient exposés à des exploits,
75 % exécutent un ancien JRE, indique un rapport de Websense

Avec les nombreuses failles qui touchent l’écosystème Java, les entreprises utilisant les applications Java seraient exposées à des attaques de pirates.

En effet, il est rapporté par Websense que 94 % des terminaux faisant usage d’un logiciel Java sont vulnérables à un exploit au minimum sur le JRE.

L’entreprise note cependant que bon nombre de ceux-ci exécuteraient une version dépassée de la plateforme Java. En effet, trois machines sur quatre utiliseraient un JRE vieux d’au moins six mois, selon la même enquête. Plus de 50 % accuseraient un retard de deux ans sur les mises à jour des correctifs de sécurité.

Depuis des mois déjà, les utilisateurs ont été invités à désactiver Java de leur navigateur à cause des problèmes relatifs à sa sécurité.

Pour les entreprises qui ont l’impératif d’utiliser Java sur un site en particulier, il est conseillé d’utiliser le JRE uniquement pour lui et de le désactiver ailleurs.

Oracle recommande aux utilisateurs de Java 1.6 de migrer vers le JDK 7 pour recevoir des correctifs de sécurité (la version 1.6 étant en fin de cycle avec la sortie de sa mise à jour 43).

Il faut noter par ailleurs que cette version dispose de nouvelles options de sécurité permettant que les applets non signés génèrent toujours un message d’avertissement à l’utilisateur avant d’être exécutés.

Ces données sont à prendre avec modération, puisqu’elles ne concernent que les applications contrôlées par le service Websense. Données qui ont conduit au diagramme ci-dessous.


Source : Websense

Et vous ?

Que pensez-vous de cette étude ? Les utilisateurs ne sont-ils pas les premiers à s’exposer en n’appliquant pas les mises à jour ?
Avatar de gbdivers gbdivers
Responsable C++
le 27/03/2013 15:59
Tiens, il faudrait que je vérifie sur l'ordi du boulot avec Windows 2000 la version du JRE... La dernière version est compatible Windows 2000 ? (bon, d'un autre côté, j'ai pas les droits admin dessus, je pourrais pas faire la mise à jour)
Avatar de tchize_ tchize_
Expert Confirmé Sénior
le 27/03/2013 16:03
Citation:
Envoyé par gouessej Voir le message
Cela sera un obstacle de plus pour les développeurs de jeux vidéo indépendants qui n'ont pas nécessairement les moyens de payer plusieurs centaines de dollars par an pour un certificat dit de confiance.
Si c'est une applet -> T'as intérêt à avoir une bonne raison de demander à sortir de la sandbox. Si ton problème est le stockage (parties sauvées), direction jnlp, qui fourni une api d'accès aux fichiers sécurisées ne nécessitant pas de signature (tu n'a accès qu'au fichiers appartenant à ton application en fait)
Si c'est une application indépendante -> Ben c'est comme tout les reste des jeux que t'installe sur ta machine, t'as pas besoin de certificats pour ça

Quand à l'argument de prix pour le développeur indépendant: Je suis désolé, mais si le développement de jeu java est ton core buisness, tu met les moyens pour faire fonctionner ton buisness: Lacher 160€ par an, c'est rien en frais de toutes façons à coté de la bécane à 700€, de l'hébergement sur serveur dédié à 30€ / mois, de l'adsl à 30€/ mois

Et si vraiment tu continue à trouver ça trop cher, tu te trouve 3 autres auteurs d'apps dans le même état que toi et vous faites une association qui achète ce certificat ensemble.
Avatar de tchize_ tchize_
Expert Confirmé Sénior
le 27/03/2013 16:10
Citation:
Envoyé par gbdivers Voir le message
La dernière version est compatible Windows 2000 ?
Perdu!

Fallait investir dans du solaris

Maintenant, ce sont les version "supportées des OS", pour les autres => faut essayer ^^
Avatar de fregolo52 fregolo52
Expert Confirmé Sénior
le 27/03/2013 16:56
Je ne vois pas la version 1.5 dans le camembert!

Le pire que j'ai vu c'est des applis Orable Forms avec jinitiator (donc JRE 1.3 like) sous XP SP2.

Ca fait peur ! Et si je vous dis que c'est la Police d'un pays qui a cette config, c'est inquiétant, non ? ,

Ah oui, j'ai oublié de dire quand : il y a 2ans. Donc, aujourd'hui rien n'a dû changer.
Avatar de Philippe Bastiani Philippe Bastiani
Membre émérite
le 27/03/2013 21:08
Citation:
Envoyé par fregolo52 Voir le message
Le pire que j'ai vu c'est des applis Orable Forms avec jinitiator (donc JRE 1.3 like) sous XP SP2.
Sauf erreur, jinitiator ne se substitue pas à la JRE... elle n'exécute donc pas du code venant de l'Internet (applet) ! Ce qui devrait te rassurer ;-)

a+
Philippe
Avatar de berceker united berceker united
Expert Confirmé
le 27/03/2013 21:27
Depuis que je l'ai désinstallé, je me suis jamais retrouvé dans une situation ou je devais l'installer pour utiliser une quelconque application ou accéder à une fonctionnalité d'un site. D'un coté, je m'aventure pas loin coté internet. Mais je viens de me rendre compte que je pouvais m'en passer et que je suis pas emmerdé par ces mise à jour à répétition. La question se pose. Est-ce que l'utilisateur lambda a vraiment besoin d'une JVM pour aller sur Web ?
Avatar de Philippe Bastiani Philippe Bastiani
Membre émérite
le 27/03/2013 21:41
Citation:
Envoyé par berceker united Voir le message
Depuis que je l'ai désinstallé, je me suis jamais retrouvé dans une situation ou je devais l'installer pour utiliser une quelconque application ou accéder à une fonctionnalité d'un site. D'un coté, je m'aventure pas loin coté internet. Mais je viens de me rendre compte que je pouvais m'en passer et que je suis pas emmerdé par ces mise à jour à répétition. La question se pose. Est-ce que l'utilisateur lambda a vraiment besoin d'une JVM pour aller sur Web ?
Non ! Sauf, pour remplir sa feuille d'imposition
Avatar de tchize_ tchize_
Expert Confirmé Sénior
le 27/03/2013 23:25
+1 pour le non, l'utilisateur lambda n'en a pas besoin. Je ne comprends d'ailleurs toujours pas pourquoi le plugin n'est pas distribué à part
Avatar de _skip _skip
Expert Confirmé Sénior
le 28/03/2013 13:08
Citation:
Envoyé par tchize_ Voir le message
+1 pour le non, l'utilisateur lambda n'en a pas besoin. Je ne comprends d'ailleurs toujours pas pourquoi le plugin n'est pas distribué à part
Sans doute que ça faisait partie d'une stratégie de promotion de java, la base d'un discours du style "70% des machines sont équipées".

Maintenant dans les faits, à mon sens les applications JNLP ou les applets sont plus très intéressantes pour les gros sites tout public. Par contre pour certaines applications multi-utilisateurs en entreprise c'est intéressant. Et à ce moment là il serait effectivement envisageable de devoir installer un plug-ins et 2 ou 3 trucs à part. Quant à la sécurité? Si on écrit et consomme ses propres applications, pas trop de soucis...
Avatar de berceker united berceker united
Expert Confirmé
le 28/03/2013 13:22
Citation:
Envoyé par Philippe Bastiani Voir le message
Non ! Sauf, pour remplir sa feuille d'imposition
En effet, galere parce que c'est pour bientôt.
Avatar de Uther Uther
Expert Confirmé Sénior
le 28/03/2013 17:45
Il me semble bien que l'applet java n'est plus nécessaire depuis l'année dernière.
Avatar de Cedric Chevalier Cedric Chevalier
Chroniqueur Actualités
le 24/04/2013 16:35
Java 7 : découverte d’une faille de sécurité dans l’API Reflector
permettant de contourner la sécurité Sandbox de la plateforme

Cela fait à peine quelques jours qu’un patch de sécurité pour Java 7 (Java Update 21) a été publié par Oracle, qu’une nouvelle faille de sécurité a été découverte pour la plateforme.

La faille concerne l’« API Reflector » et sa découverte a été réalisée par Adam Gowdiak, CEO de l’entreprise Security Exploration.

La faille rend vulnérables les systèmes exécutant Java 7. Même ceux qui exécutent la toute récente version estampillée Java 1.7.0_21-b11 ne sont pas épargnés. Correctement exploitée, elle permet à un hacker d’outrepasser la sécurité « sandbox » de Java. Cependant, une action de l'utilisateur est requise dans un scénario web pour le succès d’une attaque initiée par un hacker.



Le plus inquiétant encore, c’est que l’exploitation de la faille ne se limite pas uniquement à JDK 7. En effet, même la version serveur du JRE est concernée. Pour le comment de la chose, Adam Gowdiak donne une liste d’API et de composants rendant possible l’exécution de code arbitraire dans l’application serveur. C’est ainsi que nous avons : RMI et LDAP, l’implémentation de l’interpréteur XSLT de SUN, diverses implémentations SQL.

Par ailleurs, on note que la faille avait déjà été reportée à Oracle l’année passée. Surpris que celle-ci soit de nouveau présente dans les produits Java, Adam Gowdiak conclut qu’Oracle s’est concentré sur le correctif des mesures de sécurité liées aux appels de fonction de l’« API Reflector ».

Source : Seclist
Avatar de rt15 rt15
Membre éprouvé
le 24/04/2013 16:53
Il faut que l'utilisateur accepte d'exécuter du code dangereux pour que cette "faille" soit exploitable.
Citation:
a user needs to accept the risk of executing a potentially malicious Java application when a security warning window is displayed
Donc si l'utilisateur est assez bête pour ça il sera aussi suffisamment bête pour autoriser l'applet à nettoyer son disque dur (Ou surtout installer dieu sait quoi dessus).

Bref, cette "faille" est assez anecdotique comparativement à celles qui sorte de la sandbox sans en demander l’autorisation à l'utilisateur (Et visiblement il y en a qui se donne à coeur joie).
Avatar de GLDavid GLDavid
Membre Expert
le 25/04/2013 11:30
Bonjour

Je vais peut être faire le nostalgique, la mauvaise langue ou le pinailleur...
Mais il me semble que l'on parle beaucoup (trop ?) des failles de sécurité depuis l'ère Oracle de Java.
Attention, je ne dis pas que ces problèmes n'existaient pas chez Sun, ils existent bel et bien.
Serait-ce dû au fait que Java s'est installé dans à peu près toutes les niches possibles (dixit la propagande)? Ou est-ce dû au fait que maintenant que c'est Oracle qui "gère" Java, les gens seraient devenu plus méfiants?
Au final, OpenJava ne serait-il pas une alternative crédible?

@++
Avatar de rt15 rt15
Membre éprouvé
le 25/04/2013 11:48
A la base le problème est que si quelqu'un veut infecter un max d'utilisateur via une page web, il a surtout trois choix:
javascript/html
java
flash

Les failles "javascript/html" dépendent du navigateur.
Flash semble assez béton, conçut à la base pour du rendu uniquement, donc bien sandboxé tôt.

Reste java et sa jvm très compliqué, généraliste, très répandue, souvent pas très à jour.

Donc pour infecter quelqu'un de passage sur une page web, chercher des failles dans java semble tout à fait indiqué.

Que java soit plus ou moins open ou gérer par le saint père, ça ne changera pas énormément de chose au problème.
La solution est que les navigateurs bloque plus les applet java, même ceux ne demandant pas de droits, et que les messages d'avertissements sur ceux demandant des droits fassent plus peur.
 Poster une réponse  Retrouvez la suite de la discussion

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum d'entraide

Blogs

Hébergement

 
Partenaires

Hébergement Web