o3 d'OpenAI découvre une vulnérabilité zero-day dans Linux (et c'est une première mondiale)
-
Aaaah si seulement on avait des stagiaires en cybersécurité capable de lire 100 000 lignes de code en quelques secondes et de repérer des indices que même les experts ratent.
Et bien c’est exactement ce que o3 d’OpenAI vient de faire en découvrant la CVE-2025-37899, une vulnérabilité critique dans le noyau Linux que personne n’avait encore vue. Et d’après son auteur, cette découverte, c’est une première mondiale car jamais auparavant une IA n’avait trouvé une vulnérabilité zero-day de cette complexité dans un composant aussi critique.
Et le plus dingue c’est que Sean Heelan, le chercheur en sécurité qui auditait le code, avait lui-même raté cette faille. o3 l’a donc trouvée en analysant simplement le code source, sans scaffolding complexe, sans framework agentique, juste en lisant et en comprenant son fonctionnement.
La vulnérabilité se trouve dans ksmbd, le serveur SMB implémenté directement dans la partie du noyau Linux qui permet de partager des fichiers sur réseau. C’est un use-after-free dans le gestionnaire de la commande SMB “logoff”. Pour ceux qui ne parlent pas couramment cette langue cheloue, c’est comme utiliser l’adresse de votre ancien appart après avoir déménagé : techniquement l’adresse existe toujours, mais ce qui s’y trouve maintenant n’a plus rien à voir avec vos affaires. Sauf qu’ici, on parle de mémoire du kernel, et les conséquences peuvent aller jusqu’à l’exécution de code arbitraire.
Ce qui rend cette découverte exceptionnelle, c’est la complexité du raisonnement nécessaire à sa découverte. o3 a dû pour cela comprendre comment deux connexions SMB distinctes peuvent partager la même session grâce au session binding de SMB 3.0, analyser les interactions entre threads concurrents, et identifier qu’un objet critique est libéré par un thread pendant qu’un autre thread l’utilise encore. C’est le genre de bug qui demanderait normalement de comprendre au minimum 3300 lignes de code et leurs interactions subtiles.
Et les chiffres parlent d’eux-mêmes car quand on donne à o3 le code de gestion des sessions SMB (~27k tokens), il trouve cette vulnérabilité dans 8 runs sur 100. Claude Sonnet 3.7 ? 3 sur 100. Claude 3.5 ? Zéro pointé. On n’est plus dans la même cour de récré.
Voici donc concrètement ce qui se passe dans cette vulnérabilité. Le code problématique se trouve dans la fonction de déconnexion de session :
if (sess->user) { ksmbd_free_user(sess->user); // (1) libère la mémoire sess->user = NULL; // (2) remet le pointeur à NULL }Ça paraît clean comme code, non ? Le problème, c’est que SMB 3.0+ permet à plusieurs connexions de partager la même session via le “session binding”. Un scénario parfait pour l’attaquant se déroulerait comme ceci :
- Thread A (connexion C2) traite une requête normale (READ, WRITE, peu importe)
- Thread B (connexion C1) reçoit une commande LOGOFF pour la même session
- Thread B exécute la libération mémoire et détruit l’objet utilisateur
- Thread A continue son traitement et essaie d’accéder à l’objet… qui vient d’être libéré
Bim ! Use-after-free dans le kernel. Et le pire c’est que le code attend bien la fin des opérations avec une fonction dédiée, mais seulement pour SA propre connexion, pas pour les autres connexions qui utilisent la même session.
o3 a non seulement repéré ce bug, mais il a aussi compris que la fenêtre temporelle entre la libération mémoire et la remise à zéro du pointeur était exploitable. Plus fort, quand Sean Heelan avait trouvé une vulnérabilité similaire dans le code d’authentification Kerberos, il avait proposé un fix qui ne prenait pas en compte le session binding. o3, lui, a réalisé que mettre le pointeur à NULL ne suffisait pas et a proposé une correction plus robuste.
L’IA vient donc littéralement de corriger l’expert humain.
On assiste vraiment à un changement fondamental dans l’écosystème de la cybersécurité. En effet, durant des décennies, la recherche de vulnérabilités était l’apanage d’une élite d’experts capables de jongler avec du code assembleur et de raisonner sur des interactions système complexes. Les outils automatisés traditionnels (fuzzing, analyse symbolique, scan statique) étaient puissants mais très rigides, incapables de faire les liens conceptuels qu’un humain fait naturellement.
Et voilà que o3 change la donne parce qu’il combine créativité, flexibilité et généralité tout comme un humain, tout en gardant la vitesse et l’endurance d’une machine. Sean Heelan le dit mieux que moi :
Les LLM existent à un point de l’espace des capacités qui est bien plus proche des humains que tout ce qu’on a vu auparavant.
Et les chiffres le prouvent. Avec un ratio de 1:4.5 entre vrais et faux positifs, on est dans du exploitable dès aujourd’hui. Concrètement, ça veut dire qu’au maximum, vous devrez éplucher 5 faux positifs pour tomber sur une vraie vulnérabilité. C’est déjà mieux que beaucoup d’outils traditionnels, et ça ne fait que commencer. Plus impressionnant encore, o3 peut traiter des problèmes représentables en moins de 10k lignes de code avec des chances réelles de les résoudre ou d’aider significativement à les résoudre. Pour donner une idée d’échelle, l’audit complet du path d’exploitation de cette vulnérabilité représente exactement 3.3k lignes de code. On est pile dans la zone de confort de l’IA.
Si vous travaillez dans la recherche de vulnérabilités, vous devriez donc commencer à faire très attention car on n’est plus dans le “peut-être qu’un jour l’IA sera utile”, au contraire, on est dans le “l’IA est déjà utile, maintenant”.
Bien sûr, ça ne veut pas dire que les experts vont disparaître mais qu’au contraire, ils vont devenir “beaucoup plus efficaces”. Hop, vous faites un premier passage automatisé sur vos audits de code, avec une IA qui vous sort les suspects les plus probables et ensuite, à vous de tester vos hypothèses de vulnérabilités sur des composants complexes sans passer des heures à décortiquer le code. L’IA peut raisonner sur la concurrence, les race conditions, et les subtilités d’allocation mémoire, ce qui veut aussi dire que pour les RSSI, ça va permettre d’auditer automatiquement les repo internes avec un niveau de détail jusqu’ici impensable.
Pour les développeurs, ça signifie également l’intégration d’analyses de sécurité poussées directement dans les pipelines CI/CD et pour les chercheurs en sécurité eux-même, c’est, comme je le disais, un multiplicateur de force qui permet de se concentrer sur les vulnérabilités les plus critiques.
Et avec l’amélioration continue des modèles, on va voir des ratios signal/bruit qui s’améliorent, des fenêtres de contexte qui s’élargissent, et des capacités de raisonnement qui se renforcent…. Ainsi dans 2/3 ans, n’importe quel développeur pourra avoir accès à un niveau d’analyse de sécurité qui était jusqu’alors réservé aux pentesteurs les plus expérimentés.
– Sources :
https://korben.info/ia-o3-vulnerabilite-zero-day-linux-premiere.html
-
lol vive Windaube
