Mille chemins de moins vers l’accès root

La recherche en sécurité, qui exigeait autrefois une investigation distincte et soutenue pour chaque découverte, peut de plus en plus prendre la forme d’un processus systématique. Ce document présente l’un de nos travaux dans ce domaine.

Il devient plus facile de rechercher des vulnérabilités à grande échelle, mais leur priorisation et leur validation restent des goulots d’étranglement opérationnels. Nous avons créé un prototype pour rechercher des failles de sécurité dans le noyau Linux au sein d’un environnement de recherche contrôlé. Notre prototype a repéré et analysé 2 308 vulnérabilités potentielles du noyau Linux, reproduit dynamiquement 1 724 vulnérabilités et produit 948 exploits d’élévation locale de privilèges (LPE) susceptibles de permettre à un utilisateur local non privilégié d’obtenir un accès root.

Nous avons utilisé ces éléments pour prioriser les vulnérabilités à signaler et élaboré des propositions de correctifs à soumettre aux responsables de maintenance. Conformément aux recommandations de la communauté du noyau Linux, nous avons commencé par les vulnérabilités critiques et travaillons avec les partenaires de Patch the Planet sur d’autres rapports et correctifs.

En juin, dans le cadre de notre initiative Patch the Planet, nous avons annoncé que GPT‑5.5 Cyber avait repéré des vulnérabilités du noyau Linux et développé 24 exploits d’élévation locale de privilèges pour les valider et les signaler. Nous avons étendu ces travaux à un pipeline, alimenté par un futur modèle de cybersécurité, couvrant la découverte de vulnérabilités, la validation dynamique, l’évaluation de l’exploitabilité et la génération de correctifs. À l’issue de son exécution, des chercheurs humains ont examiné les résultats et signalé les vulnérabilités découvertes en joignant les correctifs.

Le noyau Linux est à la base des appareils Android, des infrastructures cloud, des supercalculateurs et d’autres systèmes utilisés par des milliards de personnes. Avec plus de 40 millions de lignes de code, le noyau expose une vaste surface d’attaque via les appels système, les fonctions réseau, les systèmes de fichiers et les pilotes de périphériques. Nous avons choisi Linux pour étudier l’efficacité des modèles de pointe à découvrir des vulnérabilités et à démontrer leur impact sur la sécurité dans une base de code de cette ampleur et de cette importance.

L’étape initiale de découverte a produit des milliers de vulnérabilités potentielles, trop nombreuses pour que les chercheurs en sécurité puissent les examiner et les trier manuellement. Le défi opérationnel de notre pipeline de découverte de vulnérabilités n’était pas la découverte elle-même, mais la détermination des vulnérabilités reproductibles, des frontières de sécurité qu’elles franchissaient et de celles qui devaient retenir en priorité l’attention des responsables de maintenance.

La mission de l’équipe Cyber d’OpenAI est de contribuer à sécuriser les logiciels dont le monde dépend. Nous indiquons les coûts API de chaque étape pour aider les chercheurs à évaluer les ressources nécessaires pour reproduire et prolonger ces travaux. Ces coûts reflètent les modèles, les configurations cibles et le workflow utilisés dans cette évaluation. Notre objectif plus large est d’aider les défenseurs à trouver et à corriger les vulnérabilités, en réduisant les possibilités offertes aux attaquants et en augmentant le coût d’exploitation des logiciels pour ces derniers.

Enfin, notons que ces recherches se sont concentrées sur la méthodologie et la mesure des capacités des modèles, et non sur le coût. Nous estimons qu’un travail d’ingénierie suffisant sur le harnais pourrait réduire sensiblement le coût de chaque étape ; les coûts présentés constituent donc plutôt une borne supérieure.

Notre prototype de recherche de vulnérabilités est un pipeline en cinq étapes, reposant sur un futur modèle de cybersécurité :

• Découverte de vulnérabilités : les agents repèrent les parties de la base de code pertinentes pour la sécurité et les analysent à la recherche de vulnérabilités potentielles.

• Validation dynamique : les agents tentent de reproduire chaque vulnérabilité potentielle dans un environnement isolé et conservent les preuves d’exécution. Cette étape produit les vulnérabilités reproduites et validées.

