En revanche la version 7u11 apporte une nouveauté lors de l'exécution de plugins dans le navigateur : cela ne peut plus se faire de façon invisible car on a une fenêtre d'autorisation préalable indiquant que le site veut charger une applet (y compris sur le site officiel java.com quand on clique "est-ce que je dispose de Java ?" pour vérifier la version, et même si le site dispose d'un certificat de sécurité valide).
Bref le principal danger qui était sur l'instanciation invisible d'une VM Java en visitant une page n'est plus là, on est averti avant. Les sites utilisant des applets doivent nous informer explicitement et devraient donc afficher un frame bien visible sur la page, avec une activation explicite de la part de l'utilisateur. Cela bloque les micro-applets de 1 pixel blanc. Et on a moyen aussi de régler Java pour qu'il affiche la console Java dans ce cas, et pour qu'il vérifie les certificats de sécurité de l'émetteur, et les listes CRL pour bloquer les certificats signalés abusifs. Espérons que ces mesures suffisent, sinon effectivement il vaut mieux désactiver le support des applets sur une page web (mais en fait on devrait aussi le faire avec les applets Flash dans les pages web, qui a aussi de très nombreuses failles, et qui n'affichent aucune demande préalable avant de s'exécuter pour afficher les bandeaux publicitaires qui en sont le plus large utilisateur, ainsi que Youtube qui utilise Flash pour afficher ses vidéos : il faudrait une autorisation explicite au minimum site par site, de façon à ne pas bloquer les vidéos Flash hébergés par Youtube (ou DailyMotion et TF1, parmi les plus gros sites hébergeurs de vidéos diffusées en France), mais bloquer tout le reste venant des trop nombreux réseaux d'annonceurs publicitaires). Avec HTML5 cela se complique car Flash est souvent utilisé comme moteur par défaut pour les éléments "video" (et il est possible ensuite qu'une vidéo ajoute un flux parallèle à la vidéo pour exécuter du javascript malveillant, que le moteur ActiveScript de Flash va exécuter sans rien demander de plus à l'utilisateur !) Le 24 janvier 2013 13:01, Cyrille Giquello <cyrill...@gmail.com> a écrit : > Le 16 janvier 2013 11:07, Philippe Verdy <verd...@wanadoo.fr> a écrit : >> Le 16 janvier 2013 11:01, Stéphane Péneau <stephane.pen...@wanadoo.fr> a >> écrit : >>>> Heureusement que le JRE en version Embedded n'est pas touché, sinon la >>>> cible c'était les smartphones sous Windows Phone pour aller chercher >>>> les accès des différentes applis (bancaires par exemple)... >>> >>> >>> Windows Phone qui fonctionnerait grâce à Java ? Ben voyons..... >> >> Non je n'ai pas dit ça, mais il y a IE dessus, comme aussi Firefox, et >> un Java qui tourne dessus. Windows Phone aujourd'hui c'est du Windows >> normal et ce n'est plus limité à .Net, il y a du code natif dessus >> aussi (et pas virtualisé du tout). >> Des attaques similaires existent aussi sous .Net (même principe : >> utilisation de la réflexion et changement de certificat pour passer un >> niveau de sécurité). >> Il y a aussi le système Nokia (je ne sais plus le nom) qui a du Java >> natif (mais plus nécessairement limité à la version Embedded avec les >> smartphones et tablettes actuels qui peuvent faire beaucoup plus). > > Ca ne s'arrange pas pour Java : > http://www.developpez.com/actu/51075/Java-decouverte-de-deux-nouvelles-failles-dans-le-correctif-d-Oracle-la-qualite-du-code-inquietante-pour-Security-Explorations/ > > -- > Cyrille. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
