C'est la deuxième fois ce mois-ci qu'un éditeur donne des détails sur une vulnérabilité ayant été corrigée dans un correctif paru quelques semaines auparavant.

Après Adobe et sa mise à jour 8.1.2 pour son logiciel Reader, corrigeant une vulnérabilité (Réf Lexsi 9659) dont les détails n'ont été officiellement publiés que 2 semaines plus tard, c'est au tour de Mozilla de dévoiler une faille particulièrement critique (Réf Lexsi 9671) dans son client mail Thunderbird et corrigée dans la mise à jour 2.0.0.12, qui est disponible depuis déjà 3 semaines ! La vulnérabilité est en fait un débordement de tampon dans le tas de 3 octets lors du traitement d'un message contenant un corps externe au format MIME spécialement formé, qui peut permettre d'exécuter du code arbitraire à la simple lecture d'un courriel malveillant.

Après l'avènement du "responsible disclosure", par lequel les détails des vulnérabilités n'étaient publiés qu'au moment où le correctif était disponible, on assiste à l'arrivée d'une nouvelle tendance que l'on pourrait qualifier de "deferred disclosure", et visant à attendre qu'un correctif ait été largement déployé avant d'annoncer les vulnérabilités critiques qu'il corrige.

Si l'intention est louable - cette façon de faire évitant que des pirates exploitent massivement une vulnérabilité pendant le laps de temps précédant le déploiement d'un nouveau correctif -, le remède pourrait bien être pire que le mal.
En effet, un correctif annoncé comme ne corrigeant que des failles mineures ne sera peut être pas déployé aussi rapidement qu'un correctif majeur. Le risque sera-t-il requalifié lors de la publication des vulnérabilités n'ayant pas été spécifiées auparavant ? Il est assez probable que les administrateurs ne disposant pas d'un service de veille n'aient pas le temps de surveiller autre chose que les publications de correctifs, et ne suivent donc pas l'évolution de ceux-ci dans le temps.

On peut aussi s'interroger sur les pratiques des éditeurs dans le cas où ils auraient découvert eux-mêmes la vulnérabilité. Dans les deux cas cités, les éditeurs ont été avisés de la faille par des tiers, tels le laboratoire iDefense, et sont donc obligés, dans une certaine mesure, à publier les détails de la vulnérabilité. Mais sans aucune "pression", l'éditeur ne serait-il pas tenté de ne jamais dévoiler les détails de vulnérabilités qu'il découvrirait dans ses produits, croyant ainsi - à tort - empêcher toute exploitation de celles-ci ?