• Évaluation de l’exploitabilité : les agents vérifient si les vulnérabilités validées peuvent permettre une divulgation d’informations ou une élévation locale de privilèges.

• Génération de correctifs : les agents génèrent des correctifs pour chaque vulnérabilité identifiée.

• Examen humain : les chercheurs en sécurité examinent l’exploit, le correctif et le niveau de gravité proposé avant de transmettre le rapport aux responsables de maintenance.

À la fin du pipeline, le système regroupe une analyse de la cause racine, une preuve de concept minimale provoquant un plantage, une proposition de correctif et un exploit complet pour aider les chercheurs humains à évaluer la gravité de la vulnérabilité et à faire intégrer les correctifs en amont.

Toutes les lignes de code du noyau Linux ne sont pas pertinentes pour la sécurité. Notre pipeline a utilisé une équipe d’agents éclaireurs pour repérer les cibles d’audit à forte valeur, ensuite transmises à des agents analystes pour y rechercher des vulnérabilités.

Les agents éclaireurs parcourent chaque dossier et fichier, puis déterminent les cibles à auditer selon leur accessibilité aux utilisateurs peu privilégiés et leur pertinence pour la sécurité.

Cette étape a permis de repérer 5 034 cibles d’audit, soit environ 2,8 millions de lignes de code, représentant environ 7 % de l’ensemble du code du noyau Linux. Elle a ainsi nettement réduit le coût de l’audit de sécurité par rapport à une analyse de toute la base de code. Cette étape a coûté 3 426 $ en crédits API.

Les agents analystes ont ensuite analysé chaque cible d’audit et signalé des vulnérabilités potentielles selon un workflow similaire à celui du plugin Codex Security⁠(ouverture dans une nouvelle fenêtre). Dans les grandes lignes, les agents analystes lisent le code de la cible d’audit qui leur est attribuée pour comprendre son fonctionnement, déterminer son modèle de menace et y rechercher des vulnérabilités.

En 12 heures, les agents analystes ont signalé 2 308 vulnérabilités potentielles après déduplication. Cette étape a coûté 316 549 $ en crédits API.

Une vulnérabilité potentielle n’est pas une vulnérabilité validée. À cette échelle, notre équipe de recherche ne peut pas examiner manuellement chaque rapport.

Nous avons donc concentré la validation sur les vulnérabilités qui a) étaient accessibles à un utilisateur peu privilégié, b) ne nécessitaient aucune capacité spéciale et c) produisaient des preuves mesurables de corruption mémoire.

Pour chaque vulnérabilité potentielle, un agent de triage a généré une preuve de concept et l’a exécutée dans une machine virtuelle isolée utilisant un noyau Linux doté de Kernel Address Sanitizer (KASAN). L’agent a observé à la fois la sortie du programme et la console système, puis affiné la preuve de concept par itérations jusqu’à reproduire le comportement signalé ou épuiser les moyens possibles de le déclencher.

En 30 heures, notre système a reproduit 1 724 vulnérabilités, soit environ 74,7 % des 2 308 vulnérabilités potentielles. L’examen statique du code peut, à lui seul, produire des faux positifs. Nous avons donc été impressionnés par la précision des agents analystes et l’efficacité des agents de triage, qui ont créé de manière autonome des preuves de concept fonctionnelles pour près des trois quarts des vulnérabilités potentielles.

La plupart des vulnérabilités restantes nécessitaient des privilèges élevés ou n’ont pas pu être reproduites dans le temps imparti en raison de conditions de concurrence difficiles, de conditions de déclenchement spécifiques (par exemple, un échec d’allocation requis à une ligne précise) ou d’une validation chronophage (par exemple, un rebouclage du compteur de références). Seules 3,1 % correspondaient à une analyse incorrecte du modèle, où la vulnérabilité signalée supposait une condition impossible.

L’étape de validation a coûté au total 73 330 $ en crédits API. Nous avons constaté que, dans notre pipeline de validation, où il fallait générer une preuve de concept pour confirmer la réalité d’une vulnérabilité potentielle, ce processus coûtait plus cher qu’une recommandation fondée uniquement sur l’analyse statique. Les coûts des tentatives de validation d’un vrai positif et d’un faux positif étaient similaires. Éliminer les faux positifs plus tôt dans le pipeline rend donc le processus nettement plus économique.

