Java 7 : découverte d’une nouvelle faille de sécurité dans API Reflector

Java 7 : découverte d’une nouvelle faille de sécurité dans API Reflector
permettant d’exécuter du code arbitraire et réussir des attaques basiques de plus de 10 ans

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.

http://idelways.developpez.com/news/...nerabilite.jpg

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 ?

:fleche: 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 ?

[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]

Citation:

---

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 ?

---

Ce n'est pas l'entièreté de la plateforme Java qui pose problème, mais effectivement l'API Reflector (c'est très bien de l'avoir précisé).

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.

Il 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....

Citation:

---

Envoyé par Hinault Romaric

:fleche: 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 ?

---

Ça m'étonnerai que beaucoup de personnes aient envie de se mettre au Java ...
En langage puissant il y a aussi Python par exemple qui doit faire quasiment pareil que Java et qui peut aussi être utilisés dans de divers environnements (ex: avec Django pour le web).

Pour mon cas personnel, si je devais choisir entre Java et Python pour reprendre l'exemple, ça ferait un gros point noir en plus pour Java.

Citation:

---

Envoyé par CapFlow

Pour mon cas personnel, si je devais choisir entre Java et Python pour reprendre l'exemple, ça ferait un gros point noir en plus pour Java.

---

C'est sur que python n'a pas de faille de sécurité.... Il n'a pas de sécurité :aie:

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.

Citation:

---

Il faudrait une bonne fois pour toute qu'oracle supprime, purement, cette api dans les plugins non signés, et c'est réglé!

---

Ils n'ont pas annoncé que l'on ne pouvait plus exécuter les applications non signées dans le navigateur depuis une des dernières mise à jour ?

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 !

@++

Citation:

---

Envoyé par Elendhil

Ils n'ont pas annoncé que l'on ne pouvait plus exécuter les applications non signées dans le navigateur depuis une des dernières mise à jour ?

---

Non, 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 dur :D

Ah d'accord , merci , j'avais mal compris.

Citation:

---

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.

---

J'ai retrouvé le passage de la news sur developpez.net qui parlait de ça , en fait c'est dans leur feuille de route mais ça n'a pas été mis en place pour le moment.

C'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 investir :aie:

Personnellement je pense que les appli web n'ont plus rien à faire avec des applets java, flash ou autre, il vaudrait mieux se concentrer sur html 5 avec jscript et css, vu ce qu'on peut faire avec. Java reste côté serveur avec les Jsf

Ensuite c'est au niveau du système et du serveur d'appli que les choses doivent être sécurisées.

Je me demande ce qu'on pourrait découvrir si on s'acharnait autant à découvrir les failles de .Net ...

Il y a certaines choses que tu ne sais pas faire avec html5. Par exemple, essaie de lire une carte d'identité électronique avec juste du html5 pour remplir un formulaire web :)

J'avoue ne pas m'y connaître en cartes d'identités...

Ce que je veux dire, c'est que les applications internes à une pages web, ca garde son intérêt si tu as besoin d'accéder au matériel de l'utilisateur.

Oui, tu as raison. accès webcam...
Cela dit je maintiens qu'il faudrait limiter les applets au maximum, moins de risque de failles.

Citation:

---

Envoyé par tchize_

Il y a certaines choses que tu ne sais pas faire avec html5. Par exemple, essaie de lire une carte d'identité électronique avec juste du html5 pour remplir un formulaire web :)

---

Ouais, t'as raison Tchize. J'ai eu à développer un module d'authentification par données biométriques (empreintes digitales précisément) couplé avec un lecteur de carte magnétique; et le tout doit fonctionner en mode web. Franchement il y a pas 36 solutions; il n'y a que les applets signés pour faire ça!

Nous espérons vivement que Oracle trouvera bien une meilleure solution à cette faille; mais pour l'instant on fait avec; et puis ça ne remet en cause en rien la sécurité de toute la plateforme Java. :ccool:

Bonjour,

Pardonnez mon ignorance, mais lorsqu’il est dit que l'API est intégrée dans Java, on fait référence à la JVM ?

Du coup, dès qu'une machine est équipée de Java, elle est vulnérable ? Ou alors seulement lorsqu'un programme utilise cette API ?

J’entends de plus en plus de failles mises à jour du coté de Java, cela donne une mauvaise image de ce langage, mais avant de le me mettre au placard pour cause d'insécurités, j'aimerai savoir si ces failles sont évitables par nous (développeur).

Merci d'avance.

P.S: Si vous avez de la lecture, ou des explications assez simples pour un débutant, je suis aussi preneur.

@Kurogane : ces failles concernent uniquement la "sandbox" pour les applets.

Par défaut les applets tournent avec un SecurityManager qui les empêchent de faire n'importe quoi (comme lire un fichier sur le disque par exemple).


On entend moins de "faille de sécurité" pour les autres langages, car ils n'y a pas ce principe de sandbox...


a++