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

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 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 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 24/04/2013 à 16:53
Il faut que l'utilisateur accepte d'exécuter du code dangereux pour que cette "faille" soit exploitable.
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).
1  1 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
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...
0  1 
Avatar de ticNFA
Membre confirmé https://www.developpez.com
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 ?
0  4 
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 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web