Vous êtes sur le site public du Cert-IST

Alerte orange CERT-IST/AL-2020.008 : Attaques visant F5 BIG-IP

Débat sur la publication des vulnérabilités

Date :07 Juillet 2005

Publication: Article

Introduction :

Au mois d'octobre de cette année, Scott Culp, responsable du Centre de Réponse de Sécurité chez Microsoft, a publié un essai sur ce qu'il appelle "l'information anarchique". En résumé, il encourage les chercheurs à tenir secrètes les vulnérabilités qu'ils découvrent, plutôt que de les divulguer et d'aider ainsi les pirates à développer leurs outils d'attaque. Pour certains (dont Bruce Schneier de ZDNet), la position de Microsoft repose sur le fait que, pour des raisons de facilité, l'éditeur préfère garder le secret concernant les vulnérabilités plutôt que de corriger les problèmes de sécurité, voire de produire des logiciels qui soient sécurisés dès leur conception.

Exemple :

A ce sujet, Microsoft avait accusé la société Online Solutions d'avoir divulgué à tort une faille concernant une vulnérabilité dans la gestion des cookies sous Internet Explorer 5.5 et 6 (CERT-IST/AV-2001.299). Il semblerait que Online Solutions ait découvert la faille le 1er novembre, averti aussitôt Microsoft en leur demandant de publier un bulletin de sécurité, et en l'absence de réaction de leur part, ait décidé de publer la vulnérabilité le 9 novembre. Après avoir conseillé aux utilisateurs de désactiver l'option Active Scripting d'IE, l'éditeur a finalement mis à disposition sur son site un correctif le 14 novembre.

Pour plus d'informations, lire l'article sur Yahoo : http://fr.news.yahoo.com/011121/7/2a34n.html

Débat :

Ce débat est ancien et complexe. En résumé, une vulnérabilité résulte la plupart du temps d'une erreur de programmation. Tant que personne ne le sait, il n'y a pas de danger. Dès que quelqu'un la découvre (que ce soit dans la communauté sécurité ou dans le monde des pirates), le danger augmente. Cette vulnérabilité sera annoncée et quelqu'un écrira probablement un programme d'exploitation, permettant ainsi à n'importe qui d'exploiter cette faille, quel que soit son niveau de compétences (c'est là que l'on retrouve les fameux "script-kiddies"). Enfin, le vendeur va développer un correctif pour cette vulnérabilité, diminuant ainsi le risque, mais sans le ramener à zéro. Il y a donc un cycle du danger pour chaque vulnérabilité, l'objectif étant de réduire la plage où ce risque est maximum. Et c'est dans la manière de réaliser cet objectif que s'opposent les partisans du secret des vulnérabilités et les partisans de leur publication massive.

Proposition de standardisation :

La solution proposée entre autres par Microsoft, ISS, Guardant, Foundstone, Bindview, @Stake, ... (solution qui n'est pas nouvelle en elle-même) est de donner à l'éditeur un "délai de grâce" lui permettant de développer leurs correctifs, et aux clients un délai leur permettant d'appliquer des correctifs.

Il y a donc une limite de temps, si l'éditeur ne veut (ou ne peut) pas fournir de correctifs. Si ce correctif est créé, les informations de haut-niveau concernant cette vulnérabilité, ses impacts et les solutions possibles sont publiées, et les clients auront à partir de ce moment, 30 jours pour appliquer les correctifs nécessaires. Passé ce délai, la publication des détails de la vulnérabilité sera faite.

Cet effort de standardisation devrait stopper les publications des programmes d'exploitation dès la découverte d'une vulnérabilité, qui permettent aux attaquants d'en profiter alors qu'éditeurs et clients tentent de trouver des correctifs. Ce projet, qui suivra un processus de RFC à l'IETF, vise à minimiser la publication complète des programmes d'exploitation, ne donnant aucune chance aux distributeurs et aux clients de sécuriser leurs machines à temps.

Pour plus d'information :