La validation établit qu’une vulnérabilité est réelle, mais pas le degré d’urgence de sa correction. Une vulnérabilité susceptible de permettre une élévation locale de privilèges, par exemple, mérite une priorité plus élevée qu’une vulnérabilité ne pouvant provoquer qu’un déni de service local. Avec 1 724 vulnérabilités validées, la tâche suivante consistait à repérer celles dont l’impact potentiel sur la sécurité était le plus important.

Un agent de présélection a effectué un examen statique de chaque rapport, journal de plantage et portion de code source pertinente. Il était délibérément permissif pour éviter d’écarter des vulnérabilités potentiellement graves, tout en filtrant les cas sans voie d’exploitation plausible. Cette sélection a réduit les résultats à 313 fuites d’informations potentielles et 1 238 élévations locales de privilèges potentielles.

Des agents de développement d’exploits (ExploitDev) ont ensuite testé ces vulnérabilités potentielles dans des machines virtuelles isolées, configurées avec les protections activées par une distribution Linux standard, notamment Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) et HARDENED_USERCOPY. Cela a permis d’éviter des évaluations irréalistes reposant sur la désactivation des protections.

Les agents ont produit 291 preuves de concept de fuite d’informations et 1 169 exploits fonctionnels d’élévation locale de privilèges susceptibles de donner un accès root à des utilisateurs locaux non privilégiés.

Nous avons analysé les variantes et développé 948 correctifs distincts pour les vulnérabilités à l’origine de ces exploits. Nous utilisons ce chiffre pour déterminer le nombre total de LPE distinctes. Le développement des exploits réussis a coûté en moyenne 359 $ en crédits. Les défenseurs peuvent donc tester l’exploitabilité des vulnérabilités découvertes à un coût relativement faible.

L’agent de présélection des vulnérabilités a coûté 44 194 $ en crédits API. L’étape d’exploitation a coûté au total 775 929 $ en crédits API : 84 929 $ pour traiter les fuites d’informations potentielles et 691 000 $ pour les élévations locales de privilèges potentielles.

En moyenne, traiter une élévation locale de privilèges potentielle (558 $) coûtait environ deux fois plus cher que traiter une fuite d’informations potentielle (271 $). En effet, les PoC de fuite d’informations étaient reprises de l’étape de validation et nécessitaient moins de modifications pour être utilisables dans un exploit. À l’inverse, développer un exploit à partir d’une LPE potentielle nécessitait de nombreuses étapes supplémentaires : planifier la stratégie d’exploitation, repérer les objets vulnérables à utiliser, contourner les protections, etc. Nous avons aussi constaté que les tentatives d’exploitation infructueuses (3 922 $ pour 69 cas) coûtaient bien plus cher que les tentatives réussies (360 $ pour 1 169 cas). Cela s’expliquait par quelques vulnérabilités difficiles à exploiter, comme les conditions de concurrence. Définir un critère d’abandon raisonnable, comme arrêter la tentative après une heure sans progrès, aurait considérablement réduit le coût d’ExploitDev.

Pour chaque vulnérabilité validée, le système génère aussi un correctif. Nous fournissons au modèle le code source pertinent et lui indiquons les bonnes pratiques de rédaction des correctifs : effectuer des vérifications statiques du correctif, suivre les pratiques de développement du code environnant et analyser les variantes pour s’assurer que le correctif est complet.

Sur la suggestion de la communauté du noyau Linux, nous avons déjà envoyé des centaines de rapports et de correctifs concernant des vulnérabilités critiques, et nous travaillons avec les partenaires de Patch the Planet pour transmettre progressivement les autres correctifs. Ces travaux s’inscrivent dans notre engagement plus large, Daybreak, en faveur des projets open source.

Dans cette section, nous partageons les enseignements, réflexions et analyses complémentaires issus de ces recherches.

