Un correctif publié par Oracle en 2013 pour colmater une faille de Java SE est aisément contournable

D'après des chercheurs

Une faille de Java SE, la distribution de la plateforme Java destinée typiquement aux applications pour postes de travail, qu’Oracle a colmatée en 2013 semble toujours fonctionnelle. Pour être plus précis, des chercheurs ont trouvé un moyen de contourner le correctif de sécurité mis en place par Oracle, ce qui signifie que des millions d’utilisateurs de Java ont été vulnérables pendant plus de trois ans.

C’est Adam Gowdiak, le PDG et fondateur de l’entreprise de sécurité Security Explorations, qui a divulgué ces informations dans un billet : « salut à tous, le 7 mars 2016, Security Exploration a modifié sa politique de divulgation. Par conséquent, nous ne tolérons plus les correctifs défectueux. Si jamais une instance d’un correctif défectueux pour une vulnérabilité que nous avons signalée à un vendeur était trouvée, nous allons procéder à la divulgation sans délai », a-t-il prévenu.

« L’éditeur qui a l’honneur discutable d’être le premier à subir la modification de notre politique est Oracle ». Il faut rappeler que c’est son entreprise qui a trouvé cette faille en juillet 2013 qui a été répertoriée comme étant CVE-2013-5838 et qui était décrite comme une vulnérabilité qui permettait de mettre sur pied une attaque classique contre la machine virtuelle Java. En septembre de la même année, Oracle avait alors affirmé que la faille avait été colmatée dans une implémentation rétroactive (de JDK 8) du composant affecté (l’API Method Handles) dans JDK 7 Update 40.

« Cependant, nous avons trouvé que le correctif d’Oracle pouvait être aisément contourné par l’une de ces méthodes :

• le changement des quatre caractères de notre code POC originel publié en octobre 2013 ;
• un serveur HTTP personnalisé qui force une erreur “404 (Not Found)” lorsqu’il reçoit une requête d’une classe donnée pour la première fois.

»

Pour Gowdiak, Oracle a « mal évalué l’impact de cette vulnérabilité », prétextant qu’elle « n’est exploitable que via des applications Java Web Start dans un bac à sable et via des applets Java dans un bac à sable ». « Ce qui n’est pas vrai », a insisté Gowdiak, puisque « nous avons pu vérifier qu’elle peut être exploitée dans un environnement serveur comme Google App Engine pour Java ».

D’ailleurs l’entreprise explique que la faille trouve ses origines dans une implémentation non sécurisée du nouvel API Reflection. Lorsque les objets Method Handles sont invoqués dans deux espaces de nom Class Loader, aucune vérification n’était faite quant au type de leurs arguments. Par conséquent, il était possible de fournir une définition falsifiée pour un type d’argument donné, qui aurait alors pu être traité comme un type d’argument complètement différent dans l’espace de nom Class Loader.

Le correctif d’Oracle embarque un vérificateur pour les alias de type (spoofing). Il a la forme de la méthode checkForTypeAlias, qui est invoquée pour chaque objet MemberName. Cette méthode appelle par la suite la méthode isTypeVisible de la classe sun.invoke.util.VerifyAccess. Elle prend alors deux arguments, qui correspondent au type (classe) d’un membre qui vont servir de base pour vérifier les falsifications ainsi qu’une classe de vérification.

Un appel à la méthode loadersAreRelated sera également fait pour vérifier si les Class Loader du type du membre (lorsque l’un d’entre eux est le parent de l’autre) et la classe de vérification sont liés. Une condition facile à remplir pour les chercheurs qui ont simplement eu à modifier légèrement leur code de 2013 qui a été présenté comme preuve du concept.

Voici le code original de séquence :

Voici le nouveau code qui force la condition loadersAreRelated :

Les quatre caractères qui sont changés sont en réalité le paramètre « null » qui est remplacé par « cl1 ».

Un dernier obstacle devait être franchi pour pouvoir contourner le correctif proposé par Oracle en 2013 et c’est à ce niveau qu’intervient le serveur HTTP personnalisé qui force une erreur “404 (Not Found)”.

Les chercheurs ont noté que le code d’exploit ne contourne pas les fonctionnalités click-to-play du navigateur qui bloquent le contenu Java par défaut. Présentée en 2014, cette fonctionnalité présente une page web vide jusqu’à ce que l’utilisateur clique explicitement pour lancer l’exécution du contenu. Une fonctionnalité qui semble avoir mitigé la vulnérabilité Java dans le navigateur.

Source : blog Security Explorations, preuve du concept (au format PDF)