Java 7 : découverte d'une faille de sécurité dans l'API Reflector
Permettant de contourner la sécurité Sandbox de la plateforme
Le 2013-04-24 16:35:29, par Cedric Chevalier, Expert éminent sénior
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
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
-
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 -
rt15Membre éclairé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).le 24/04/2013 à 16:53 -
GLDavidExpert confirméBonjour
Je vais peut être faire le nostalgique, la mauvaise langue ou le pinailleur...
Mais il me semble que l'on parle beaucoup (trop ?) des failles de sécurité depuis l'ère Oracle de Java.
Attention, je ne dis pas que ces problèmes n'existaient pas chez Sun, ils existent bel et bien.
Serait-ce dû au fait que Java s'est installé dans à peu près toutes les niches possibles (dixit la propagande)? Ou est-ce dû au fait que maintenant que c'est Oracle qui "gère" Java, les gens seraient devenu plus méfiants?
Au final, OpenJava ne serait-il pas une alternative crédible?
@++le 25/04/2013 à 11:30