Lexsi démystifie les failles du plugin Java
Et sort un guide qui explique comment contrôler la machine d'un utilisateur à distance
Le 2013-03-19 17:56:19, par Stéphane le calme, Chroniqueur Actualités
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 :
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 ?
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 ?
-
UtherExpert éminent séniorSauf 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é.La question n'a pas vraiment de sens.Envoyé par Stéphane le calme
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é.le 20/03/2013 à 13:01 -
UtherExpert éminent séniorLes 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.le 21/03/2013 à 17:12 -
SharcouxMembre avertiOui, 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?le 21/03/2013 à 16:43 -
Philippe BastianiMembre éprouvéle 27/03/2013 à 21:41
-
rt15Membre éclairé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.le 25/04/2013 à 11:48 -
hwoarangMembre chevronné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...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.
Envoyé par Traroth2
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...le 20/03/2013 à 15:31 -
UtherExpert éminent séniorJe 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.jpgle 20/03/2013 à 16:10 -
Philippe BastianiMembre éprouvéle 20/03/2013 à 17:58
-
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é
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.le 21/03/2013 à 13:48 -
bytecodeMembre actifBonsoir,
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.le 21/03/2013 à 20:52