Java 7 : découverte d'une nouvelle faille de sécurité dans l'API Reflector
Permettant de réussir des attaques basiques de plus de 10 ans
Le 2013-07-19 11:52:28, par Hinault Romaric, Responsable .NET
Après un moment de répit, Java revient au-devant de la scène pour ses failles de sécurité.
La vulnérabilité concerne une fois de plus « l’API Reflector », intégrée dans Java et qui est source depuis plusieurs années des failles de sécurité critiques de la plateforme de développement.
Elle a été découverte par le cabinet de sécurité polonais Security Exploration, qui a confirmé que le code d’exploit fonctionne sur Java 7 SE et toutes les versions antérieures.
Selon Adam Gowdiak, PDG de l’entreprise, la faille peut permettre à des pirates de mettre en œuvre des attaques classiques connues depuis au moins 10 ans.
Comme il est de coutume, la vulnérabilité permet de contourner la sécurité du Sanbox (bac à sable) Java et d’exécuter du code de façon arbitraire.
Adam Gowdiak a une fois de plus critiqué la mise en œuvre de l’API Reflector, arguant que la fonction ne semble pas avoir été soumise à un examen de sécurité complet.
Plus qu’à espérer qu’Oracle, qui s’est engagé à corriger et communiquer sur les failles de Java, réagira rapidement afin de protéger les utilisateurs des attaques des pirates.
Oracle a été informé sur cette faille et le code d’exploit de celle-ci a été transmis à la firme par Security Explorations.
Source : Full Disclosure
Et vous ?
Que pensez-vous de la récurrence des failles dans Java ? L’aspect sécurité a-t-il été sacrifié lors du développement de la plateforme ?
La vulnérabilité concerne une fois de plus « l’API Reflector », intégrée dans Java et qui est source depuis plusieurs années des failles de sécurité critiques de la plateforme de développement.
Elle a été découverte par le cabinet de sécurité polonais Security Exploration, qui a confirmé que le code d’exploit fonctionne sur Java 7 SE et toutes les versions antérieures.
Selon Adam Gowdiak, PDG de l’entreprise, la faille peut permettre à des pirates de mettre en œuvre des attaques classiques connues depuis au moins 10 ans.
Comme il est de coutume, la vulnérabilité permet de contourner la sécurité du Sanbox (bac à sable) Java et d’exécuter du code de façon arbitraire.
Adam Gowdiak a une fois de plus critiqué la mise en œuvre de l’API Reflector, arguant que la fonction ne semble pas avoir été soumise à un examen de sécurité complet.
Plus qu’à espérer qu’Oracle, qui s’est engagé à corriger et communiquer sur les failles de Java, réagira rapidement afin de protéger les utilisateurs des attaques des pirates.
Oracle a été informé sur cette faille et le code d’exploit de celle-ci a été transmis à la firme par Security Explorations.
Source : Full Disclosure
Et vous ?
-
Bestel74Membre confirmé[troll]
On sait pourquoi Oracle ne rend pas la JVM open-source maintenant : elle a été écrite à la rache (méthodologie de La RACHE).
[/troll]le 19/07/2013 à 12:12 -
tchize_Expert éminent séniorIl faudrait une bonne fois pour toute qu'oracle supprime, purement, cette api dans les plugins non signés, et c'est réglé!
Mais voilà, ce n'est pas que cette api a été écrit à l'arrache, comme mentionné ici, mais que d'autres apis, genre swing, on été écrites à l'arrache et du coup reposent inutilement sur l'api reflection, ce qui rends une simple suppression impossible....le 19/07/2013 à 13:42 -
VoyvodeMembre émériteQue pensez-vous de la récurrence des failles dans Java ? L’aspect sécurité a-t-il été sacrifié lors du développement de la plateforme ?
Quand on sait que l'introspection existe pour qu'un programme puisse connaitre et modifier sa propre exécution, on comprend vite que ce n'est pas à mettre entre toutes les mains.
Ce sont les programmes Java qui exploitent cette API qui sont potentiellement dangereux. L'API doit être corrigée, mais il faudrait surtout songer à encadrer son utilisation car elle octroie beaucoup de puissance aux programmeurs parfois malveillants.le 19/07/2013 à 13:15 -
tchize_Expert éminent séniorC'est sur que python n'a pas de faille de sécurité.... Il n'a pas de sécurité
Encore une fois, ça concerne cette sal**** de plugin java qui, heureusement, est maintenant désactivé par défaut par oracle. Les applis serveur ou standalone ne sont pas concernées.le 19/07/2013 à 13:58 -
GLDavidExpert confirméBonjour
Plus de 10 ans que je fais du Java, je remarque que depuis que Oracle a racheté Sun, les failles et surtout les correctifs à l'emporte-pièce (beaucoup d'applis basés sur Java ne fonctionnent tout simplement plus) sont devenus monnaie courante.
Je ne dis pas que du temps de Sun c'était merveilleux et bug-free. Non, je dis juste que Java est devenu un faire-valoir supplémentaire pour Oracle.
Croyez-moi ce n'est pas du tout de gaité de coeur que je vois mon langage favori partir en déliquessence, mais force est de constater que même pour moi, je me tourne vers d'autres langages, .net au niveau pro (d'accord de manière forcé) et PHP, Ruby, Perl, Python et C à la maison.
Ô James Gosling, sors nous une nouvelle magie !
@++le 19/07/2013 à 13:59 -
ElendhilMembre avertiIl faudrait une bonne fois pour toute qu'oracle supprime, purement, cette api dans les plugins non signés, et c'est réglé!le 19/07/2013 à 13:59
-
tchize_Expert éminent séniorNon, si ma mémoire est bonne, c'est juste que tu as d'office la popup "Ho, y a une applet java là? t'es sur que tu veux que je l'exécute? Elle est pas signée."
Rappelons d'ailleurs que la signature ne garantis rien. LA seule sécurité de la signature c'est que tu est plus ou moins sur de l'éditeur et que la jvm te demande l'autorisation avant de lancer une applet signée car elle aura des droits étendus.
Forcer tout le monde à signer serait encore pire, l'utilisateur n'aurait aucun moyen de faire la différence entre l'applet signée par tartempion qui affiche du texte coloré dans le browser, et l'applet signée par mme michu qui accède au disque durle 19/07/2013 à 14:00 -
ElendhilMembre avertiAh d'accord , merci , j'avais mal compris.le 19/07/2013 à 14:05
-
ElendhilMembre averti
De nouveaux niveaux de sécurité et d'avertissements pour les applets Java ont été introduits dès Java 7 Update 10 et Java 7 Update 21 respectivement, note Ramani. « Dans un futur proche, par défaut, Java n'autorisera plus l'exécution de code non signé ou auto-signé » explique-t-elle. La plupart des exploits Java étant livrés sous forme d'applets Java non signés, cette décision stratégique prend tout son sens.
le 19/07/2013 à 14:20 -
tchize_Expert éminent séniorC'est sur, la signature du code, ca va arrêter les malware. Ca coute 50€ un certificat de signature. Quand tu vois ce que tu ramasse avec ça, t'inquiète, ils vont investirle 19/07/2013 à 14:32