Java : les correctifs sortent, les failles suivent,
"le langage est un désordre qui n'est pas sécurisé" pour AlienVault Labs

0PARTAGES

1  1 
Mise à jour du 04/03/2013

Malgré les efforts d’Oracle pour rendre Java plus sécurisé, la plateforme est toujours vulnérable.

Une fois de plus, à la suite des sorties de nouveaux correctifs de sécurité (Java 1.6 update 41 et Java 1.7 update 15) qui corrigent les précédentes failles, de nouvelles vulnérabilités sont découvertes.

Ces failles, comme il est coutume, sont exploitables via les plugins Java exécutés dans le navigateur, pour perpétrer de cyberattaques.




Les pirates injectent en particulier des « ransomware », des codes malveillants qui se propagent typiquement de la même manière que les vers informatiques. Les documents de l’utilisateur sont alors verrouillés et une demande de paiement est exigée en échange de la clé pour les déverrouiller.

Adam Gowdiak, PDG de Security Explorations dit sans détour : « nous ne pouvons affirmer aux utilisateurs qu’il est de nouveau sûr d’utiliser Java ». Jaime Blasco, de la société AlienVault Labs, quant à lui, fait écho en affirmant que « Java est un désordre, il n’est pas sécurisé, vous devez le désactiver ».

Face à ces risques de sécurité, le département américain de la sécurité recommandait aux utilisateurs de désactiver temporairement Java. Apple ayant été touché de plein fouet a réagi avec une mise à jour de son filtre anti-malware XProtect qui désactive Java sur les versions Mountain Lion et Lion d’OS X.

Source : Reuters

Et vous ?

Pensez-vous que Java pourrait à nouveau inspirer confiance ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 20/03/2013 à 13:01
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é.

Citation Envoyé par Stéphane le calme
Désactiver la JNA serait-il une solution aux problèmes causés par les failles 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é.
5  0 
Avatar de la.lune
Membre chevronné https://www.developpez.com
Le 05/03/2013 à 0:47
Une heure après la publication de cet article Oracle a publié une mise à jour de sécurité, le Java 1.7 update 17. Mais cet article on se réfère d'une source qui parle de de java 1.7 update 15, donc une version avant l'avant-dernière version. L'essentiel mettez à jour vos systèmes.
http://www.oracle.com/technetwork/java/javase/downloads/index.html

A vrai dire si oracle continue dans ce sens il pourra sans doute colmater tous les fuites sur la sécurité dont sa machine virtuelle est exposé.
3  1 
Avatar de wax78
Modérateur https://www.developpez.com
Le 06/03/2013 à 11:03
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/03/2013 à 17:12
Les 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.
2  0 
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 06/03/2013 à 10:39
Citation Envoyé par Hinault Romaric Voir le message
Java 7 update 15 est sortie dimanche dernier. Oracle est passé directement à Java 7 update 17, sans expliquer pourquoi.
L'update 15 c'était le 19 février ! Mais, IMHO, la.lune faisait référence a ton lien Reuters qui date du 14 Janvier !

Il n'en reste pas moins qu'Oracle semble désormais réagir rapidement !

a+
Philippe
1  0 
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 06/03/2013 à 14:06
Citation Envoyé par herve4 Voir le message
La notion d' "urgence" pour le correctif java est une notion plutôt relative, je trouve. La détection du problème ne date pas d'hier...

J' espère que ce correctif sera suffisant pour la suite des evenements...
C'est clair hier le patch était déjà à disposition

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
1  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 13/03/2013 à 12:06
A partir de Java 1.7.0 u21 (prévu pour être publié en avril), les Applets devront être signées (par un certificat reconnu par une autorité) pour s'exécuter dans le navigateur de manière "confortable" pour l'utilisateur (oui je sais ce n'est pas très clair comme terme).

Si j'ai bien compris la FAQ en bas de l'article, les Applets non-signées afficheront un nombre plus important de boites de dialogues de sécurité et l'utilisateur pourra plus facilement terminer l'exécution d'un programme en cas de comportement dangereux.
De plus Oracle se réserver le droit de restreindre encore plus le mode d'exécution des applet "self-signed" (avec un certificat temporaire généré par le developpeur lui-même) ou non-signées dans les mises à jour suivantes.

Citation Envoyé par http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html
During the February 19, 2013 Java Critical Patch Update (CPU)1, Oracle announced it’s intentions to deliver a new April 16, 2013 Java CPU release, Oracle Java SE 7 Update 21 (Java SE 7u21). In addition to delivering security remediation, Java SE 7u21 will also deliver some key security features. Most significant is a new requirement that all Java applets and web start applications using the Java plug-in to run in browsers be signed with a trusted certificate for the best user experience. Java supports code signing, but until Java SE 7u21 it was an optional feature. Requiring application code signing provides numerous security benefits to users.

Java SE 7u21 will introduce changes to security levels on the Security Slider within the Java Control Panel encouraging authors and vendors of applications deployed using either Java applets or Java web start technology – applications distributed to end users at runtime via the web browser or network - to sign their code using a trusted certificate. Specifically, all Java code executed within the client’s browser will prompt the user. The type of dialog messages presented depends upon risk factors like, code signed or unsigned, code requesting elevate privileges, JRE is above or below the security baseline, etc. Low risk scenarios present a very minimal dialog and include a checkbox to not display similar dialogs by the same vendor in the future. Higher risk scenarios, such as running unsigned jars, will require more user interaction given the increased risk of exploitation to the desktop.

Even the smallest changes in user experience are sometimes troublesome. We have considered how our changes impact user experience and it is our desire to find the best balance of security and user experience. Given the current climate around Java security in the browser, code signing is a valuable security control for protecting Java users.
1  0 
Avatar de Sharcoux
Membre averti https://www.developpez.com
Le 21/03/2013 à 16:43
Oui, 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?
1  0 
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 27/03/2013 à 21:41
Citation Envoyé par berceker united Voir le message
Depuis que je l'ai désinstallé, je me suis jamais retrouvé dans une situation ou je devais l'installer pour utiliser une quelconque application ou accéder à une fonctionnalité d'un site. D'un coté, je m'aventure pas loin coté internet. Mais je viens de me rendre compte que je pouvais m'en passer et que je suis pas emmerdé par ces mise à jour à répétition. La question se pose. Est-ce que l'utilisateur lambda a vraiment besoin d'une JVM pour aller sur Web ?
Non ! Sauf, pour remplir sa feuille d'imposition
1  0 
Avatar de rt15
Membre confirmé https://www.developpez.com
Le 25/04/2013 à 11:48
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.
2  1 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web