Mais pourquoi Microsoft est-il si mauvais ?
Krebs, éditorialiste respectable et respecté du Washington Post, vient d'enfourcher le cheval du manichéisme (robe pie, cela va sans dire) et titre « Internet Explorer Unsafe for 284 Days in 2006 ». Et de comparer les 284 jours de « fenêtre de vulnérabilité » de MS et les 9 jours de risques encourus par les usagers de Firefox durant cette même période.
Voilà un chiffre qui frappe l'imagination. Tout comme celui des quelques 415 jours de souffrance concernant une « petite » faille rpc que l'on peut exhumer de la liste des trous non comblés tenue par eEye. Mais... mais se contenter de déplorer cette situation, de conspuer l'abominable MiKro$oft (in L33t dans le texte) fait oublier certaines petites précisions techniques.
A commencer par le fait que les failles les plus béantes ne sont pas celles que l'on connaît et que l'on peut comptabiliser, mais celles qui sont exploitées. Et qu'il existe une frange -assez étroite reconnaissons-le, mais parfois très nuisible- de défauts potentiels non publiés et touchant aussi bien Microsoft que la Fondation Mozilla. C'est la résultante de la « professionnalisation » de l'activité criminelle informatique, c'est également, dans une plus faible proportion, le fruit de la monétisation des trous de sécurité par certaines entreprises. De ce côté là, Mozilla doit assumer sa part de responsabilités.
Ajoutons que le problème n'est pas tant « l'incapacité » de Microsoft et la « mauvaise écriture de ses programmes » qui est en cause, que son attachement inexplicable à une mensualisation des correctifs. En tentant de « réguler » la publication des rustines -sous le conseil peut-être un peu trop candide de DSI « fonctionnarisées »-, la Windows Company a, de son propre fait, accru cette fameuse fenêtre de vulnérabilité. Comment se fait-il qu'au sein d'une entreprise spécialisée dans la conception des systèmes d'exploitation personne n'ai compris qu'une mesure de sécurité est avant tout un problème d'adaptation à la menace -un simple automatisme PID*, une contre-réaction série-, et non une action « temps réel » au sens déterministe du terme, soumise à des cycles d'horloge que rien ni personne ne peut modifier ?
Renchérissons une fois de plus sur le paradoxe de la « divulgation responsable » des failles en dehors de la sacro-sainte juridiction des éditeurs concernés. Si ce « péril jaune du full disclosure » était aussi dramatique que ne le prétendent ses principaux détracteurs, la fenêtre de vulnérabilité de la Mozilla Foundation serait considérablement plus importante que ce qu'aurait mesuré Brian Krebs. Notons à ce propos ce superbe sujet de devoir en première année de socio « Rift Widens Over Bug Disclosure » que publie Dark Reading. En substance, elle n'est pas très belle, cette mode du « mois du bug chez machin » et « semaine du trou chez bidule ». Elle décrédibilise les « véritables » chasseurs de failles. Tiens donc... et qui sont les véritables chasseurs de faille ? Qui donc peut juger de la moralité comparée d'un Lietchfield ou d'un Cerrudo, d'un Liu Die Yu ou d'un Auriema ? D'un Maiffret ou d'un http-equiv, d'un Paul ou d'un Zaraza ? Il est tout de même assez amusant de constater que ces mêmes « gourous » respectables souhaitant tempérer l'élan de leurs cadets ont, à une époque, utilisé des méthodes semblables pour se faire connaître. Sans publication, un chercheur n'est rien, ou presque. Sans divulgation « limite » ou révélation fracassante, sans courriels saignants et avant-premières diffusés dans les colonnes du Full Disclosure ou du Bugtaq, qui donc se souviendrait des noms de ces chercheurs ? Tout est dans la manière, le subtil équilibre entre la preuve indiscutable, l'antériorité (qui prouve la paternité, et donc la compétence), le PoC et le non-dit. Ajoutons que, bons ou mauvais, ces mois du bug ont au moins une vertu : celle d'apprendre au public qu'aucun système n'est fiable, et que les mantras d'un éditeur ne renforcent en aucune manière la solidité de ses propres productions.
Maintenant, relions sans réfléchir ces deux idées simples et stupides. D'un côté les statistiques de Krebs sur les temps de « patch » après révélation d'une faille, et de l'autre l'action dévastatrice d'un « mois du bug »façon H.D. Moore. Agrémentons le tout d'une pensée profonde du genre « il n'existe pas de méthode de développement en C plus fiable qu'un autre » ou « aucune école de programmation, même structurée à l'extrême, ne peut demeurer exemple de faute dès que le nombre de lignes conçues et le nombre de programmeurs en équipe dépasse un seuil critique ». Agitons le tout, et versons ce cocktail sur une oeuvre Cisco, Oracle, ou tout autre progiciel ne faisant pas nécessairement la hune des grands média « sécurité ». Et qu'obtient-on ?
Une hécatombe
La question n'est pas de savoir si Microsoft est méchant ou non (si l'on devait mesurer les « fenêtres » de chaque éditeur, MS ne serait probablement pas le plus mal placé) mais de déterminer quelle est la méthode permettant d'intégrer la parade dans le flux de l'attaque -et accessoirement la sécurité dans le flux productif-. Plutôt Aïkido, ou plutôt « conseil de sécurité/casques bleus » ? Jusqu'à présent, la méthode Mozilla semble être statistiquement l'une des meilleures. Ce qui ne veut pas nécessairement dire que les pratiques de la fondation en termes de réponse à une agression puissent être appliquées à un géant de la taille de Microsoft ou Oracle. La nature, le nombre, la diversité, la complexité des logiciels édités alourdit singulièrement le « portage » du système Firefox. Ce qui est certain, c'est que l'idée du calendrier de patch a vécu.
* NdlC Note de la Chauffagiste : PID Proportionnelle-intégrée-dérivée. C'est ainsi que fonctionnent les boucles d'asservissement de la chaudière à commande thermostatique de la rédaction de CSO France.
