- Après la divulgation de Copy Fail, Hyunwoo Kim a estimé que le correctif existant n’était pas suffisant et a partagé un patch le jour même, mais la procédure Linux de correction publique discrète a été révélée par une découverte externe, ce qui a entraîné la fin de l’embargo
- Dans Linux, en particulier dans la partie réseau, il existe une pratique consistant à partager l’impact de sécurité sur une liste privée, tout en corrigeant rapidement et publiquement le bug, afin de maintenir pendant quelques jours un embargo sur l’existence réelle de la vulnérabilité
- Quelqu’un d’autre a repéré le changement, en a déduit l’impact de sécurité, puis l’a rendu public, après quoi tous les détails ont été publiés
- À mesure que l’IA réduit le coût d’évaluation de la portée sécurité de chaque commit, il devient plus facile de retrouver des vulnérabilités dans des correctifs publiés discrètement, avec un rapport signal/bruit plus élevé
- La divulgation coordonnée traditionnelle sur 90 jours s’affaiblit elle aussi : dans ce cas, Kuan-Ting Chen a signalé indépendamment la vulnérabilité ESP seulement 9 heures après le signalement initial de Kim, ce qui suggère que des embargos très courts pourraient être une meilleure approche
Le choc entre Copy Fail et les pratiques de correctifs de sécurité de Linux
- Après la divulgation de la vulnérabilité Copy Fail, Hyunwoo Kim a estimé que le correctif existant n’était pas suffisant et a partagé un patch le jour même
- Kim a suivi la procédure courante dans Linux, surtout dans la partie réseau
- l’impact de sécurité a été partagé sur une liste privée d’ingénieurs sécurité Linux
- la correction du bug a été menée publiquement, discrètement et rapidement
- l’objectif était de maintenir pendant quelques jours un embargo sur l’existence d’une vulnérabilité grave alors que seul le correctif proprement dit était public
- Quelqu’un d’autre a repéré ce changement, en a déduit l’impact de sécurité, puis l’a rendu public
- La vulnérabilité ayant alors été considérée comme déjà divulguée, l’embargo a pris fin, puis tous les détails ont été publiés
La pression que l’IA exerce sur deux cultures de la vulnérabilité
-
La culture de la divulgation coordonnée
- Lorsqu’on découvre un bug de sécurité, on le signale en privé aux mainteneurs et on leur laisse généralement une période comme 90 jours pour le corriger
- L’objectif est que le correctif soit diffusé avant que la vulnérabilité ne soit connue
-
La culture du « un bug reste un bug »
- C’est une approche particulièrement courante dans Linux, où l’on part du principe que si le kernel fait quelque chose qu’il ne devrait pas faire, quelqu’un pourra en faire une attaque
- On corrige donc aussi vite que possible, sans attirer l’attention sur le fait qu’il s’agit d’une vulnérabilité
- Comme de nombreux changements passent en continu, on espère que les gens ne le remarqueront pas immédiatement, ce qui laisse un peu de temps pour patcher les systèmes
-
Avec l’IA, les risques des correctifs publics augmentent
- Cette méthode n’a jamais été parfaitement fiable, mais elle devient bien plus problématique à mesure que l’IA progresse dans la découverte de vulnérabilités
- Comme les correctifs de sécurité sont nombreux, examiner les commits est devenu plus attractif, et le rapport signal/bruit augmente
- Le coût pour l’IA d’évaluer chaque commit au fil de l’eau baisse progressivement, tandis que son efficacité augmente
-
Les embargos longs s’affaiblissent eux aussi
- Par le passé, comme la détection était lente, signaler le problème à un vendor et prévoir une fenêtre de divulgation de 90 jours signifiait qu’il y avait de bonnes chances que personne d’autre ne le découvre entre-temps
- Cette hypothèse s’affaiblit désormais, car des groupes assistés par l’IA scannent massivement les vulnérabilités logicielles
- Dans ce cas, seulement 9 heures après le signalement de Kim sur la vulnérabilité ESP, Kuan-Ting Chen l’a lui aussi signalée indépendamment
- Les embargos peuvent créer une fausse impression de non-urgence et accroître le risque en limitant les acteurs capables de corriger le défaut
-
Pistes possibles et test rapide avec des modèles
- La solution n’est pas évidente, mais des embargos très courts semblent être une bonne approche, et ils pourraient devoir raccourcir encore avec le temps
- L’IA peut accélérer non seulement les attaquants, mais aussi les défenseurs, ce qui pourrait rendre viables des embargos qui auraient autrefois été trop courts pour être utiles
- Lorsqu’on a donné f4c50a403 à Gemini 3.1 Pro, ChatGPT-Thinking 5.5 et Claude Opus 4.7, les trois modèles ont immédiatement identifié qu’il s’agissait d’un correctif de sécurité
- Lorsqu’on ne leur a donné que le diff, sans le contexte du commit, Gemini s’est montré certain qu’il s’agissait d’un correctif de sécurité, GPT a jugé cela probable, tandis que Claude a estimé que ce n’était probablement pas le cas
- Ce test n’est qu’un exemple très rapide, avec une seule exécution par modèle à partir du prompt
"Without searching, does this look like a security patch?", et il est difficile d’en tirer une comparaison solide entre modèles
2 commentaires
Entre un embargo très court et un embargo long, puisqu’on n’aura d’autre choix que d’opter pour un « embargo très court », l’agent IA chargé de la sécurité va être encore plus sollicité.
Réactions sur Hacker News
Ce changement était annoncé depuis très longtemps, et même avant de savoir ce qu’était un LLM, la fissure qu’on voit aujourd’hui était prévisible
Le catalyseur, c’est l’augmentation de la transparence logicielle. L’adoption de l’open source et des logiciels à code source disponible a fortement progressé, et les outils de rétro-ingénierie et de décompilation se sont aussi énormément améliorés. L’époque où les logiciels propriétaires standard distribués commercialement étaient réellement dissimulés à des attaquants sérieux est déjà derrière nous depuis plus de dix ans
Depuis BinDiff, ce problème avance lentement. Quand on patch un logiciel, on est pratiquement obligé de divulguer aussi la vulnérabilité. Jusqu’ici, tout le monde faisait semblant du contraire, car il fallait un certain niveau d’expertise pour comprendre qu’un patch équivalait à une divulgation de vulnérabilité, mais l’IA a fait voler cette excuse en éclats
Désormais, chaque fois que quelque chose est fusionné dans le mainline Linux, plusieurs organisations injectent le diff dans un prompt LLM, évaluent agressivement s’il s’agit d’un correctif de vulnérabilité et génèrent des guides d’exploitation. La plupart des grands projets open source comme nginx, OpenSSL ou Postgres vont probablement bientôt subir le même traitement
Les pratiques de divulgation coordonnée ne sont pas adaptées à cet environnement, et à vrai dire elles ne l’étaient déjà plus depuis dix ans
Curieusement, cette situation ne me dérange pas tant que ça, parce qu’à mes yeux les pratiques de divulgation coordonnée ont toujours admis sans remise en question qu’il valait mieux retarder la divulgation pour le confort opérationnel des administrateurs système. Cette hypothèse mérite d’être mise en doute. Retarder la divulgation prive aussi d’informations les opérateurs système qui ont d’autres options que simplement appliquer le patch
Si les vulnérabilités deviennent plus faciles à détecter et à exploiter, cette approche pourrait devenir plus courante. Bien sûr, ce n’est pas toujours possible
Ces 11 dernières années, c’était assez irritant de voir des binaires de clients de jeux obfusqués avec ProGuard être décompilés à plusieurs reprises puis publiés sur GitHub. Seul le code serveur non distribué restait privé
Fait intéressant, tant qu’on ne changeait pas le protocole réseau moins souvent qu’hebdomadairement, les attaquants n’avaient pas de mal à le rétroconcevoir. Maintenant, avec l’aide des LLM, ils devraient probablement pouvoir suivre même ce rythme
Cela ressemble moins à un nouveau problème créé par l’IA qu’à un vieux problème reconditionné en problème d’IA
Les gens identifiaient déjà les correctifs de sécurité bien avant les LLM en comparant les diffs des commits du noyau. Dès qu’un patch est publié, la course a en réalité déjà commencé
Je ne suis pas certain que réduire la période d’embargo aide vraiment. Les organisations capables de patcher en quelques heures s’en sortent déjà, et les autres mettront toujours plusieurs jours ou plusieurs semaines
Au contraire, plus le coût de génération d’exploits baisse, plus la divulgation coordonnée risque de devenir non pas moins importante, mais plus importante encore
Sur « je ne suis pas certain que réduire la période d’embargo aide », la vraie question est : pourquoi 90 jours et pas 2 ans ? L’argument du texte, c’est qu’avec la hausse de la fréquence des découvertes simultanées, les facteurs qui définissaient cet équilibre ont changé. Si de toute façon plusieurs personnes hors embargo vont trouver l’exploit, alors la période d’embargo n’est pas une vraie fenêtre, mais une illusion
Je suis d’accord avec l’idée que « une génération d’exploits bon marché rend la divulgation coordonnée plus importante ». Mais elle la rend aussi moins praticable. Si même des script kiddies peuvent trouver et exploiter des zero-days, la capacité même à coordonner s’effondre
La culture white hat a toujours eu une forme d’éthique de guilde artisanale. Si cette guilde se brise, cette éthique n’a plus vraiment où s’ancrer
Je n’ai jamais vu ça, et même en tenant compte du ton un peu hyperbolique, j’ai l’impression qu’avec les LLM cela va désormais arriver souvent
Donc ce n’est pas surprenant que Dirtyfrag ait été divulgué sous forme de correctif du noyau Linux [2]
[1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
[2] https://afflicted.sh/blog/posts/copy-fail-2.html
https://news.ycombinator.com/item?id=47921829
Il y a un gros problème
Les États-Unis sont en guerre, et une bonne partie du monde mène en ce moment des guerres d’intensité cyberattaque. C’est le cas des États-Unis, de l’UE, de la majeure partie du Moyen-Orient, d’Israël et de la Russie
Des services majeurs comme Ubuntu, GitHub, Let’s Encrypt et Stryker ont été attaqués et mis hors ligne pendant plusieurs jours, et des systèmes hospitaliers entiers ont aussi été partiellement interrompus
Dans ce contexte, l’IA a énormément accéléré la vitesse de génération des attaques. Plus vite que la défense ne peut répondre. Avant, les attaques zero-day étaient rares ; désormais, c’est devenu banal
La situation va empirer avant de s’améliorer, et elle pourrait même empirer bien davantage
Le passage qui dit « maintenant qu’il y a tellement de correctifs de sécurité, il est encore plus intéressant d’examiner les commits. Le rapport signal/bruit est plus élevé » me laisse perplexe
Le point essentiel, c’est que « le coût pour l’IA d’évaluer chaque commit devient toujours plus faible et plus efficace ». Avec l’IA, l’hypothèse selon laquelle « il y a trop de changements pour que les gens s’en aperçoivent » s’effondre
Ce test rapide ne montre pas grand-chose. Si on demande directement « est-ce un patch de sécurité ? », on suggère déjà cette prémisse à l’IA et on l’oriente vers une sortie qui va dans ce sens
Une matrice de confusion serait plus utile. Bien sûr, je comprends que cet article n’a pas vocation à être un test détaillé des capacités de l’IA
On peut le calculer à partir du nombre de vrais positifs, vrais négatifs, faux positifs et faux négatifs
Il faut des cycles de patch et de release automatisés
Jusqu’ici, nous avons dépendu de procédures manuelles incroyablement lentes : recevoir un signalement, enquêter, valider, patcher, puis préparer une release. Il n’est pas rare qu’il faille des mois pour sortir une version corrigée. À une époque où les attaquants peuvent produire de nouveaux exploits en quelques heures, c’est bien trop lent
Pour réduire le temps moyen jusqu’au patch, il faut améliorer de manière itérative les goulots d’étranglement de toute la chaîne de valeur
Après réception d’un rapport de bug, il devrait être possible d’obtenir en moins d’une heure un produit patché prêt pour les tests QA. Il faut standardiser cela ou l’ouvrir en open source, puis faire en sorte que toute la chaîne d’approvisionnement logicielle l’utilise, du noyau Linux → à la distribution → au produit qui utilise cette distribution → à l’utilisateur. Avec l’IA, il n’y a aucune raison de ne pas y arriver ; nous sommes simplement lents
L’IA va réduire de façon spectaculaire la fenêtre de mise à jour. En 2026, réfléchir au cooldown des dépendances serait la pire approche ; il faudra désormais réfléchir au warmup des dépendances
Bientôt, l’idée même de divulguer des vulnérabilités de manière sûre dans les projets open source disparaîtra. Le SaaS centralisé y gagnera un énorme avantage de sécurité
Une vulnérabilité d’exécution de code à distance dans une dépendance open source signifie qu’au moment même où le patch de sécurité est publié, tout le monde est vulnérable de la même manière, donc je ne vois pas vraiment où est la controverse
La vieille formule de Tony Hoare entre « l’absence de bugs évidente » et « l’évidence de l’absence de bugs » n’a jamais été aussi pertinente qu’à l’ère des LLM
Personnellement, cette manière de traiter les bugs comme de simples bugs me semble assez absurde, mais je sais que dans le monde Linux beaucoup de gens accordent plus d’importance aux principes qu’aux problèmes pratiques
Cela dit, 90 jours paraît long
Au final, les grandes entreprises de l’IA vont probablement devoir aider les personnes qui maintiennent l’infrastructure centrale d’Internet. Faire tourner les IA les plus récentes et les meilleures sur des composants comme nginx serait collectivement bénéfique pour nous tous
Le passage disant « heureusement, l’IA peut aussi accélérer les défenseurs autant que les attaquants, ce qui rend possibles des périodes d’embargo qui auraient auparavant été trop courtes pour être utiles » touche à un aspect important de cet espace de problèmes
Le risque de sécurité pourrait finir par devenir une course aux armements déterminée par qui est prêt à dépenser le plus en coût de tokens
Les attaquants ne peuvent pas y dépenser de tokens, alors que les défenseurs peuvent en dépenser pour des travaux de renforcement à partir du code source. Les attaquants se retrouvent alors limités aux tests en boîte noire