Au cours de ces recherches, nous avons constaté la rapidité avec laquelle les responsables de maintenance de Linux corrigent les vulnérabilités et protègent les utilisateurs. L’analyse a porté sur la dernière version du noyau Linux à la mi-octobre 2026. Au terme des 10 jours d’analyse autonome et manuelle, 61 LPE avaient déjà été corrigées en amont, 43 disposaient de correctifs en préparation et 299 faisaient l’objet de signalements et de discussions publics.

Nous remercions vivement les responsables de maintenance de Linux, qui travaillent dans l’urgence pour corriger les problèmes identifiés, ainsi que l’ensemble de la communauté de la sécurité, qui contribue également par ses découvertes. Cette réponse collective est indispensable pour sécuriser les logiciels du monde entier. Le rythme rapide de divulgation et de correction des vulnérabilités souligne aussi l’importance cruciale, pour les utilisateurs et les entreprises, de maintenir leurs logiciels à jour.

À retenir : le triage automatisé doit tenir compte de la rapidité du cycle de correction. Revalider les vulnérabilités à partir du code le plus récent, y compris celui intégré après l’analyse initiale, permet d’éviter les rapports en double ou obsolètes. Cela concentre l’attention sur les vulnérabilités non résolues et fournit aux responsables de maintenance des éléments exploitables sans alourdir inutilement leur travail d’examen.

Fin juillet 2026, alors que nous développions le pipeline, GPT‑5.6 Sol a découvert et exploité 166 vulnérabilités LPE distinctes, pour un coût total de 513 690 $ en crédits API.

Lors de la deuxième analyse, à la mi-octobre 2026, le modèle de cybersécurité plus récent a découvert et exploité 948 vulnérabilités LPE distinctes, pour un coût total de 1 213 430 $ en crédits API. Pour les deux campagnes, nous avons analysé la dernière version de la branche master du noyau Linux disponible à ce moment-là.

À retenir : réanalysez le code déjà audité à mesure que les capacités des modèles progressent. Un modèle plus performant peut découvrir des vulnérabilités que les modèles précédents ont manquées, même avec le même harnais de recherche.

Nous avons sélectionné un échantillon de 166 exploits développés par les agents et analysé les techniques d’exploitation employées. À notre connaissance, les agents ont utilisé 10 techniques d’exploitation inédites dans les exploits de cet échantillon. Nous avons partagé ces techniques avec des experts externes en exploitation du noyau, qui ne les connaissaient pas non plus.

Parmi ces 10 techniques, deux reposent sur de nouveaux objets élastiques persistants que le modèle a utilisés pour remplir le cache cible du noyau d’objets ; deux sont de nouvelles techniques d’agencement des pages pour fiabiliser les exploits ; cinq sont de nouvelles techniques portant uniquement sur les données pour obtenir une élévation de privilèges, directement ou via une écriture arbitraire ; la dernière implique une confusion de type arbitraire. Pour des raisons de sécurité, nous ne partageons pas l’intégralité des détails techniques de ces nouvelles techniques d’exploitation dans cet article.

À retenir : les modèles de pointe ne se contentent pas de reconnaître des schémas de code vulnérable connus ou d’utiliser uniquement des techniques d’exploitation connues ; ils font preuve de créativité et proposent des approches inédites.

Une part importante de la mission de notre équipe consiste à mesurer le coût de la découverte et de l’exploitation des vulnérabilités, puis à utiliser ces données pour orienter les investissements défensifs. Notre objectif est d’aider les défenseurs à corriger les vulnérabilités avant que les attaquants ne puissent les utiliser, et de rendre le coût d’exploitation des logiciels prohibitif pour ces derniers. Mesurer les coûts d’exploitation nous aide à évaluer l’évolution de ce défi à mesure que les capacités des modèles progressent. Dans cette section, nous comparons le coût d’exécution de notre pipeline aux récompenses des programmes de primes aux bugs pour les vulnérabilités identifiées.

Les machines virtuelles cibles de notre expérience exécutaient un système d’exploitation de bureau standard, et non une cible affaiblie, selon le même modèle de menace que celui des compétitions de cybersécurité (par exemple Pwn2Own⁠(ouverture dans une nouvelle fenêtre), TyphoonPWN⁠(ouverture dans une nouvelle fenêtre)). Par le passé, Pwn2Own et TyphoonPWN ont proposé des primes respectives de 20 000 $ et 70 000 $ pour les exploits d’élévation locale de privilèges du noyau Linux. Appliquer ces anciens montants aux 948 exploits donne une valorisation hypothétique de 18,9 à 66,3 millions de dollars, soit environ 16 à 55 fois le coût de notre pipeline.

