Oracle veut renforcer la sécurité de Java. En particulier, l'éditeur va commencer par corriger la fonction de vérification de la révocation des certificats qui empêche les applets sans signature valide d'être exécutées par défaut, mais il va aussi ajouter des options de gestion centralisées avec des capacités de liste blanche pour les environnements professionnels.

Ces changements, plus d'autres mesures également liées à la sécurité, doivent permettre de « réduire l'exploitabilité et la gravité des vulnérabilités potentielles de Java en environnement desktop et de renforcer la protection de Java en environnement serveur », a déclaré avant le week-end dans un blog Nandini Ramani, la vice-présidente de l'ingénierie Java Client et Mobile Platforms chez Oracle. Cet article qui aborde la question du « niveau de sécurité de Java » est une manière de répondre indirectement à certaines critiques et préoccupations soulevées par les chercheurs en sécurité cette année. Ceux-ci se plaignaient des nombreuses attaques réussies et généralisées exploitant des vulnérabilités zero-day - précédemment non corrigées - dans le plug-in Java pour navigateur, ciblé pour compromettre les ordinateurs.

Analyse fuzzy pour détecter les failles

Nandini Ramani a répété qu'Oracle souhaitait accélérer son calendrier de mises à jour pour Java à partir du mois d'octobre, et que celui-ci serait calé sur le calendrier de mises à jour des autres produits de l'éditeur. La vice-présidente a également évoqué les mesures envisagées par Oracle pour la validation de la sécurité du code Java. « L'équipe de développement Java utilise systématiquement des outils de test de sécurité automatisés. Elle peut ainsi traiter régulièrement de grosses portions de code Java », a-t-elle écrit. L'équipe a travaillé avec le principal fournisseur de services d'analyse de code source d'Oracle pour que ces outils soient plus efficaces dans l'environnement Java. Elle a également développé des outils d'analyses, dits de « fuzzing », qui contribuent à éliminer certains types de vulnérabilités.

Le code source de Java 7 n'a semble-t-il pas bénéficié d'un examen de sécurité, ni de tests de qualité suffisants. Un grand nombre de vulnérabilités critiques ont été trouvées dans la plate-forme, suscitant une série de critiques de la part des chercheurs en sécurité. Nandini Ramani a également indiqué les nouveaux niveaux de sécurité et d'alertes pour les applets Java - les applications Java basées sur le web - introduites respectivement dans Java 7 Update 10 et Java 7 Update 21. « Ces changements ont pour but de décourager l'exécution d'applets non signées ou auto-signées », a-t-elle précisé. « Prochainement, par défaut, Java n'autorisera plus l'exécution de code auto-signé ou non signé ».

La sécurité se renforce

Ce choix par défaut est logique du point de vue de la sécurité, étant donné que la plupart des exploits Java sont livrés sous forme d'applets Java non signées. Cependant, on a déjà vu des attaques utilisant des exploits Java signés numériquement. Les chercheurs en sécurité pensent d'ailleurs que leur nombre va continuer à augmenter. Pour cette raison, il est important que le client Java puisse vérifier en temps réel la validité des certificats numériques utilisés pour signer les applets. Actuellement, Java sait prendre en charge la révocation des certificats. Il s'appuie pour cela sur les listes de révocation de certificats (CRL) et le Online Certificate Status Protocol (OCSP). Mais cette fonctionnalité est désactivée par défaut. « La fonction n'est pas activée par défaut à cause de l'impact potentiellement négatif sur la performance », a expliqué la vice-présidente de l'ingénierie Java Client et Mobile Platforms. « Oracle est en train d'améliorer les services de révocation standardisés afin de pouvoir les activer par défaut dans une future version de Java ».

L'éditeur californien veut également ajouter à Java des fonctions de gestion des listes blanches centralisées. Les entreprises pourront ainsi contrôler quels sites sont autorisés à exécuter des applets Java dans les navigateurs qui tournent sur leurs ordinateurs. À la différence des utilisateurs domestiques, la plupart des entreprises ne peuvent pas se permettre de désactiver le plug-in Java dans le navigateur, car elles en ont besoin pour accéder à leurs applications critiques écrites en Java, tournant sur le web. « Des fonctions pour gérer les politiques de sécurité locales seront bientôt ajoutées à Java. Les administrateurs système auront plus de contrôle sur les paramètres de sécurité lors de l'installation et du déploiement de Java dans leur entreprise », a déclaré Nadani Ramani. « Notamment, les administrateurs système pourront restreindre l'exécution des applets Java à des hôtes spécifiques (par exemple, les assets des serveurs d'entreprise, des partenaires, etc) et réduire ainsi le risque d'infection par un malware ».

Les entreprises inquiètes pour les applications Java

« Même si les récents problèmes de sécurité de Java n'ont généralement concerné que le code Java tournant dans les navigateurs, la médiatisation de ces problèmes a également suscité des inquiétudes dans les entreprises qui utilisent Java sur les serveurs », a reconnu la vice-présidente de l'ingénierie. Oracle a déjà commencé à retirer le client Java des distributions pour serveurs. La version du JRE serveur (Java Runtime Environment) pour Java 7 Update 21 ne contient pas le plug-in. « Oracle va continuer à chercher des mesures plus efficaces pour réduire encore davantage la surface d'attaque, en supprimant notamment certaines bibliothèques généralement inutiles en mode serveur », a déclaré Nandani Ramani. « Cependant, ces changements ne seront effectifs que dans les versions majeures de Java à venir dans la mesure où leur introduction irait à l'encontre des spécifications actuelles de Java », a-t-elle déclaré.