Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
C'est clair hier le patch était déjà à dispositionEnvoyé par herve4
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
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.
Blog
Sans l'analyse et la conception, la programmation est l'art d'ajouter des bogues à un fichier texte vide.
(Louis Srygley : Without requirements or design, programming is the art of adding bugs to an empty text file.)
Lexsi démystifie les failles du plugin Java
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 ?
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
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...
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 ?
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é.
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é.
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.
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...
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...
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.
java
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.
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).
94 % des utilisateurs de Java seraient exposés à des exploits
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 ?
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
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)
Perdu!
Fallait investir dans du solaris
Maintenant, ce sont les version "supportées des OS", pour les autres => faut essayer ^^
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.
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
Il me semble bien que l'applet java n'est plus nécessaire depuis l'année dernière.
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
Il faut que l'utilisateur accepte d'exécuter du code dangereux pour que cette "faille" soit exploitable.
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).a user needs to accept the risk of executing a potentially malicious Java application when a security warning window is displayed
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).
Répondre avec citation
Partager