Nous avons aussi testé notre pipeline dans le cadre du programme de récompense des vulnérabilités kernelCTF⁠(ouverture dans une nouvelle fenêtre) de Google, dont la cible est un noyau Linux renforcé aux surfaces d’attaque réduites. Nous avons exécuté le pipeline sur la dernière version du noyau Linux dans l’environnement kernelCTF (cette version étant incompatible avec la protection SLAB_VIRTUAL de kernelCTF, nous l’avons retirée de la configuration) et obtenu 25 preuves de concept de fuite d’informations et 21 exploits d’élévation locale de privilèges. À titre de comparaison, à la date de rédaction, kernelCTF avait accepté 26 exploits LPE zero-day confirmés en 2026. La campagne complète a duré 112 heures et coûté environ 32 936 $ en crédits API, la découverte de vulnérabilités représentant 83,7 % du coût API. Si les 21 vulnérabilités étaient acceptées par le programme, elles donneraient droit à une prime d’environ 1,5 million de dollars, soit environ 45 fois le coût.

À retenir : sur la base des montants de récompense publics, avec les modèles actuels dotés de capacités en cybersécurité, notre pipeline de recherche de vulnérabilités dégageait un bénéfice net au moment de ces recherches. Les défenseurs doivent analyser leurs logiciels de manière proactive afin de rendre leur exploitation trop coûteuse pour les attaquants.

Lors de l’évaluation de l’exploitabilité, les agents ExploitDev recevaient un rapport de vulnérabilité et devaient créer un exploit pleinement fonctionnel. Notre pipeline considérait une vulnérabilité comme exploitée si un shell root avait été obtenu. Lors d’une première exécution, l’étape d’exploitation a signalé 200 exploits d’élévation locale de privilèges réussis. Cependant, après examen humain, nous avons constaté que 20 d’entre eux avaient obtenu les privilèges root via une autre vulnérabilité zero-day que celle qui leur avait été attribuée. Cela suggère que même une exploitation réussie par les agents nécessite une validation rigoureuse.

Nous avons ensuite renforcé les contraintes de la tâche et ajouté un contrôle indépendant pour confirmer que chaque exploit final utilisait bien la vulnérabilité qui lui avait été attribuée.

À retenir : pour la recherche autonome en sécurité, vérifiez le chemin menant au résultat en plus du résultat lui-même ; l’isolation, la surveillance et les vérifications indépendantes sont des contrôles indispensables.

Au début de ces recherches, nous avons étudié l’intérêt de mettre en place une orchestration lourde autour de l’agent pour améliorer ses capacités en cybersécurité. Nos résultats ont suggéré que les modèles plus performants nécessitent une orchestration et un accompagnement plus légers. Et le gain marginal ne justifie pas le coût de maintenance. Nous avons donc décidé de supprimer l’orchestration lourde.

L’expérience comparait GPT‑5.5 Cyber et GPT‑5.6 Cyber. Selon nos observations, GPT‑5.5 Cyber ne déterminait pas systématiquement quand et comment appliquer les techniques existantes d’exploitation du noyau Linux. Nous avons alors regroupé 103 techniques dans un format adapté au modèle, les avons rendues accessibles dans l’environnement de l’agent et lui avons demandé de les utiliser. Sur 63 vulnérabilités candidates à l’exploitation, le taux de réussite est ainsi passé de 76,2 % à 88,9 %.

Lorsque nous avons répété l’expérience avec GPT‑5.6 Cyber, le modèle était mieux à même de trouver, de sélectionner et d’appliquer seul les techniques pertinentes. Nous avons supprimé l’orchestration des techniques et des compétences, et ce workflow GPT‑5.6 Cyber à orchestration légère a surpassé le workflow GPT‑5.5 Cyber plus fortement encadré. Rétablir la couche de techniques supplémentaire pour GPT‑5.6 Cyber n’a apporté qu’un gain marginal de 1,5 point de pourcentage.

