- Retour d’expérience sur la découverte d’une vulnérabilité 0-day à distance (CVE-2025-37899) dans l’implémentation SMB du noyau Linux à l’aide du modèle OpenAI o3
- Lors d’un benchmark des capacités d’analyse de code des LLM sur le code de ksmbd, une comparaison a été menée à partir d’une vulnérabilité déjà trouvée manuellement
- Pour la détection de vulnérabilités, le contexte a été construit fonction par fonction avec des prompts adaptés afin de permettre à o3 d’identifier la faille
- Les résultats montrent qu’o3 détecte les vulnérabilités avec une précision 2 à 3 fois supérieure à celle des LLM précédents, tout en découvrant automatiquement un nouveau type de bug use-after-free
- Les LLM, et en particulier les modèles récents comme o3, montrent une souplesse et une créativité proches de l’approche humaine en audit de code et en recherche de vulnérabilités, ce qui renforce leur valeur en pratique
Introduction
Cet article présente comment une vulnérabilité 0-day à distance a été découverte dans l’implémentation SMB du noyau Linux (ksmbd) à l’aide du modèle o3 d’OpenAI. L’expérience a été menée en utilisant uniquement l’API d’o3, sans framework ni outil supplémentaire. ksmbd est le serveur qui implémente le protocole SMB3 dans le noyau Linux et gère le partage de fichiers sur le réseau. Un benchmark a été lancé pour mesurer la capacité réelle d’o3 à trouver des bugs, à l’occasion d’un audit de vulnérabilités commencé comme une pause vis-à-vis du développement autour des LLM. L’accent est mis ici sur la vulnérabilité zero-day CVE-2025-37899 trouvée par o3.
Cette vulnérabilité est un problème de use-after-free qui se produit lors du traitement de la commande SMB logoff. Elle exige de comprendre à la fois les connexions concurrentes au serveur et la manière dont plusieurs threads partagent certains objets. o3 a détecté la faille en identifiant, dans son contexte, ce problème de concurrence et cette erreur de gestion d’objet. Il s’agit du premier cas public connu où un LLM découvre ce type de vulnérabilité.
Le message principal est qu’o3 montre un véritable saut qualitatif dans les capacités d’analyse de code et de raisonnement des LLM, et que les chercheurs en vulnérabilités doivent impérativement suivre cette évolution. Les LLM ne remplacent pas les experts, mais ils sont déjà devenus des outils capables d’augmenter radicalement la productivité et l’efficacité des spécialistes. Sur des bases de code de moins de 10 000 lignes, o3 peut apporter une aide concrète pour détecter et résoudre la plupart des problèmes.
Benchmark d’o3 à partir de CVE-2025-37778
Contexte et objectif du benchmark
Pour commencer, les capacités de détection de vulnérabilités d’o3 ont été évaluées en prenant comme point de référence CVE-2025-37778, une vulnérabilité découverte manuellement auparavant (ci-après la vulnérabilité d’authentification Kerberos). Il s’agit d’un problème où un use-after-free survient dans le processus d’authentification du client lorsque l’état de la session remplit certaines conditions.
- Lorsque l’état de la session est
SMB2_SESSION_VALID, l’objet utilisateur est libéré de la mémoire - Si l’authentification échoue ensuite, l’objet utilisateur n’est pas réinitialisé, et il devient possible d’y accéder dans cet état, provoquant un use-after-free
- Il faut suivre environ 3 300 lignes de code pour comprendre l’ensemble du chemin concerné, ce qui en fait une tâche de benchmark d’une difficulté raisonnable
Construction du contexte d’analyse
Dans l’expérience, le contexte fourni au LLM — c’est-à-dire la zone de code — a été soigneusement construit du point de vue d’un système automatisé de détection de vulnérabilités. Pour chaque gestionnaire de commande SMB, les fonctions principales et leurs sous-fonctions ont été incluses jusqu’à une profondeur d’appel de 3 niveaux, de façon à fournir l’ensemble du code logiquement lié (soit 3,3k LoC au total, environ 27k tokens). Il faut aussi inclure les fonctions liées à l’analyse des données, au branchement des requêtes et à la déconnexion pour obtenir des résultats fiables.
Les prompts précis et les données d’entrée utilisées peuvent être consultés dans le dépôt Github associé. Les conditions suivantes ont été données au LLM :
- instruction explicite de détecter les vulnérabilités de type use-after-free
- brève explication de la structure de base de ksmbd et du modèle de menace
- utilisation de prompts d’orientation pour éviter les faux positifs (False Positive)
Les requêtes réelles ont été exécutées de manière répétée via l’outil en ligne de commande llm, et les résultats expérimentaux ont été collectés ainsi (N=100).
Résultats du benchmark
- o3 : détection de la vulnérabilité d’authentification Kerberos 8 fois sur 100, 66 non-détections (omissions), 28 faux positifs signalés
- Claude Sonnet 3.7 : seulement 3 détections
- Claude Sonnet 3.5 : échec de détection sur les 100 essais
Au final, o3 affiche une précision 2 à 3 fois supérieure à celle des LLM précédents. En outre, la sortie d’o3 est concise, à la manière d’un rapport de synthèse rédigé par un chercheur en sécurité humain. À l’inverse, les résultats de Sonnet 3.7 donnent davantage l’impression d’un journal de travail centré sur le processus, avec à la fois des avantages et des inconvénients.
Découverte d’un vrai 0-day avec o3 (CVE-2025-37899)
Expérience dans un environnement de code en entrée à grande échelle
Au-delà de la vulnérabilité Kerberos, une tentative de détection globale a été menée avec o3 en incluant l’ensemble des gestionnaires de commandes SMB (environ 9 000 lignes). En ajoutant tous les gestionnaires ainsi que le code de connexion/déconnexion, environ 12k LoC au total (près de 100 000 tokens) ont été fournis en une seule fois. Lors de 100 exécutions répétées, la vulnérabilité d’authentification Kerberos n’a été détectée qu’une seule fois, ce qui montre clairement une baisse de performance, mais l’objectif principal était d’évaluer l’utilité des LLM sur un périmètre de code plus large.
Nouvelle vulnérabilité découverte dans cette expérience
C’est dans ce contexte qu’o3 a découvert, en plus du problème d’authentification Kerberos, un nouveau bug de type use-after-free. Il se situe dans le gestionnaire logoff de la session : dans une situation de connexions concurrentes avec deux threads, l’objet user d’une session est partagé et consulté en parallèle ; un thread libère l’objet, tandis que l’autre peut continuer à le référencer, ce qui constitue un problème de concurrence.
Résumé du rapport automatique d’o3 sur la vulnérabilité
- Deux threads worker coopèrent : l’un exécute la libération de session (
logoff) et libère l’objet utilisateur en mémoire, tandis que l’autre continue d’utiliser cet objet utilisateur dans la session existante - Si un dereference survient par un autre chemin juste après la libération (avant l’initialisation à NULL), on obtient un use-after-free classique
- Selon le timing, un NULL dereference peut également se produire et entraîner un DoS
- Cela peut mener à une corruption de la mémoire du noyau et à l’exécution de code arbitraire
Enseignements tirés du rapport automatique
Ce rapport automatique a permis de comprendre que la méthode de correction de la vulnérabilité d’authentification Kerberos — définir la valeur à NULL juste après la libération — n’est pas une solution fondamentale dans le cas du traitement du logoff. Autrement dit, la sécurité ne peut être garantie qu’en prenant en compte la liaison de session et les vecteurs d’attaque inter-threads. Dans certains rapports, o3 a lui aussi identifié ce point et a démontré qu’il était capable de proposer une correction plus robuste.
Conclusion
Les LLM, et en particulier les modèles récents comme o3, montrent des performances bien plus proches de celles d’un chercheur en sécurité humain que les approches existantes en matière d’analyse créative et flexible du code. Jusqu’à récemment, cette possibilité relevait surtout de la théorie, mais o3 est le premier à avoir atteint, dans un cas réel, un niveau réellement utile en pratique. Bien sûr, o3 reste sujet aux faux positifs et aux omissions, mais la probabilité qu’il produise des résultats réellement exploitables est désormais suffisamment élevée pour justifier son usage en production. Le moment est venu pour les chercheurs en vulnérabilités comme pour les développeurs de trouver comment intégrer efficacement les LLM dans leur flux de travail.
1 commentaires
Avis Hacker News
L’auteur explique qu’il gère son projet en structurant séparément le prompt système, les informations de contexte et les commandes auxiliaires dans des fichiers
.prompt, puis en les exécutant viallmJ’ai l’impression que cette manière d’utiliser les LLM de façon aussi méthodique montre qu’il faut un raisonnement de conception minutieux et un réglage fin des spécifications, presque comme avec n’importe quel autre outil d’ingénierie
Le projet associé est disponible ici
Ce qui est amusant, c’est que l’auteur reconnaît franchement à ce sujet que « tout mon prompt système repose en fait sur des suppositions, et c’est loin de la science ou de l’ingénierie »
Il existe différentes façons d’écrire des prompts, mais sans véritable critère pour les évaluer ou les comparer, cela ressemble presque à une incantation improvisée
Par exemple, des instructions comme « tu es un expert en recherche de vulnérabilités », « indique-moi uniquement de vraies vulnérabilités, pas des fausses », ou encore le fait de délimiter avec des balises HTML arbitraires auxquelles le modèle est censé bien réagir
On peut se demander où se situe réellement la part d’ingénierie
Je trouve amusant qu’on invoque des principes d’ingénierie pour tenter de contrôler des systèmes intrinsèquement instables et imprévisibles
Pour ce genre de prompts, le terme « indice » serait sans doute plus approprié
Tous les LLM actuels ont souvent tendance à ignorer le prompt si nécessaire, car leur objectif fondamental reste de fournir une réponse coûte que coûte (qu’elle soit vraie ou non), même quand le prompt est contradictoire
Le billet mentionne un rapport signal/bruit d’environ 1:50, et je pense que l’auteur a pu repérer les signaux pertinents parce qu’il connaissait très bien la base de code
C’est justement l’automatisation de cette identification du signal utile qui me semble être le vrai jackpot potentiel des LLM, donc je vais suivre les évolutions à venir avec intérêt
Nous développons justement un système pour améliorer ce problème de rapport signal/bruit, et nous benchmarkons aussi directement les agents logiciels récents les plus populaires
La variance des résultats est énorme, et nous prévoyons de publier tous nos résultats expérimentaux lors d’une conférence prochaine
Cela devrait offrir une bonne vue d’ensemble de l’état de l’art dans le secteur
Une idée m’est venue il y a quelques jours : ne pourrait-on pas exploiter tout l’historique du noyau Linux, y compris tous les changements git, les mailing lists, etc., pour faire évoluer un modèle fine-tuné ?
Un tel LLM pourrait réellement devenir une version synthétique plus proche de l’intuition d’un développeur ayant travaillé longtemps sur le code
Rien qu’avec un contexte très long, on peut déjà couvrir beaucoup de choses, et certaines bases de code dépassent à elles seules 200 000 tokens, donc cela me semble plausible
Un ratio de 1:50 est en réalité un très bon taux de détection dans une situation de type « chercher une aiguille dans une botte de foin »
Si le LLM écrivait lui-même le harness et les tests de preuve de concept pour valider chaque vulnérabilité supposée, le rapport signal/bruit s’améliorerait énormément
Mais aujourd’hui, ce niveau d’automatisation coûte encore assez cher, ce qui est regrettable
Ce qui m’a le plus impressionné, c’est que l’auteur a répété 100 fois la recherche de vulnérabilités pour plusieurs modèles de LLM
C’est un niveau d’investissement en ressources bien supérieur à celui que j’ai consacré jusque-là à la plupart de mes problèmes avec les LLM, et maintenant je me demande si je ne devrais pas moi aussi confier un peu de « force brute » au modèle
Au final, la conclusion est qu’il faut beaucoup d’argent
Les vulnérabilités zero-day se vendent à des montants considérables, et on peut aussi gagner de l’argent avec les bug bounties
Le coût d’usage des LLM est minime en comparaison de ces récompenses
Le paysage de la sécurité dans un futur où le coût de l’inférence sera proche de zéro sera complètement différent
Lancer 100 exécutions par modèle signifie aussi une consommation d’énergie importante
Quand il faut mobiliser autant de ressources pour trouver une vulnérabilité assez classique dans du code en C, cela finit par lui retirer de sa valeur et met surtout en avant le gaspillage et le luxe
Vu la crise climatique mondiale actuelle, il est difficile de ne pas s’inquiéter de voir encore brûler des ressources pour des tâches de faible valeur, comme dans les années 1950
Comme Claude ne disposait pas d’un scratchpad séparé pour organiser sa réflexion intermédiaire, je pense que son cheminement de pensée s’est mélangé au rapport final
J’aimerais tester à quel point Claude changerait si on lui donnait officiellement un espace autorisé pour structurer sa réflexion
Là où o3 transmet surtout l’essentiel sous une forme épurée, comme un rapport de bug rédigé par un humain, les résultats de Sonnet 3.7 conservent davantage un flux de pensées ou un journal de travail
J’ai utilisé moi-même o3, 3.7 et Gemini 2.5 pro, et mon impression est qu’o3 est à un niveau incomparable
Les scores de benchmark peuvent ne pas sembler énormes, mais plus la tâche est complexe, plus cet écart devient significatif
Je me demande pourquoi il a été annoncé en novembre dernier mais n’est sorti qu’il y a environ un mois seulement (sans doute pour des raisons de sécurité), et j’attends déjà o4 avec impatience
Je me demande si quelqu’un pourrait recommander des cas d’usage, des articles ou des liens sur l’utilisation du « scratchpad » dans la recherche
J’aime beaucoup à quel point cela résume bien l’essence du prompt engineering
En particulier la partie qui dit en substance : « j’ai fait de mon mieux pour guider le modèle afin qu’il n’indique pas à tort de faux positifs comme vulnérabilités, mais je n’ai aucun moyen de savoir si cela aide réellement et j’espère seulement que oui ; je n’ai pas encore assez évalué l’efficacité, donc ce n’est ni de la science ni de l’ingénierie, je partagerai l’évaluation plus tard » — cela ressemble énormément à ma propre façon de développer des prompts
Je me demande si ce domaine (la détection automatisée de vulnérabilités) n’est pas le cas d’usage le plus adapté aux LLM
En théorie, on pourrait automatiser tout le processus, traiter le LLM comme un fuzzer très avancé, faire tourner en continu la cible dans une VM et détecter la possibilité d’une vraie vulnérabilité dès qu’un comportement anormal apparaît
(Il faut se rappeler que la plupart des exploits initiaux commencent par faire tomber une machine ou provoquer un crash avant d’être améliorés)
D’un côté, ce type d’usage des LLM semble très pertinent, mais d’un autre côté il suggère aussi que « le fait que nous puissions faire ce genre de tests ne révèle pas forcément quelque chose de radicalement nouveau ou décisif »
Je partage une vidéo YouTube de ma présentation sur le ciblage automatisé des bugs zk (liés aux preuves à divulgation nulle de connaissance)
Les paramètres supplémentaires servent essentiellement au tracking des liens
J’espère sincèrement qu’on n’ira pas vers une répétition du genre de problèmes qui continuent à frapper curl
Pour le contexte, voir le billet de Daniel Stenberg
Si j’ai bien compris, ksmbd est connu comme un serveur SMB en espace noyau, plus léger et plus performant que le serveur Samba traditionnel
Q1 : qui utilise réellement ksmbd en production ?
Q2 : pourquoi l’utiliser ?
Quelqu’un sait-il si cela prend en charge nativement les ACL comme sous Windows ?
(C’était la dernière raison pour laquelle on continuait à faire tourner Solaris, et il me semble que c’était pris en charge via ZFS)
Samba reste encore coincé dans un modèle dépassé de synchronisation avec les UID/GID Unix et son modèle de sécurité
Cela dit, les serveurs SMB dans le noyau ont aussi déjà connu de graves vulnérabilités de type remote root sur Windows, donc il faut bien mesurer les compromis
C’est à cause d’un problème de licence
Samba est sous GPLv3, alors que Linux ne peut utiliser que la GPLv2
J’imagine qu’on l’utilise simplement parce que c’est léger et performant
Je pense que c’est pour une raison similaire à celle qui pousse à utiliser kmod-trelay plutôt que relayd
Je pense que le plus grand défi à court terme des LLM, en matière d’Alignment Problem, se manifeste justement dans ce genre d’automatisation des vulnérabilités
J’ai récemment trouvé, presque sans effort à l’aide d’un LLM, une faille de sécurité vraiment grave sur un serveur de niche que j’utilise de temps en temps
Si ce marché s’automatise, on risque de voir apparaître en masse de graves problèmes dans toutes sortes de logiciels de longue traîne qui, auparavant, ne valaient pas l’effort d’être attaqués manuellement
À l’inverse, grâce à ce progrès technologique, nous pouvons nous aussi analyser automatiquement notre propre base de code d’un point de vue « adversarial »
Cela offre une chance de corriger à l’avance des vulnérabilités qui, autrement, auraient été découvertes par des chercheurs puis exploitées
C’est pourquoi il ne me semble pas très approprié d’appeler cela un problème d’alignement
Les attaquants peuvent automatiser la détection de vulnérabilités, mais les défenseurs peuvent eux aussi disposer de cette capacité
Il devient même possible d’intégrer cette automatisation défensive au processus de validation des commits ou à chaque build