Une vulnérabilité Java non corrigée ravive la question de la divulgation responsable

Cela ressemble à une violation des pratiques convenues de divulgation responsable des vulnérabilités : un chercheur en sécurité vient de publier du code exploitant une vulnérabilité de Java qu’Oracle avait assuré avoir corrigée en 2013 ; il n’a pas informé l’éditeur par avance du fait que la faille était encore béante.

De fait, selon Adam Gowdiak, Pdg et fondateur de Security Explorations, la vulnérabilité est encore exploitable. Il présentait ses recherches la semaine dernière lors de la conférence JavaLand, à Bruhl, en Allemagne.

Référencée CVE-2013-5838, cette vulnérabilité avait été initialement découverte par Security Explorations. Ce dernier en avait révélé les détails après qu’Oracle eut publié un correctif à l’automne 2013. A l’époque, elle affichait un score de sévérité de 9.3 sur 10 parce qu’elle était exploitable à distance, sans authentification, pour prendre le contrôle de systèmes vulnérables.

Au mois de février dernier, alors qu’il préparait son intervention pour JavaLand, Gowdiak a découvert par accident que le correctif ne comblait pas la vulnérabilité. Ce qu’il a publiquement dévoilé à l’occasion de sa présentation.

Dans une note d’information, Gowdiak explique avoir « mis en œuvre un code de démonstration qui illustre l’impact d’un correctif raté ». Et de souligner avoir testé son exploit avec Java SE 7 Update 97, Java SE 8 Update 74, et Java SE 9 Early Access Build 108 : « dans tous les cas, une sortie complète du bac à sable de sécurité de Java est effectuée ».

Pour beaucoup d’experts, Gowdiak est allé trop loin en ne prévenant pas Oracle. Chez Fidelis Security, John Bambenek, concède qu’il peut être tentant de dévoiler rapidement une vulnérabilité « pour faire les gros titres », mais il relève que « dans ce cas particulier, l’entreprise a changé sa politique de divulgation, quelques jours avant de publier le code de démonstration. Il est généralement considéré comme déraisonnable de publier un code de démonstration pour n’importe quelle vulnérabilité, sans informer au préalable la partie concernée ».

Contacté par SearchSecurity.com (groupe TechTarget), Gowdiak défend toutefois ce changement de politique qui, selon lui, « reflète nos attentes plus élevées à l’égard des processus de sécurité des éditeurs ». Modifiée, la politique de divulgation prévoit ainsi une présentation publique des vulnérabilités encore présentes malgré un correctif, sans avertissement préalable.

Trey Ford, ancien responsable stratégie de sécurité de Rapid7, voit de la frustration dans la démarche de Gowdiak, reprochant à Oracle une lenteur « notoire » dans son cycle de correctifs : « il est très frustrant pour les chercheurs [surtout lorsqu’une vulnérabilité n’a été que partiellement corrigée] de relancer le processus avec ce qu’Oracle va probablement traiter comme une nouvelle notification ».

Mais pour Bambenek, tant éditeurs que chercheurs se doivent de « gérer les problèmes de sécurité de manière responsable ». D’ailleurs, pour Lane Thames, chercheur chez TripWire, « n’importe quel éditeur peut produire des correctifs qui contiennent d’autres bugs ou vulnérabilités. Les correctifs sont du code, et le code ne peut pas être garanti sans bug ».

Oracle doit publier ses prochains correctifs de sécurité critiques le 19 avril. Il n’a pas répondu à demandes de commentaires.

Adapté de l’anglais.