Mise à jour : 30/08/2012 20h10
Oracle vient de publier une mise à jour au moteur Java standard (versions 6 et 7). Il vous est recommandé de le mettre à jour si vous avez Java installé sur votre machine.
Une mise à jour de l’information sur cette vulnérabilité est publiée sur le site d’Oracle. Une analyse de la mise à jour est publiée ici.
Le tweet où tout commence
Vous en avez peut-être entendu (ou lu) parler ici (Korben), ici (eh oui ça touche les Mac aussi!), au Monde Informatique ou même ici (l’ANSSI vous en parle)… Assez peu toutefois dans la presse grand public (en tous cas je n’ai rien trouvé ?), même si des blogs destinés à un public assez large l’évoquent en détail (Numérama ou Malekal).
Il s’agit d’une faille (apparemment un cumul de deux failles), dites 0-day, parce que non révélées auparavant et encore exploitables parce que le produit qui est ciblé n’a pas encore été corrigé. Cette vulnérabilité, référencée sous le nom de code « CVE-2012-4681 » dans la base de référence américaine du MITRE, touche le moteur Java de la société Oracle dans sa version 1.7, soit la plus récente. Le CERT US détaille la vulnérabilité.
Chronologie
On vit cette fois-ci un enchaînement et une combinaison de phénomènes particulièrement défavorable (Eric Romang analyse aussi une partie de cette chronologie):
- 04/2012… (j’en parle un peu plus bas)
- 26/08/2012, FireEye publie sur son blog l’annonce de cette vulnérabilité jusque là inconnue. Elle leur est révélée grâce à l’étude de ce qu’ils décrivent comme une attaque ciblée d’un de leurs clients (d’autres spécialistes comme Eric Romang ou la société Trend Micro ne croient pas à cette analyse, mais plutôt à une vulnérabilité circulant déjà peut-être depuis quelques mois, Symantec de son côté effectue un rapprochementavec les attaques ciblée d’une équipe surnommée Nitro)
- FireEye a eu quelques jours auparavant des soucis avec une découverte qui n’en était pas une, alors qu’ils annonçaient avoir découvert un serveur de commande du botnet Gauss, commun avec celui d’un autre botnet semblable, Flame. En réalité c’est la société antivirus Kaspersky Lab qui avait mis en place un serveur pour reprendre le contrôle de ces deux botnets. Cela a peut être précipité leur publication expresse de l’information sur cette vulnérabilité.
- L’annonce est reprise de nombreuses fois dans beaucoup de blogs sur la sécurité informatique, y compris avec des codes de démonstration (PoC). S’agissant d’une vulnérabilité indépendante des systèmes d’exploitation, elle est potentiellement exploitable sur tous, de Linux à Microsoft Windows en passant par MacOSX.
- 27/08/2012, il semblerait que les développeurs de différentes plateformes d’exploit annoncent à leurs ‘clients’ qu’ils vont pouvoir profiter eux aussi de cette vulnérabilité très rapidement (Brian Krebs en parlait lundi au sujet de BlackHole et très vite des chercheurs en sécurité repèrent des serveurs malveillants qui l’exploitent) et selon Kafeine (et ici), l’exploit kit Sakura et Sweet orange semblent être sur les rangs. Je vous ai parlé des plateformes d’exploit dans mon article de décembre 2011 sur le rançongiciel gendarmerie ou dans l’article de février dernier sur le botnet Citadel.
- 27/08/2012, toujours, Rapid7 annonce que sa plateforme de tests d’intrusion et d’évaluation sécuritaire Metasploit intègre cette nouvelle vulnérabilité dans sa batterie de tests;
- 28/08/2012, en fin de journée, l’équipe du Kaspersky Lab pousse un petit coup de gueule. On ne sait trop si c’est contre FireEye (encore, la guerre de communication entre les sociétés de sécurité ?) ou bien contre ceux qui ont publié très rapidement des « PoC » (proof of concept, démonstrateurs de l’exploitation de la vulnérabilité).
- 29/08/2012, on apprend qu’Oracle aurait été avisé de ces vulnérabilités dès le mois d’avril (ComputerWorld) par la société polonaise Security Explorations. Notons qu’il est normal que des vulnérabilités ne soient pas corrigées immédiatement par les développeurs d’un logiciel, le développement d’une correction demandant parfois de nombreux tests pour éviter que de nouvelles failles ou dysfonctionnements soient créés par ces changements.
- 30/08/2012, à ce jour, Oracle ne reprend toujours pas l’alerte sur cette vulnérabilité et ne semble pas vouloir publier de mise à jour avant celle qui est programmée pour le mois d’Octobre 2012:
Quelque chose ne va pas dans le monde de la sécurité
Je suis assez d’accord avec certains qui ne sont pas satisfaits de cette chronologie, même si elle permet de démontrer un enchaînement particulièrement prévisible, mais qui est ici exacerbé, en moins de trois jours on aura eu:
- Une société de sécurité qui publie brutalement des informations sibyllines, mais assez faciles à déchiffrer, relatives à une vulnérabilité;
- Quelques heures après, des chercheurs s’empressent de publier presque en se faisant la course au premier qui le fera, grâce aux éléments diffusés par la dite société, des détails sur la vulnérabilité et la façon de l’exploiter;
- Un éditeur qui ne communique pas vers son public sur les mesures qu’il envisage de prendre tout de suite ou prochainement;
- Quelques heures après, les démonstrateurs publiés sont directement intégrés dans les plateformes d’exploits utilisées par les groupes criminels;
- Très rapidement, des victimes se font exploiter de façon massive, notamment pour diffuser les virus bancaires et autres rançongiciels particulièrement actifs actuellement.
Il est grand temps que les professionnels de la sécurité informatique se mettent enfin d’accord sur des procédures responsables de divulgation des vulnérabilités et ce de façon coordonnée (développeurs, comme chercheurs en sécurité de tous bords). Au vu des conséquences des exploitations aujourd’hui possibles grâce au type de botnets qui sont en activité, il est fort probable que plus de 100.000 euros aient été déjà détournées de victimes à travers le monde (les montants sont difficiles à évaluer, mais c’est l’ordre de grandeur de ce qu’on constate comme gains sur certains botnets en un ou deux jours et comme beaucoup agissent en même temps et que cette vulnérabilité n’est pas forcément celle qui est utilisée pour toutes les attaques il est encore trop tôt pour être plus précis), et vraisemblablement le compteur va finir de tourner tant qu’une mise à jour de Java n’est pas massivement diffusée. Par ailleurs, depuis lundi, des milliers de responsables informatiques se grattent la tête à travers la planète pour savoir comment sécuriser leurs réseaux et s’échangent des scripts pour rapidement désactiver Java 1.7 chez leurs utilisateurs.
Que puis-je faire chez moi ?
Sur un ordinateur personnel, il est vraisemblable que vous n’ayez pas besoin très souvent de Java, même s’il est parfois nécessaire pour certaines applications disponibles en ligne. Il est donc raisonnable d’envisager de désactiver Java dans son ordinateur, au moins pour la version 1.7.
Plusieurs sites expliquent les procédures: le blog Malekal, ou encore ici en anglais. Vous pouvez vous prémunir de ce type d’attaques et bien d’autre en installant des extensions de sécurité telles que NoScript (http://noscript.net/ pour Firefox ou Notscripts ou Scriptno sous Chrome) qui vous permettent d’avoir un contrôle site par site du lancement grâce à des programmes intégrés (scripts) de ce type de modules depuis une page Web.
Dans une entreprise, beaucoup seront peut-être encore à la version précédente qui certes a d’autres vulnérabilités mais permet de faire tourner certaines applications. Si Java n’est pas nécessaire dans votre entreprise, il semble aujourd’hui urgent de le désactiver pour éviter tout incident. Si Java 1.7 est indispensable dans votre contexte, il existe des correctifs non officiels qui pourraient vous aider.
Faites circuler l’information et continuez de vous tenir informés des bonnes pratiques.
Mise à jour : 30/08/2012 20h10
Oracle vient de publier une mise à jour au moteur Java standard (versions 6 et 7). Il vous est recommandé de le mettre à jour si vous avez Java installé sur votre machine.
Une mise à jour de l’information sur cette vulnérabilité est publiée sur le site d’Oracle.
Bonjour à vous,
Très belle chronologie et je suis presque à 100% aligné avec votre point de vue:
– Une société de sécurité qui publie brutalement des informations sibyllines, mais assez faciles à déchiffrer, relatives à une vulnérabilité;
Comme vous le préciser ces vulnérabilités étaient connues par Oracle depuis Avril, et malheureusement ont été découverte exploitées dans la nature. Soit il y a eu recherche parallèle qui a aussi découvert ces vulnérabilités, mais pas dans le même esprit que Security Explorations, soit il y a eu fuite quelque part. Mais le fait que les vulnérabilités soient présentes dans des exploits Kits et sur des serveurs passoires et connues de tous, et ceci avant la publication de FireEye ne présageait rien de bon. La divulgation aurait eu lieu quoi qu’il arrive.
Le « responsable disclosure » n’existe pas dans le cas d’une vulnérabilité exploitée dans la nature, c’est déjà trop tard, des méchants se sont déjà chargé de ne pas être responsable.
– Quelques heures après, des chercheurs s’empressent de publier presque en se faisant la course au premier qui le fera, grâce aux éléments diffusés par la dite société, des détails sur la vulnérabilité et la façon de l’exploiter;
Idem que pour le premier avis.
– Un éditeur qui ne communique pas vers son public sur les mesures qu’il envisage de prendre tout de suite ou prochainement;
100% d’accord avec vous
– Quelques heures après, les démonstrateurs publiés sont directement intégrés dans les plateformes d’exploits utilisées par les groupes criminels;
C’était déjà le cas dès avant la découverte par FireEye
– Il est grand temps que les professionnels de la sécurité informatique se mettent enfin d’accord sur des procédures responsables de divulgation des vulnérabilités et ce de façon coordonnée (développeurs, comme chercheurs en sécurité de tous bords).
La procédure responsable de divulgation des vulnérabilités coordonnée avait été respectée en Avril par Security Explorations. C’est plutot Oracle qui lance des produits non finis sur le marchés et qui prend tous son temps pour comblés les failles, et de plus ne communique pas avec les chercheurs en sécurité informatique.
Vu que les vulnérabilités avaient été découvertes exploitées dans la nature et de plus intégrées dans un exploit kit, il n’y a pas de besoin de divulgation responsable, il est déjà de toute façon trop tard.
Bonjour,
– C’est effectivement ce que je dis, il faut qu’il y ait un débat dans la communauté pour qu’on soit plus efficace, et tous les acteurs sont concernés dans cet exemple de l’éditeur aux sociétés de sécurité informatique ;
– Mon argument est que je ne suis justement pas d’accord avec ce qui semble être votre définition des divulgations responsables. Ce n’est pas parce qu’il y a des instances dans la nature de l’exploitation de la vulnérabilité (dont l’impact reste à quantifier) qu’on devrait pouvoir publier avec une telle audience un article qui pointe presque directement sur la façon de l’exploiter (sans vraiment la détailler d’ailleurs, l’ont-ils étudiée ? ont-ils contacté Oracle ?)..
D’ailleurs les faits qui ont suivi le confirment très clairement, c’est bien la publication le 26/08 qui déclenche l’intégration dans Blackhole et consorts ou encore dans Metasploit, alors que vraisemblablement l’exploitation était dans la nature depuis plusieurs semaines. Ce n’est pas parce que quelque chose existe que c’était connu, y compris dans la communauté des développeurs de plateformes d’exploit criminelles qui vivent beaucoup des informations publiées et pas réellement d’une recherche très poussée (je veux bien qu’on me prouve le contraire, mais là ce n’est pas le cas).
Donc, il faut examiner ce cas à froid et voir comment on pourrait mieux faire.
Cordialement,
Le responsible disclosure, c’est bien ; mais le responsible patching doit être au rendez-vous. Oracle, avec ses pratiques de sécurité obscures, n’est pas très coopératif (ça se ressens aussi sur MySQL) ce qui pousse au full disclosure.
De plus, l’exploit tournant déjà dans la nature, je ne vois pas en quoi continuer à le cacher aurait amélioré la situation.
Et encore, il est à craindre que l’on n’ait pas tout vu sur les dernières versions de Java tant que le plugin Java sera actif par défaut, car les dernières versions de Java (7u4 ou 7u6 selon les plateformes) incluent par défaut un énorme bloc de code pour JavaFX (lib/jfxrt.jar) comprenant aussi un Webkit embarqué (bin/jfxwebkit.dll).
Ce serait impressionnant qu’une telle arrivée de code, Java et natif, utilisable depuis le web via le Java plugin n’ait apporté aucune faille (même si JavaFX 2 a commencé à être utilisé dans la nature depuis un an).
De plus, certaines améliorations de performances de JavaFX impliqueront des modifications du coeur de la machine virtuelle Java pouvant ajouter des problèmes intéressants de sécurité, tant que du code extérieur pourra être aussi facile à exécuter sur la JVM.
Je trouve effectivement assez irresponsable le courant de pensée « je ne vois pas en quoi contribuer à le cacher aurait améliorer la situation ». Franchement il s’agit de mauvaise foi non ? On parle de choses concrètes à savoir que des 0 days ont forcément toujours un côté ludique, mais lorsque la criminalité organisée s’en empare pour causer du préjudice, ça sert qui ou quoi ? N’est-il pas important de protéger l’écosystème des menaces non-contrôlables ? C’est comme diffuser un nouveau sida et de dire : les laboratoires pharmaceutiques et les chercheurs n’ont qu’à ce bouger le cul ! Un peu facile.
Pour conclure ne perdons pas de vue que :
« Est complice d’un crime ou d’un délit la personne qui sciemment, par aide ou assistance, en a facilité la préparation ou la consommation.
Est également complice la personne qui par don, promesse, menace, ordre, abus d’autorité ou de pouvoir aura provoqué à une infraction ou donné des instructions pour la commettre. » (Article 121-7 du Code Pénal)
Révéler le problème permet aux utilisateurs de prendre des mesures pour ne plus être exposés aux attaques des « méchants » qui exploitent déjà la vulnérabilité.
Ne rien dire aurait juste permis à ces derniers de continuer tranquillement leurs activités, ce qui- AMHA- est plus dangereux.
Bonjour,
C’est justement là que je ne suis pas d’accord (voir le contenu de l’article sur la chronologie et les réponses à des commentaires précédents).
Le problème c’est que d’un côté on a quelques victimes isolées ciblées par ce qui semble être un phénomène très local, voire selon les auteurs de l’alerte une attaque ciblée. De l’autre on a des centaines de millions d’utilisateurs dont très peu sont aujourd’hui au courant en réalité et des dizaines de groupes qui auparavant ne connaissaient pas cette faille et maintenant l’intègrent dans les exploit kits déployés, et donc au résultat ces centaines de millions mal protégés sont encore plus vulnérables parce que la méthode de l’attaque a été dévoilée au plus grand nombre de délinquants.
Cordialement,
De manière analytique, on peut aussi constater les points suivants:
-Oracle ne fournit pas de patch out-of-band
-Une vulnérabilité sort de manière confidentielle.
-Aucun patch n’est sorti, laissant tous les utilisateurs en risque.
Cette situation est la pire qu’il soit:
–> Impossible de connaitre la portée de la faille, impossible de connaitre son étendue, impossible de savoir si on est vulnérable. On peut rester la tête sous le sable en espérant que la faille reste confidentielle et qu’elle passe à côté de nous, mais c’est un pari que je ne prendrai pas.
Puis une énorme publicité est faite autour de cette faille:
-on la comprend bien
-elle est étudiée, et immédiatement répliquée de partout, y compris sous forme de kit, etc..
-Oracle sort de sa torpeur et publie un patch en 3 jours!
–> Bénéfices évidents et immédiats pour _tout_ le monde.
Ensuite, imaginer un monde parfait ou les chercheurs remontent de manière responsable les failles et ou les éditeurs coopèrent gentiment dans les correctifs, pourquoi pas, mais ça reste de l’utopie bisounoursienne. Sauf qu’on est dans un monde ou les éditeurs ne font RIEN lorsqu’on leur remonte des failles, ce qui implique que la seule attitude constructive est le full disclosure avec Poc: les failles sont corrigées. C’est rude pour tout le monde (éditeur, administrateurs, utilisateurs), mais c’est la seule méthode qui fonctionne.
Bonjour !
Un point bisounours depuis un commentateur anonyme 🙂
– Je pourrais vous inviter à relire l’article dans un premier temps.
– Je pourrais aussi vous rappeler qu’on ne vit pas dans un univers où il y a une vulnérabilité à gérer de temps en temps, mais des milliers de vulnérabilités en même temps, sur des centaines de produits avec des centaines d’acteurs différents.
– Vous êtes mal informé à croire que les utilisateurs mettent à jour rapidement leurs logiciels.
– En plus, en attirant l’attention des criminels sur une vulnérabilité forte, facile à exploiter, on crée un effet d’aubaine supplémentaire.
– Je rajouterais qu’on crée aussi l’occasion pour ces groupes criminels (ceux qui commercialisent ou louent des plateformes d’exploits) de se faire de la publicité à moindre frais auprès de leurs acheteurs.
L’enjeu ici est justement le créneau créé par cette annonce en mode « full » sur une vulnérabilité non corrigée, et qui permet leur exploitation large, sur presque 100% des personnes vulnérables, alors que dans un mode plus raisonnable et responsable de révélation de vulnérabilité, on a des impacts beaucoup plus lissés.
On est d’accord qu’Oracle a certainement tardé à diffuser un patch pour cette vulnérabilité particulière, mais cela n’enlève rien au fait que la succession d’événements que nous avons ici vécue montre bien qu’il n’y a pas une gestion satisfaisante de ce type d’informations.
Il ne faut pas regarder ce type de problèmes qu’avec le regard d’un spécialiste informatique, mais aussi s’intéresser à l’écosystème criminel qui abuse de tout cela derrière, la façon dont ils agissent et réagissent. C’est cette dimension que j’essaie de rappeler.
Cordialement,
» – Je pourrais aussi vous rappeler qu’on ne vit pas dans un univers où il y a une vulnérabilité à gérer de temps en temps, mais des milliers de vulnérabilités en même temps, sur des centaines de produits avec des centaines d’acteurs différents. »
Tout à fait, et c’est précisément le point important. On peut donc demander aux différents acteurs du monde de la sécurité à être responsable, sauf que cela ne marche pas. Les failles sont divulguées à plus ou moins grandes échelle, et les éditeurs patchent de temps en temps, quand leur prend l’envie, ce qui est autrement plus grave que de voir un pack contenant un nouvel exploit ou des vendeurs clamer qu’ils ont des framework contenant des 0days.
Il y aurait donc une autre attitude qui consisterait à se retourner vers les éditeurs de soft et de leur demander des méthodes permettant de patcher rapidement et efficacement. Google Chrome adopte la rolling release, ça me parait une avancée intéressante. Oracle décide de ne patcher que 4 fois par an, c’est une ENORME régression en terme de sécurité.
Dès lors, seul le full disclosure permet de faire avancer les choses.
Il y aura un peu de casse, mais cent fois moins qu’imaginer que cacher les failles les rendra inoffensive.
Il est vrai que le JRE d’Oracle a toujours été une vraie passoire.
Ainsi, étant sous Linux Mint 13, j’ai désinstallé Java pour installer Open JDK (le pendant Open Source de JRE).
Mais OpenJDK peut-il lui aussi être affecté par le type de faille rencontré par JRE ?
Cordialement,
Bonjour,
J’avoue qu’il faudrait que je recherche la perméabilité de ce type d’attaques dans OpenJDK. La réponse est sûrement du côté des forums de développeurs/mainteneurs d’OpenJDK qui ont pris en compte justement cette vulnérabilité dans leur travail récemment.
Le plugin pour le browser (ainsi que Java WebStart) sont propriétaires Oracle et ne font pas partie d’OpenJDK. Par conséquent, les distributions libres basées sur OpenJDK, telles qu’IcedTea, n’incluent pas le plugin standard pour le browser.
Cependant, RedHat a écrit un nouveau plugin Java pour browser [1] pour compenser l’absence de celui propriétaire d’Oracle. Je n’ai aucune idée de ses fonctionnalités et bugs, mais le code source est différent, espérons que les bugs le sont aussi (on ne trouvera ce plugin que très rarement car uniquement sur des Linux de bureau, de facto).
Désolé du manque de détails sur ce cas précis, mais je n’aime le Java qu’en serveur ou en application JavaFX car mes règles de sécurité font que je réduis au maximum la taille de la frontière (surface d’attaque) entre la zone interne de confiance et la zone externe non sûre (donc je boycotte le plugin Java, entre autres).
[1]: http://icedtea.classpath.org/wiki/IcedTea-Web
Merci pour cet info plus éclairée que moi sur OpenJDK