Qui est-ce qui effraie le plus un éditeur de logiciels ? Le client ou l’actionnaire ? Aucun des deux... Le pire cauchemar de l’industrie informatique, c’est qu’un troisième larron - modèle de civisme ou emmerdeur ? - révèle aux deux premiers les faiblesses éventuelles de son matériel. Ce troisième larron, c’est le hacker...

En 1993 - mais son succès date de 1995 - est apparue une liste de discussion nommée BugTraq (« traque de bugs »), qui recense toutes les points faibles des produits informatiques. Elias Levy (qui se fait appeler Aleph 1), le modérateur, est devenu une vraie légende. Tout comme sa liste et son site Securityfocus, qui est sans doute maintenant la plus grande base de données du monde de vulnérabilités informatiques.

Cette liste et son explosion ont bouleversé le secteur des éditeurs de logiciels et des constructeurs de matériel. Avant BugTraq, ils étaient relativement tranquilles. Aucune publicité n’était faite lorsqu’un défaut de fabrication était trouvé. Au mieux, l’information circulait entre quelques personnes triées sur le volet (les bons clients), au pire, elle ne circulait pas. L’idée des éditeurs était la suivante : si personne ne sait qu’une vulnérabilité existe, il y a des chances pour que personne ne l’exploite... Seule faille, mais de taille, dans ce raisonnement : les vilains pirates ne sont pas moins malins que les développeurs de logiciels et peuvent aussi découvrir des bugs qu’ils exploiteront.

Le concept de full disclosure (que l’on peut traduire par « révélation intégrale ») est venu contrecarrer cette logique et ses risques. Pour ses promoteurs, un système doit pouvoir être passé au crible et les vulnérabilités doivent pouvoir être connues de tous, dans le détail et au plus vite. Ainsi, depuis que Bugtraq existe, la communauté des hackers et autres bidouilleurs informatiques s’échange quotidiennement, par mail, les caractéristiques d’une vingtaine de nouveaux bugs. Généralement, les éditeurs et les constructeurs n’ont d’autre recours que de publier un correctif très rapidement. Sans quoi, leurs clients pourraient leur reprocher leur laxisme...

Dark Guninski...

Sur Bugtraq, cela faisait un moment que ce n’était pas arrivé : une méga engueulade au sujet du full disclosure... Doit-on tout dire pas ? Un cas concret a marqué le point de départ du débat. Le 27 novembre dernier au petit matin (américain), un inconnu protégeant son identité derrière un e-mail anonyme envoie dans la liste Bugtraq une diatribe contre un hacker répondant au doux nom de Georgi Guninski. HellNbak@husmail.com (c’est tout ce que l’on saura de lui) explique, en gros, que Georgi est employé comme expert en sécurité par Netscape et qu’il passe son temps à publier des advisories (alertes de sécurité) à propos des logiciels Microsoft. Comme en plus, Georgi ne laisse que 4 jours à Microsoft avant de les rendre publiques, c’est qu’il est de mauvaise foi. Hypothèse de HellNbak : Guninski est payé par un concurrent pour déstabiliser Microsoft. La discussion sur le concept de full disclosure est relancée...

Patron d’une entreprise de sécurité informatique, Georgi Guninski est, sans aucun doute, l’un des experts en sécurité les plus connus pour son travail sur les logiciels Microsoft. Mais il a aussi publié 16 advisories concernant les produits de Netscape, l’un de ses clients. Que lui reproche HellNback ? De n’avoir offert que 4 jours à Microsoft pour publier un correctif ? Combien de temps faudrait-il attendre avant de rendre public un problème qui touche des millions d’utilisateurs de produits et qui, gardons cela à l’esprit, auraient pu être plus sûrs dès leur mise sur le marché ? 10 jours ? Un mois ? Deux ans ?

... et le côté obscur de la Force

Quelques mois auparavant, en juin 2000, pour tenter de cadrer un peu le concept de full disclosure, Rain Forest Puppy, un hacker américain (lire ci-dessus) a publié une méthodologie de publication d’alertes de sécurité : la RFPolicy. Ce document définit via quelles adresses e-mail types il convient d’alerter un éditeur de logiciel, le temps que l’on doit lui laisser pour répondre (5 jours) ou encore l’étendue des réponses que l’on peut fournir au même éditeur. Dès les débuts de Bugtraq, ses initiateurs estimaient, quant à eux, qu’il était judicieux de poster une alerte dans la liste si l’éditeur n’avait pas donné de nouvelles au bout d’une semaine. Ou même, immédiatement si le problème est excessivement grave et met en danger des millions d’utilisateurs. Enfin, ils soulignaient qu’il vaut toujours mieux poster dans la liste, même sans prévenir le vendeur, que de garder ça secret.

Le cœur du débat est là. La vie d’un bug exploitable commence lorsqu’un hacker le trouve. Il est alors généralement testé par quelques personnes, pendant un temps qui peut osciller entre une semaine et plusieurs mois. Il est ensuite posté dans Bugtraq. Puis, quelques mois plus tard, il est évoqué (mais pas décrit dans le détail) sur les sites des CERT (Computer Emergency Response Team). Résultat, la plupart des utilisateurs ne sont prévenus de l’existence du problème qu’un an après, si ce n’est jamais... Or, la publication d’un bug ne nuit pas aux ventes du produit, il suffit de compter - mais c’est impossible - le nombre de bugs concernant les logiciels Microsoft pour comprendre cela. Au contraire, le fait qu’un logiciel soit « suivi » sur le plan de la sécurité devrait rassurer les acheteurs. Et moins on laissera de temps aux méchants pirates pour exploiter des failles connues seulement des adeptes du côté obscur de la Force, mieux les gentils utilisateurs se porteront...