Face à un assaut d’attaques de logiciels malveillants qui exploitent les vulnérabilités et les faiblesses de conception dans Java, Oracle Corp. a récemment modifié les choses afin que Java avertisse désormais les utilisateurs des risques de sécurité liés à l’exécution de contenu Java. Mais de nouvelles recherches suggèrent que l’intégrité et la précision de ces messages d’avertissement peuvent être facilement contournées de plusieurs façons, et que le nouveau système de sécurité d’Oracle punit en fait les développeurs d’applications Java qui y adhèrent.

Boîte de dialogue de sécurité de Java.
L’exécution d’une applet Java fait maintenant apparaître une boîte de dialogue de sécurité qui présente aux utilisateurs des informations sur le nom, l’éditeur et la source de l’application. Oracle indique que cette fenêtre contextuelle est conçue pour avertir les utilisateurs des risques de sécurité potentiels, tels que l’utilisation d’anciennes versions de Java ou l’exécution d’un code d’applet qui n’est pas signé par une autorité de certification de confiance.
Les experts en sécurité ne s’entendent pas sur la question de savoir si les utilisateurs réguliers prêtent une quelconque attention à ces avertissements. Mais pour aggraver les choses, de nouvelles recherches suggèrent que la plupart des informations contenues dans les fenêtres contextuelles peuvent être falsifiées par les auteurs de logiciels malveillants.
Dans une série de cinglant Blog des postesdéveloppeur Java de longue date Jerry Jongerius détaille les différentes façons dont les attaquants peuvent subvertir l’utilité de ces boîtes de dialogue. Pour illustrer son propos, Jongerius utilise une applet obtenue sur le propre site Web d’Oracle — javadetection.jar — et montre que les informations contenues dans deux de ses trois descripteurs de fichiers (les champs « Nom » et « Emplacement ») peuvent être modifiées, même si l’applet est déjà signée cryptographiquement.
« L’essentiel dans tout cela n’est pas le risque de sécurité des erreurs, mais le fait qu’Oracle ait commis des erreurs de type » 101 « incroyablement basiques – en autorisant des » informations non signées « dans leurs boîtes de dialogue de sécurité », a écrit Jongerius dans un échange de courrier électronique. « L’ampleur de cet ‘échec’ est énorme. »
Jongerius présente le scénario suivant dans lequel un attaquant pourrait utiliser les boîtes de dialogue pour inciter les utilisateurs à exécuter des applets non sécurisées :
« Imaginez qu’un pirate prenne une véritable application Java signée pour le contrôle/l’assistance d’un ordinateur à distance, et la place sur un site de jeu, en la renommant « Échecs ». Un utilisateur final sans méfiance recevrait une fenêtre contextuelle de sécurité de Java lui demandant s’il veut exécuter « Chess », et parce qu’il le fait, répondrait oui – mais dans les coulisses, l’ordinateur de l’utilisateur final est maintenant sous le contrôle à distance d’un pirate informatique (et peut-être pour dissiper les soupçons, a implémenté un « échecs » de base dans HTML5 pour qu’il semble que cette applet ait fonctionné) – tout cela parce qu’Oracle a autorisé le « nom » dans les dialogues de sécurité à être forgé en quelque chose d’innocent et d’incorrect.
Oracle n’a pas répondu aux demandes de commentaires. Mais Jongerius n’est pas le seul expert en logiciel à critiquer les invites de sécurité de l’entreprise. Will Dormanécrivant pour le Institut de génie logiciel de l’Université Carnegie Mellonmet en garde les développeurs Java contre l’adoption d’un principe clé des nouvelles directives de sécurité d’Oracle.
Oracle recommande que toutes les applets Java soient signées de manière cryptographique, quels que soient les privilèges requis par le programme. Les applets Java non signées s’exécuteront dans une page Web avec un avertissement rouge effrayant qui, « L’exécution de cette application peut présenter un risque pour la sécurité. » L’une des fonctionnalités les plus vantées de Java est un mécanisme de sécurité « sandbox » censé empêcher certaines fonctions lorsque l’applet est envoyée dans le cadre d’une page Web. Mais selon Jongerius et Dormann, Oracle a fait du code signé le comportement par défaut pour un accès complet à l’ordinateur (essentiellement, annulant l’utilité du bac à sable).
« Qu’en est-il de la vision d’Oracle d’un futur Java où chaque applet Java est signée ? », demande Dormann, chercheur de longue date en sécurité au sein du Department of Homeland Security. Équipe américaine de préparation aux urgences informatiques (US-CERT). «Ce que cette vision signifie, c’est que chaque applet Java, qui serait signée, serait également désormais dans un état où elle pourrait être réutilisée car elle n’est plus limitée par le bac à sable. Une applet Java en bac à sable mal conçue ne peut pas faire grand-chose. Cependant, une applet Java signée mal conçue peut faire à peu près tout ce que le code natif peut faire.
Dormann et Jongerius proposent un certain nombre d’idées qu’Oracle pourrait utiliser pour remédier à la situation. Seul le temps nous dira si l’entreprise tiendra compte des recommandations. En attendant, je continuerai d’exhorter les utilisateurs réguliers d’Internet à se débarrasser complètement de Java, ou au moins à déconnecter le plugin Java de tout navigateur Web (avertissement obligatoire : ce conseil ne s’applique pas aux utilisateurs professionnels, dont les ordinateurs peuvent compter sur Java pour des applications spécifiques).