IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Lexsi démystifie les failles du plugin Java
Et sort un guide qui explique comment contrôler la machine d'un utilisateur à distance

Le , par Stéphane le calme
114 commentaires

26PARTAGES

1  4 
Faille de sécurité critique dans Java 7 activement exploitée
pouvant être utilisée pour installer des malwares

Une nouvelle faille de sécurité vient d’être découverte par des chercheurs en sécurité dans la plateforme de développement Java.

Selon l’alerte de sécurité publiée par le groupe US-CERT (cellule américaine de sécurité informatique), la vulnérabilité concerne la dernière mise à jour Java 7 Update 10 et la mise à jour Java 7 Update 9 (versions qui ont été testées pour l’instant).

La faille peut être exploitée par un pirate après la visite d’un site Web compromis pour exécuter du code arbitraire à distance et installer des applications malveillantes sur le poste d’un utilisateur.

Les risques liés à cette faille sont assez élevés, dans la mesure où le code d’exploit a déjà été divulgué publiquement. Le kit de piratage BlackHole intègre une copie du code des instructions permettant d’exploiter la faille.

Pour l’instant, Oracle n’a encore fait aucun commentaire sur cette nouvelle faille. Les experts en sécurité conseillent de désactiver le plug-in Java dans le navigateur tant qu’un correctif n’a pas été publié.

Pour les utilisateurs de Java 7u10, ils pourront dans le panneau de configuration désactiver les applications Java qui s’exécutent dans le navigateur et définir un niveau de sécurité pour les applets non signés, les applications Java Web Start et les solutions embarquées JavaFX qui s’exécutent dans le navigateur.

Source : US-CERT

Et vous ?

Que pensez-vous de cette faille ?
Vous avez lu gratuitement 725 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

114 commentaires
Commenter Signaler un problème
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
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é.
5  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
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.
2  0 
Sharcoux
Avatar de Sharcoux
Membre averti https://www.developpez.com
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?
1  0 
Philippe Bastiani
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
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
1  0 
rt15
Avatar de rt15
Membre éclairé https://www.developpez.com
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.
2  1 
hwoarang
Avatar de hwoarang
Membre chevronné https://www.developpez.com
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...
0  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
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
0  0 
Philippe Bastiani
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
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...
0  0 
Avatar de
https://www.developpez.com
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.
0  0 
bytecode
Avatar de bytecode
Membre actif https://www.developpez.com
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.
0  0 
Commenter Signaler un problème