Claude Code découvre une vulnérabilité Linux restée cachée pendant 23 ans

 (mtlynch.io)
9 points par GN⁺ 26 일 전 | 2 commentaires | Partager sur WhatsApp
  • Claude Code d’Anthropic a automatiquement détecté une vulnérabilité exploitable à distance dans le noyau Linux, mettant au jour un heap buffer overflow dans le pilote NFS passé inaperçu pendant 23 ans
  • Avec un simple prompt du type « Où se trouve la faille de sécurité ? », il a analysé l’ensemble du noyau et identifié la vulnérabilité avec très peu de supervision
  • Le bug provient d’une conception avec tampon fixe de 112 octets dans du code noyau de 2003, puis de l’absence de limite sur la longueur de l’owner ID lors de l’ajout de l’opération LOCK
  • Carlini a aussi trouvé des centaines de vulnérabilités potentielles du noyau, mais la plupart n’ont pas encore été signalées à cause du goulot d’étranglement de la vérification humaine
  • Le modèle récent Claude Opus 4.6 a montré des capacités de détection bien supérieures aux versions précédentes, au point d’être considéré comme un tournant pour la recherche en sécurité fondée sur l’IA

Claude Code découvre une vulnérabilité Linux restée cachée pendant 23 ans

  • Le chercheur d’Anthropic Nicholas Carlini a découvert, à l’aide de Claude Code, plusieurs vulnérabilités exploitables à distance dans le noyau Linux
    • L’une d’elles est une vulnérabilité de buffer overflow dans le pilote NFS (Network File System) restée indétectée pendant 23 ans
    • Carlini a déclaré n’avoir « jamais trouvé lui-même ce type de vulnérabilité », soulignant sa surprise face aux performances de Claude Code

  • Méthode de détection des vulnérabilités par Claude Code

    • Claude Code détecte des failles de sécurité dans le noyau Linux avec très peu de supervision
      • Carlini lui a simplement donné un prompt du type « Où se trouve la faille de sécurité ? » et l’a configuré pour parcourir l’ensemble des fichiers sources du noyau
    • Le script utilisé simulait, pour chaque fichier, une situation de CTF (compétition de hacking) et demandait à Claude Code d’écrire la vulnérabilité la plus grave dans /out/report.txt
      • Il parcourait tous les fichiers avec la commande find, puis relançait Claude Code pour chaque fichier afin d’y chercher une vulnérabilité
    • Le système était conçu pour éviter les signalements en double d’une même faille, en analysant individuellement tous les fichiers du noyau

  • Vulnérabilité NFS (Network File System)

    • La principale vulnérabilité découverte par Claude Code est un heap buffer overflow dans le pilote Linux NFS, qui permet à un attaquant de lire la mémoire du noyau via le réseau
    • Le scénario d’attaque implique deux clients NFS coopérants (Client A, Client B) ciblant un même serveur NFS
      • Le Client A demande puis obtient un verrou de fichier avec un owner ID long de 1024 octets
      • Ensuite, le Client B demande un verrou sur le même fichier, ce que le serveur refuse en générant un message de réponse
    • Le problème est que le tampon de cette réponse de refus ne fait que 112 octets, alors que le message réel atteint 1056 octets au total avec l’owner ID
      • Le noyau écrit donc 1056 octets dans un tampon de 112 octets, ce qui écrase la mémoire noyau avec des données contrôlées par l’attaquant
    • Lors du signalement de cette faille, Claude Code a même automatiquement généré et inclus un diagramme de protocole en ASCII

  • Pourquoi la faille est restée invisible pendant 23 ans

    • Le bug provient de code introduit dans le noyau Linux en mars 2003
      • À l’époque, le message de commit précisait que NFSD4_REPLAY_ISIZE, un tampon fixe de 112 octets, suffisait pour les opérations NFSv4 comme OPEN ou CLOSE
      • Plus tard, lors de l’ajout de l’opération LOCK, la limite de longueur de l’owner ID n’a pas été prise en compte, ce qui a créé la vulnérabilité
    • Ce code date d’avant l’introduction de Git (2005), et repose donc sur une base si ancienne qu’il n’est même plus possible d’y renvoyer directement par lien

  • Des centaines d’autres vulnérabilités non encore signalées

    • Carlini a découvert des centaines de vulnérabilités potentielles supplémentaires dans le noyau Linux, mais la plupart n’ont pas encore été signalées à cause du goulot d’étranglement de la vérification humaine
      • Il a expliqué qu’« il est impossible d’envoyer aux mainteneurs du noyau des résultats non vérifiés », et qu’il existe donc encore des centaines de crashs non confirmés
    • À ce jour, Carlini a lui-même corrigé ou signalé 5 vulnérabilités
      • nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
      • io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
      • futex: Require sys_futex_requeue() to have identical flags
      • ksmbd: fix share_conf UAF in tree_conn disconnect
      • ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

  • Les progrès de la détection de vulnérabilités fondée sur l’IA

    • Carlini a découvert cette faille avec Claude Opus 4.6 (deux mois avant sa sortie)
      • Il n’avait pas réussi à reproduire le même résultat avec les versions précédentes, Opus 4.1 (il y a 8 mois) et Sonnet 4.5 (il y a 6 mois)
      • Le modèle le plus récent a pu détecter bien davantage de vulnérabilités
    • Selon lui, « dans les prochains mois, chercheurs comme attaquants vont prendre conscience de la puissance de ces modèles d’IA, et une vague de découvertes massives de vulnérabilités va arriver »

  • Présentation et autres informations

    • Ce contenu a été présenté à la conférence [un]prompted AI security conference 2026
    • Ce cas de découverte par Claude Code est considéré comme une démonstration du fait que l’IA peut réellement augmenter de manière spectaculaire la productivité de la recherche en sécurité

