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

0PARTAGES

1  4 
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é ?

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

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 
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 
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 
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 
Avatar de rt15
Membre confirmé 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 
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 
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 
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 
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