veilletech.frCe qui se passe
Anil Madhavapeddy, professeur à Cambridge et mainteneur du compilateur OCaml,
corrige une traversée de chemin dans cohttp et ouvre publiquement la pull
request avant la release, pour obtenir des relectures.
Son constat, relayé par Simon Willison : « En dix minutes environ (!), ce site
recevait des sondes cherchant des séquences de traversée encodées en pourcentage,
ce qui indique que des surveillants automatiques gardent un œil sur les dépôts
publics. »
Il a vérifié la chose depuis l'autre bout : en pointant un agent sur le code concerné, avec pour seule consigne de chercher des problèmes de normalisation de chemin, il a obtenu plusieurs défauts voisins et un exploit fonctionnel en moins d'une minute.
Pourquoi ça compte
La divulgation coordonnée repose sur un pari de calendrier : entre la discussion du problème et la sortie de la version corrigée, l'information publique est supposée trop mince pour être exploitée. Ce pari suppose qu'un attaquant doive faire le travail à partir d'un indice. Ce n'est plus le cas.
L'effet de volume se voit ailleurs. Nick Craig-Wood, mainteneur de rclone,
témoigne dans les commentaires : environ 20 divulgations de sécurité pendant
les dix premières années du projet, plus de 40 sur le seul mois écoulé,
dont 75 % contiennent quelque chose à examiner. L'attribution des CVE par GitHub
est passée de 2-3 jours à 3-4 semaines, l'obligeant à publier ses versions
correctives avec la mention CVE-PENDING au changelog.
Ce qu'on peut en faire
Considérer que publier un correctif publie la faille : préparer la version corrigée avant d'ouvrir la discussion publique, et sortir le correctif et l'avis le même jour. Deux témoignages ne font pas une étude, mais ils concordent.
Source : Simon Willison, Just a rumour of a bug is enough to find a security exploit these days · billet d'origine : Anil Madhavapeddy