Correctifs : Microsoft se hâte de plus en plus lentement
Brian Krebs, l'homme de la rubrique Security Fix du Washington Post, s'est lancé dans une étude statistique des « temps de réponse » microsoftien. Et pour ne pas voir ses calculs faussés par les statistiques officielles de Redmond, le journaliste s'est forcé à rechercher la date de première communication à l'éditeur plutôt que la date de première divulgation publique. Il lui a donc fallu contacter un à un les inventeurs des failles, les chasseurs de bug du monde entier. Et les résultats obtenus sont contraires au discours officiel de « Corp » : sur les trois dernières années, le temps nécessaire à la publication d'une rustine n'a fait qu'augmenter. De 90 jours en moyenne durant 2003, on est passé à 134,5 jours en 2004- 2005. Un accroissement des temps de réaction principalement provoqué par la mise en place d'un processus de vérification de non-régression plus minutieux, explique le patron du response team, Steven Toulouse. Cependant, la publication d'une faille dans les listes Full Disclosure tend à compenser cette inertie endémique. En 2003, une faille rendue publique ne prenait que 71 jours à être corrigée, 55 jours en 2004, 46 en 2005... on est très loin des 134 jours en vitesse de croisière. Mais, fait remarquer Krebs, les efforts de communication de Microsoft parviennent à convaincre les professionnels de la sécurité à communiquer plus directement et en priorité avec l'éditeur afin de lui laisser le temps d'effectuer les développements et tests de « patch » de façon sereine. Au moins 8 vulnérabilités importantes étaient mises sur la place publique en 2003 en « avant première » et à l'insu de Microsoft... moins de 4 cette année. Remarquons au passage qu'entre-temps, bon nombre de « Zero Day publishers » ont disparu des listes du FD. Et que parallèlement, le prix des ZdE a singulièrement augmenté sur le marché parallèle, et l'exploitation « business » (mafieux ou commercial « véreux ») a également augmenté de manière significative. L'étude de Krebs ne prend pas en compte, faute d'éléments tangibles, l'occultation de certaines failles qui viennent alimenter les fonds de commerce des phishers et des spammers. A noter qu'en fin d'article, Brian Krebs mentionne le cas étrange du fameux patch WMF... lequel aurait pris moins de 10 jours de développement grâce au reverse engineering d'un autre patch, non officiel celui là. Reste que d'autres aspects des inconsistances WMF étaient connues de l'équipe de Toulouse (il existe même, ce que ne mentionne pas Krebs, un CVE fort ancien sur le sujet), ce qui repose la question du « pourquoi le problème n'a-t-il pas été traité à temps »... en travaillant sur des bugs apparemment mineurs, il était fort probable que l'équipe aurait du même coup comblé le trou qui a permis le fameux ZDE. Longtemps, chez Microsoft, et ceci depuis la haute époque de Windows 3.0, l'importance d'une faille n'était pas quantifiée en fonction de la dangerosité potentielle de son exploitation, mais selon la fréquence avec laquelle les béta testeurs remontait l'information à Seattle. Dans de telles conditions, il semble logique que les hiatus d'interface ou les conflits fonctionnels « mineurs » mais simples à reproduire aient si longtemps primé sur les accidents kernel ou I.E. importants. Combien de « bugs fossiles » reste-t-il donc à exhumer ? Que le dialogue entre chasseurs de failles et Microsoft dépasse le simple rapport de force est une excellente nouvelle. Que l'aiguillon du Full Disclosure continue à inciter MS à s'impliquer sérieusement dans le travail d'épuration du code est tout aussi rassurant.
