Les diffs de correctifs sont devenus des cartes d'attaque, GLM 5.3 le prouve

Et si le document le plus dangereux de l'open source n'était pas un rapport de vulnérabilité, mais le correctif qui la répare ? C'est l'idée dérangeante au cœur d'une nouvelle expérience: un correctif public, posé dans un dépôt, pourrait désormais être lu et transformé en arme par un modèle qui, d'après Epoch AI, coûte environ 1 000 $ par exploit.

Un modèle à 1 000 $ a transformé des correctifs publics en exploits

Selon l'étude d'Epoch AI, GLM 5.3, un modèle à poids ouverts publié par Z.ai en août, peut repérer et exploiter des vulnérabilités dans des versions récentes de Firefox à partir de correctifs de sécurité publiés mais pas encore livrés aux utilisateurs. Cet intervalle porte le nom de « patch gap », ou délai de correction. Les chercheurs affirment avoir conçu le dispositif pour imiter un pirate peu sophistiqué aux ressources limitées, en s'appuyant uniquement sur les informations disponibles à la sortie de chaque version.

Résultats rapportés: des chaînes d'exploits contre six versions récentes de Firefox, pour environ 1 000 $ chacune, sans aucun refus du modèle, d'après des articles de seconde main comme explainx.ai. Mozilla a depuis corrigé une faille connexe. Précisons que nous nous appuyons sur le récit d'Epoch lui-même et sur des résumés de presse, et que nous n'avons vu aucune réplication indépendante.

Le correctif est le rapport de vulnérabilité

L'open source fonctionne depuis longtemps sur un pacte: corriger en public, parce que la transparence crée la confiance et permet à de nombreux regards de relire la modification. Ce pacte supposait que transformer un correctif en exploit fiable par ingénierie inverse demandait de la compétence, du temps et de la patience. Des humains compétents en étaient capables, mais sans doute pas à grande échelle.

Si un modèle y parvient pour 1 000 $ pièce, l'équation s'inverse. Un message de commit disant « fix out-of-bounds write » n'est plus une note destinée aux collègues; c'est un panneau indiquant où se trouve le bug. À notre avis, la ressource rare n'a jamais été la vulnérabilité, mais l'attention de l'attaquant, et c'est précisément ce que les modèles de langage rendent bon marché.

Cela pénalise aussi les plus diligents. Les projets qui valident leurs correctifs vite et ouvertement créent l'écart entre le correctif visible et le correctif livré. Plus on travaille vite en public, plus la cible reste éclairée, à moins que la livraison ne suive le rythme.

Accuser les poids ouverts, c'est passer à côté du vrai problème

Il est tentant d'en faire une histoire de modèles à poids ouverts. Nous pensons que c'est la mauvaise cible. Le fait, rapporté, que le modèle n'ait jamais refusé mérite d'être noté, mais un modèle fermé doté de garde-fous solides ne changerait probablement que l'identité de celui qui obtient la capacité en premier et la facilité avec laquelle on peut la contourner. Le problème de fond tient à la structure de la divulgation, pas à la licence du modèle.

Interdire ou restreindre les poids ne refermerait pas le délai de correction. Qu'est-ce qui le ferait ? Des délais plus courts. Des processus de publication où le commit public et la mise à jour côté utilisateur arrivent ensemble. Des correctifs sous embargo, conservés dans des branches privées jusqu'à ce que les versions soient prêtes. Des messages de commit moins descriptifs, même si nous restons sceptiques sur ce point: un modèle qui lit des diffs de code n'a pas besoin du message de commit pour repérer la modification.

Tous les projets n'en sont pas capables. Les grands éditeurs, dotés de mises à jour automatiques et de cycles de publication serrés, peuvent réduire l'écart. Une bibliothèque maintenue par des bénévoles, non. C'est dans cette asymétrie que nous attendons les vrais dégâts: la longue traîne des logiciels qui corrigent en public et se mettent à jour lentement.

Les mainteneurs devraient livrer d'abord et expliquer ensuite

Pour les mainteneurs, la recommandation est sans détour: considérer que, dès l'instant où un correctif devient visible, un exploit peut exister. Mesurer son délai en heures, pas en semaines, et envisager de retenir les commits de sécurité jusqu'à ce que la version soit prête à être livrée. La transparence peut venir juste après la livraison plutôt qu'avant.

Pour tous les autres, le conseil est ennuyeux et plus urgent que jamais: activez les mises à jour automatiques et redémarrez le navigateur quand il vous le demande. Le coût du retard vient de devenir mesurable en dollars.

Une réserve. Il s'agit d'une seule expérience centrée sur Firefox, et un résumé indique que Chrome a tenu bon; il ne faut donc pas extrapoler à tous les logiciels. Mais la direction semble assez claire. Les diffs de correctifs servaient autrefois de documentation. Ils ressemblent désormais à une carte, et la seule réponse sensée est de cesser de la laisser à la vue de tous avant que la route ne soit goudronnée.