À lire aussi

2 commentaires

 
m3op0w94 23 일 전

Version optimiste : découverte d’une vulnérabilité Linux
Version désespérante : suppression du bouncing de curl
 
GN⁺ 26 일 전
Avis Hacker News

  • Rien de surprenant. En revanche, ce que l’article ne mentionne pas, c’est que Claude Code a aussi trouvé 1 000 faux positifs, et qu’il a fallu 3 mois aux développeurs pour les filtrer

    • Ce n’est plus comme ça que ça fonctionne maintenant. Les LLM filtrent eux-mêmes les bugs non reproductibles dans un pipeline secondaire. Vérifier si une vulnérabilité est réellement exploitable est bien plus facile que de la trouver, donc au final il ne reste presque que de vrais bugs, avec une précision proche de 100 %. Il y a encore beaucoup de gens qui nient les progrès des LLM, mais il est difficile de nier leur utilité
    • Je serais curieux de connaître la source. Je n’ai jamais vu passer ça. D’après mon expérience, le taux de faux positifs de détection de vulnérabilités de Claude Opus 4.6 était inférieur à 20 %
    • Les outils d’analyse statique/dynamique trouvent eux aussi toujours des vulnérabilités. La plupart des grands projets ont déjà un backlog d’issues déversé par des scanners. Le vrai problème, c’est d’identifier celles qui sont réellement dangereuses. Que Claude ait trouvé un vieux bug est intéressant, mais ça arrive toujours quand un nouveau scanner sort
    • L’article ne dit pas qu’il y a beaucoup de faux positifs. Au contraire, il mentionne qu’« il y a trop de bugs pas encore vérifiés »
    • La leçon, ce n’est pas que Claude Code est inutile, mais que c’est un outil puissant entre de bonnes mains

  • Coller d’un coup du nouveau code et demander à Claude « qu’est-ce que j’ai oublié ? où sont les bugs ? » est une approche très convaincante pour des développeurs qui débutent avec l’IA. Il trouve surtout rapidement les bugs de threading ou de systèmes distribués. À ce stade, j’imagine que des montagnes de code crypto sont en train d’être analysées

    • J’aime bien biaiser le prompt pour pousser Claude à partir du principe qu’il y a un bug. Je demande « il y a un bug dans ce code, peux-tu le trouver ? » ou j’ajoute « le bug n’est pas évident », et ça a amélioré mon taux de réussite
    • Moi aussi, j’utilise presque toujours CC/codex comme ça
    • Je m’en sers en demandant quelque chose comme « c’est du code écrit par Codex, tu vois quelque chose d’étrange ? »

  • Plutôt qu’un bug « caché », il serait plus juste de dire que « personne n’avait regardé ». Le code écrivait 1056 octets dans un buffer de 112 octets. C’est le genre de problème qu’un analyseur statique peut repérer facilement, mais si on demande à un LLM de « vérifier tous les buffers à taille fixe », on risque aussi d’obtenir des hallucinations. Cela reste quand même un bon point de départ

    • La plupart des vulnérabilités subsistent parce que « personne n’avait regardé ». La complexité des systèmes s’accumule et devient difficile à suivre pour les humains. Si cela peut résoudre ce problème, c’est une grande nouvelle. Les analyseurs statiques signalent tous les chemins possibles de copie de buffer, mais comme les entrées sont souvent limitées en pratique, cela fonctionne mal sur le noyau Linux
    • En réalité, si « personne n’avait regardé », c’est surtout par manque de main-d’œuvre. Le nombre de personnes et le temps disponibles pour trouver des vulnérabilités open source étaient limités. Mais maintenant que les modèles deviennent suffisamment compétents, cette limite commence à céder. Cette année s’annonce très intéressante
    • On dit qu’un analyseur statique aurait pu le trouver facilement, mais dans les faits, personne ne l’a trouvé pendant plus de 20 ans. C’est amusant de voir qu’à chaque fois qu’un LLM fait quelque chose d’impressionnant, la réaction est toujours « ce n’est pas si extraordinaire »

  • Fait intéressant, 3 à 4 des 5 bugs trouvés auraient été atténués par les patchs linux-hardened, par exemple désactivation de io_uring, crash du noyau en cas de UAF, prévention de l’exploitation des heap overflows, etc.

  • C’est assez drôle comme annonce : « on publie une arme dangereuse, alors aidez-nous à rendre le monde plus sûr — mais payez un abonnement ». On dirait un biochimiste qui relâche une bombe chimique puis dit « payez pour qu’on vous aide à vous en protéger ». L’industrie logicielle est vraiment ironique en ce moment

    • Ça n’a aucun sens. Comparer la recherche et le signalement de vulnérabilités à la diffusion d’armes biochimiques, c’est complètement excessif

  • J’ai reproduit l’expérience sur plusieurs bases de code en production, et il y avait beaucoup de doublons, faux positifs et bugs non exploitables. Cela dit, il y avait aussi pas mal de vulnérabilités critiques (crit) bien réelles

  • Pendant la session de questions-réponses, je me demandais ce qu’était cette vidéo diffusée en arrière-plan. C’était une démo d’exploit utilisant un bug NFS via un réseau USB ?

  • C’est un travail connexe de notre labo de sécurité. Rien que cette année, nous avons découvert 23 vulnérabilités avec des agents de sécurité IA

  • Les réserves de 0-day des agences à trois lettres (services de renseignement) risquent de diminuer fortement

  • N’attendez pas davantage de rapports de vulnérabilités à l’avenir ; attendez-vous plutôt à davantage de tentatives d’attaque