À retenir : réévaluez votre orchestration et votre harnais à mesure que les capacités du modèle de base évoluent. Un dispositif d’encadrement qui améliore sensiblement une génération de modèles peut apporter peu de valeur à un modèle plus performant ; son intérêt doit être évalué au regard du coût de maintenance.

Au départ, lorsqu’on lui demandait directement de proposer des correctifs, le modèle créait des correctifs fonctionnellement corrects qui neutralisaient la preuve de concept, mais introduisaient parfois d’autres problèmes : code superflu, compromis potentiels sur les performances, non-respect des conventions de code ou absence d’examen du code connexe à la recherche de variantes de la même vulnérabilité, ce qui rendait les correctifs incomplets.

Des instructions supplémentaires et des itérations sur le processus de génération ont amélioré la qualité des correctifs. Cela suggère qu’avec un encadrement adapté, les correctifs de sécurité générés par l’IA peuvent être corrects, minimaux et conformes aux conventions de code existantes. C’est un domaine de recherche actif, et nous pensons que les futurs modèles rendront ce processus plus facile et plus efficace. Dans quelques cas, notre prototype de recherche a aussi repéré des problèmes dans des correctifs rédigés par des experts humains ; ces problèmes ont été corrigés avant leur intégration.

À retenir : les modèles peuvent accélérer la correction, mais les compétences et les harnais associés peuvent nécessiter des itérations pour garantir que les correctifs répondent de manière fiable aux exigences fonctionnelles et non fonctionnelles. Nous recommandons également d’utiliser les modèles pour examiner les correctifs humains et générés par l’IA dans une optique adversariale, afin de repérer notamment les possibilités de contournement, les voies d’attaque ou variantes oubliées.

Lors de notre exécution dans kernelCTF, en plus des 21 exploits zero-day du noyau Linux, notre prototype de recherche a découvert et exploité une vulnérabilité de QEMU TCG. L’agent analyste devait analyser le code d’entrée des appels système. En écrivant des programmes pour tester les transitions de privilèges, il a rencontré un plantage inattendu du noyau. Il a effectué le triage du plantage et retracé l’origine du problème jusqu’à QEMU TCG, sans avoir accès au code source de QEMU, puis a inclus la vulnérabilité dans le rapport. L’agent ExploitDev a ensuite réussi à développer un exploit d’élévation locale de privilèges pour cette vulnérabilité. Nous avons découvert cette vulnérabilité de QEMU lors de l’analyse manuelle des exploits et confirmé qu’elle avait été corrigée dans QEMU en amont, mais pas dans la version compilée utilisée pendant l’expérience.

À retenir : les modèles de pointe dotés de capacités en cybersécurité peuvent trouver des vulnérabilités dans l’infrastructure de test. Nous recommandons de tester chaque composant de l’infrastructure avant de mener des recherches offensives sur les vulnérabilités. Nous avons testé notre infrastructure de manière proactive, divulguant et corrigeant de nombreuses vulnérabilités dans Kata, Moby/Docker, gVisor et d’autres projets.

Notre objectif est de transformer les capacités croissantes des modèles en un avantage durable pour les personnes qui sécurisent Internet. Ces recherches montrent que les capacités croissantes des modèles de pointe en cybersécurité permettent de rechercher efficacement des vulnérabilités dans des logiciels complexes, comme le noyau Linux. Renforcer la sécurité de projets logiciels critiques comme Linux et d’autres projets open source peut protéger de nombreux systèmes et utilisateurs en aval.

Avec Patch the Planet, une initiative Daybreak, nous souhaitons étendre ces recherches à davantage de projets logiciels critiques et développer une correction automatisée fiable, aux côtés des responsables de maintenance et de nos partenaires en sécurité. Nous voulons réduire progressivement les possibilités offertes aux attaquants et augmenter le coût de la découverte et de l’exploitation des vulnérabilités, jusqu’à ce que le gain escompté ne justifie plus l’attaque.

Chaque génération de modèles devrait nous aider à créer des logiciels que la génération suivante aura plus de mal à compromettre. Nous continuerons à œuvrer pour un Internet sécurisé sur lequel chacun puisse créer avec plaisir.