Mil camins menys cap a l'accés root

La recerca en seguretat, que abans requeria una investigació específica i sostinguda per a cada troballa, cada cop es pot dur a terme d'una manera més semblant a un procés sistemàtic. Aquest document explora una de les nostres iniciatives en aquest àmbit.

Cada cop és més fàcil ampliar l'escala de la descoberta de vulnerabilitats, però la priorització i la validació continuen sent colls d'ampolla operatius. Vam construir un prototip per cercar errors de seguretat al nucli de Linux en un entorn de recerca controlat. El nostre prototip va identificar i analitzar 2.308 possibles vulnerabilitats del nucli de Linux, va reproduir dinàmicament 1.724 vulnerabilitats i va generar 948 explotadors d'escalada local de privilegis (LPE) que podrien permetre a un usuari local sense privilegis obtenir accés root.

Vam utilitzar aquestes proves per prioritzar les vulnerabilitats que calia comunicar i vam desenvolupar propostes de pedaços perquè els responsables del manteniment les revisessin. Seguint les indicacions de la comunitat del nucli de Linux, vam començar per les vulnerabilitats crítiques i estem treballant amb els socis de Patch the Planet en més informes i pedaços.

Al juny, com a part de la nostra iniciativa Patch the Planet, vam anunciar que GPT‑5.5 Cyber havia identificat vulnerabilitats al nucli de Linux i havia desenvolupat 24 explotadors d'escalada local de privilegis per validar-les i comunicar-les. Vam ampliar aquesta tasca fins a crear un pipeline, impulsat per un futur model de ciberseguretat, que comprèn la descoberta de vulnerabilitats, la validació dinàmica, l'avaluació de l'explotabilitat i la generació de pedaços. Un cop enllestida, investigadors humans van revisar els resultats i van comunicar les vulnerabilitats trobades juntament amb els pedaços.

El nucli de Linux és la base dels dispositius Android, la infraestructura del núvol, els supercomputadors i altres sistemes que utilitzen milers de milions de persones. Amb més de 40 milions de línies de codi, el nucli exposa una superfície d'atac àmplia per mitjà de les crides al sistema, les funcions de xarxa, els sistemes de fitxers i els controladors de dispositius. Vam triar Linux per estudiar amb quina eficàcia els models d'avantguarda podien trobar vulnerabilitats i demostrar-ne l'impacte en la seguretat en una base de codi d'aquesta escala i importància.

La fase inicial de descoberta va detectar milers de possibles vulnerabilitats, massa perquè els investigadors de seguretat les revisessin i en fessin el triatge manualment. El repte operatiu del nostre pipeline de descoberta de vulnerabilitats no era descobrir-les, sinó determinar quines troballes es podien reproduir, quin límit de seguretat traspassaven i quines requerien una atenció més urgent per part dels responsables del manteniment.

La missió de l'equip de ciberseguretat d'OpenAI és ajudar a protegir el programari del qual depèn el món. Indiquem els costos de l'API de cada fase per ajudar els investigadors a avaluar els recursos necessaris per reproduir i ampliar aquesta tasca. Aquests costos corresponen als models, les configuracions dels sistemes objectiu i el flux de treball utilitzats en aquesta avaluació. El nostre objectiu més ampli és ajudar els defensors a trobar i corregir vulnerabilitats reduint les oportunitats a l'abast dels atacants i augmentant el cost que els suposa explotar el programari.

Finalment, cal assenyalar que aquesta recerca es va centrar en la metodologia i a mesurar les capacitats dels models, no en el cost. Preveiem que un treball d'enginyeria suficient sobre l'entorn d'execució podria reduir significativament el cost de cada fase; per tant, els costos que indiquem són més aviat un límit superior.

El nostre prototip de recerca de vulnerabilitats és un pipeline en cinc fases que té com a element central un futur model de ciberseguretat:

• Descoberta de vulnerabilitats: els agents identifiquen les parts de la base de codi rellevants per a la seguretat i les analitzen a la recerca de possibles vulnerabilitats.

• Validació dinàmica: els agents intenten reproduir cada possible vulnerabilitat en un entorn aïllat i conserven les proves obtingudes durant l'execució. Aquest pas permet conèixer les vulnerabilitats reproduïdes i validades.

• Avaluació de l'explotabilitat: els agents comproven si les vulnerabilitats validades podrien permetre la divulgació d'informació o l'escalada local de privilegis.

• Generació de pedaços: els agents generen pedaços per corregir cada vulnerabilitat identificada.

• Revisió humana: els investigadors de seguretat revisen l'explotador, el pedaç i la gravetat proposada abans de comunicar-ho als responsables del manteniment.

Al final del pipeline, el sistema agrupa una anàlisi de la causa principal, una prova de concepte mínima que provoca un error, una proposta de pedaç i un explotador complet per ajudar els investigadors humans a avaluar la gravetat de la vulnerabilitat i incorporar les correccions al projecte original.

No totes les línies de codi del nucli de Linux són rellevants per a la seguretat. El nostre pipeline va utilitzar un equip d'agents exploradors per identificar elements d'alt valor per auditar, que després es van passar als agents analistes perquè hi cerquessin vulnerabilitats.

Els agents exploradors llegeixen cada carpeta i fitxer i determinen quins elements cal auditar segons si són accessibles per a usuaris amb pocs privilegis i la seva rellevància per a la seguretat.

En aquesta fase es van identificar 5.034 elements per auditar, uns 2,8 milions de línies de codi, que representen aproximadament el 7 % de tot el codi del nucli de Linux. Això va reduir significativament el cost de l'auditoria de seguretat respecte d'una anàlisi de tot el codi. Aquest pas va tenir un cost de 3.426 USD en crèdits de l'API.

A continuació, els agents analistes van analitzar cada element per auditar i van detectar possibles vulnerabilitats amb un flux de treball semblant al del connector Codex Security⁠(s'obre en una finestra nova). A grans trets, els agents analistes llegeixen el codi de l'element assignat per entendre com funciona, identificar-ne el model d'amenaces i cercar-hi vulnerabilitats.

En 12 hores, els agents analistes van detectar 2.308 possibles vulnerabilitats, un cop eliminats els duplicats. Aquesta fase va tenir un cost de 316.549 USD en crèdits de l'API.

Una possible vulnerabilitat no és el mateix que una vulnerabilitat validada. A aquesta escala, investigar manualment cada informe és inviable per al nostre equip de recerca.

Per això, ens vam centrar a validar les troballes que a) eren accessibles per a un usuari amb pocs privilegis, b) no requerien capacitats especials i c) produïen proves mesurables de danys a la memòria.

Per a cada possible vulnerabilitat, un agent de triatge va generar una prova de concepte i la va executar en una màquina virtual aïllada amb un nucli de Linux amb Kernel Address Sanitizer (KASAN). L'agent va observar tant la sortida del programa com la consola del sistema i va anar refinant la prova de concepte fins a reproduir el comportament descrit a l'informe o esgotar les possibles maneres de provocar-lo.

En 30 hores, el nostre sistema va reproduir 1.724 vulnerabilitats, aproximadament el 74,7 % de les 2.308 possibles vulnerabilitats detectades. La revisió estàtica del codi, per si sola, pot ser propensa a falsos positius. Per això, ens van impressionar la precisió dels agents analistes i l'eficàcia dels agents de triatge a l'hora de crear autònomament proves de concepte funcionals per a gairebé tres quartes parts de les possibles vulnerabilitats.

La majoria de les troballes restants requerien privilegis elevats o no es van poder reproduir en el temps assignat a causa de condicions de cursa difícils, condicions d'activació específiques (p. ex., la necessitat d'una fallada d'assignació de memòria en una línia concreta) o validacions que requerien molt de temps (p. ex., el desbordament del comptador de referències). Només el 3,1 % corresponia a anàlisis incorrectes del model, en què la vulnerabilitat descrita pressuposava una condició impossible.

La fase de validació va tenir un cost total de 73.330 USD en crèdits de l'API. Vam observar que, en el nostre flux de validació, que havia de generar una prova de concepte per confirmar si una possible vulnerabilitat era real, aquest procés resultava més car que fer una recomanació basada només en l'anàlisi estàtica. A més, els costos d'intentar validar un positiu real i un fals positiu eren semblants. Per tant, el fet d'eliminar els falsos positius amb antelació dins del pipeline fa que el procés sigui significativament més eficient en termes de costos.

La validació estableix que una vulnerabilitat és real, però no amb quina urgència cal abordar-la. Una vulnerabilitat que podria permetre una escalada local de privilegis, per exemple, mereix més prioritat que una altra que només podria provocar una denegació de servei local. Amb 1.724 vulnerabilitats validades, la tasca següent era identificar les troballes amb un impacte potencial més gran en la seguretat.

Un agent de cribratge inicial va revisar estàticament cada informe, registre d'error i fragment de codi font rellevant. Va ser deliberadament permissiu per evitar descartar troballes potencialment greus, i a la vegada va filtrar els casos sense una via d'explotació plausible. Això va reduir els resultats a 313 possibles filtracions d'informació i 1.238 possibles escalades locals de privilegis.

A continuació, els agents de desenvolupament d'explotadors (ExploitDev) van provar aquests casos en màquines virtuals aïllades configurades amb les proteccions activades en una distribució estàndard de Linux, entre les quals Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) i HARDENED_USERCOPY. Això va ajudar a evitar avaluacions poc realistes que depenguessin del fet de tenir les proteccions desactivades.

Els agents van generar 291 proves de concepte de filtració d'informació i 1.169 explotadors funcionals d'escalada local de privilegis que podrien donar accés root a usuaris locals sense privilegis.

Vam fer una anàlisi de variants i vam desenvolupar 948 pedaços diferents per a les vulnerabilitats que feien possibles aquests explotadors. Utilitzem aquesta xifra per determinar el nombre total de vulnerabilitats d'LPE úniques. Desenvolupar els explotadors reeixits va tenir un cost mitjà de 359 USD en crèdits. Això fa que comprovar l'explotabilitat de les vulnerabilitats trobades resulti relativament econòmic per als defensors.

L'agent de cribratge inicial de vulnerabilitats va tenir un cost de 44.194 USD en crèdits de l'API. La fase d'explotació va tenir un cost total de 775.929 USD en crèdits de l'API: 84.929 USD per processar les possibles filtracions d'informació i 691.000 USD per a les possibles escalades locals de privilegis.

De mitjana, processar una possible escalada local de privilegis (558 USD) va costar aproximadament el doble que processar una possible filtració d'informació (271 USD). Això es deu al fet que les proves de concepte de filtració d'informació es reutilitzaven de la fase de validació i requerien menys modificacions per poder-se utilitzar en un explotador. En canvi, desenvolupar un explotador a partir d'una possible LPE requeria molts passos addicionals, com ara planificar l'estratègia d'explotació, identificar objectes vulnerables per utilitzar-los, eludir les mitigacions i altres tasques. També vam observar que els intents d'explotació fallits (3.922 USD per a 69 casos) costaven molt més que els reeixits (360 USD per a 1.169 casos). Això es devia a unes quantes vulnerabilitats difícils d'explotar (p. ex., condicions de cursa). Definir una condició d'abandonament raonable, com ara aturar l'intent després d'una hora sense progressos, hauria reduït significativament el cost d'ExploitDev.

Per a cada vulnerabilitat validada, el sistema també genera un pedaç. Proporcionem al model el codi font rellevant i li donem indicacions sobre bones pràctiques per escriure pedaços, com ara fer comprovacions estàtiques del pedaç, seguir les pràctiques de desenvolupament utilitzades en el codi proper i analitzar les variants per assegurar-se que el pedaç sigui complet.

Seguint el suggeriment de la comunitat del nucli de Linux, ja hem enviat centenars d'informes i pedaços per a vulnerabilitats crítiques i estem treballant amb els socis de Patch the Planet per anar enviant els pedaços de la resta. Aquesta feina forma part del nostre compromís més ampli, a través de Daybreak, de donar suport als projectes de codi obert.

En aquesta secció compartim aprenentatges, reflexions i anàlisis addicionals d'aquesta recerca.

Durant aquesta recerca, vam observar que els responsables del manteniment de Linux actuaven amb rapidesa per corregir vulnerabilitats i protegir els usuaris. L'anàlisi es va fer sobre la versió més recent del nucli de Linux a mitjan octubre del 2026. Quan l'anàlisi autònoma i la manual van acabar al cap de 10 dies, ja s'havien corregit 61 vulnerabilitats d'LPE al projecte original, 43 disposaven de pedaços pendents d'integrar i 299 s'estaven comunicant i debatent públicament.

Agraïm molt la feina urgent dels responsables del manteniment de Linux per corregir els problemes identificats, així com les aportacions de tota la comunitat de seguretat. Aquesta resposta col·lectiva és la que cal per protegir el programari d'arreu del món. El ritme ràpid de divulgació i correcció de vulnerabilitats també posa de manifest com n'és d'essencial que els usuaris i les empreses mantinguin el programari actualitzat.

Conclusió clau: el triatge automatitzat ha de tenir en compte la rapidesa del cicle de correcció. Tornar a validar les troballes amb el codi més recent, incloent-hi el codi nou integrat després de l'anàlisi original, ajuda a evitar la generació d'informes duplicats o obsolets. Això centra l'atenció en les vulnerabilitats no resoltes i proporciona als responsables del manteniment proves sobre les quals poden actuar, sense afegir una càrrega de revisió innecessària.

Mentre desenvolupàvem el pipeline, a finals de juliol del 2026, GPT‑5.6 Sol va trobar i explotar 166 vulnerabilitats d'LPE úniques, amb un cost total de 513.690 USD en crèdits de l'API.

En la segona anàlisi, a mitjan octubre del 2026, el model de ciberseguretat més recent va trobar i explotar 948 vulnerabilitats d'LPE úniques, amb un cost total d'1.213.430 USD en crèdits de l'API. En totes dues campanyes, vam analitzar la versió més recent de la branca mestra del nucli de Linux disponible en aquell moment.

Conclusió clau: cal tornar a analitzar el codi ja auditat a mesura que millorin les capacitats dels models. Un model més capaç pot descobrir vulnerabilitats que els models anteriors no van detectar, fins i tot amb el mateix entorn d'execució per a la recerca.

Vam seleccionar una mostra de 166 explotadors desenvolupats pels agents i vam analitzar les tècniques d'explotació que utilitzaven. Que nosaltres sapiguem, els agents van utilitzar 10 tècniques d'explotació noves en els explotadors de la mostra. Vam compartir aquestes tècniques amb experts externs en explotació del nucli, que tampoc no les coneixien.

De les 10 tècniques, dues són nous objectes elàstics persistents que el model va utilitzar per omplir d'objectes la memòria cau objectiu del nucli, dues són noves tècniques de preparació de pàgines de memòria per millorar la fiabilitat de l'explotador, cinc són noves tècniques basades només en dades per obtenir una escalada de privilegis directament o mitjançant una escriptura arbitrària i l'altra implica una confusió arbitrària de tipus. Per motius de seguretat, no compartim tots els detalls tècnics d'aquestes noves tècniques d'explotació en aquest article.

Conclusió clau: els models d'avantguarda no es limiten a reconèixer patrons coneguts de codi vulnerable ni a utilitzar únicament tècniques d'explotació conegudes; demostren creativitat i plantegen enfocaments nous.

Una part important de la missió del nostre equip és mesurar el cost de trobar i explotar vulnerabilitats i utilitzar aquestes dades per orientar la inversió en defensa. El nostre objectiu és ajudar els defensors a corregir les vulnerabilitats abans que els atacants les puguin utilitzar i fer que explotar el programari tingui un cost prohibitiu per als atacants. Mesurar els costos d'explotació ens ajuda a avaluar com canvia aquest repte a mesura que milloren les capacitats dels models. En aquesta secció, comparem el cost d'execució del nostre pipeline amb les recompenses dels programes de detecció de vulnerabilitats per a les vulnerabilitats identificades.

Les màquines virtuals objectiu del nostre experiment executaven un sistema operatiu d'escriptori estàndard, no pas un sistema amb les defenses debilitades, amb el mateix model d'amenaces que utilitzen les competicions de ciberseguretat (p. ex., Pwn2Own⁠(s'obre en una finestra nova), TyphoonPWN⁠(s'obre en una finestra nova)). Històricament, Pwn2Own i TyphoonPWN han ofert recompenses de 20.000 USD i 70.000 USD, respectivament, per explotadors d'escalada local de privilegis al nucli de Linux. Si apliquem aquests imports històrics als 948 explotadors, obtenim una valoració hipotètica d'entre 18,9 i 66,3 milions de dòlars, aproximadament entre 16 i 55 vegades el cost del nostre pipeline.

També vam provar el nostre pipeline amb el programa de recompenses per vulnerabilitats kernelCTF⁠(s'obre en una finestra nova) de Google, que té com a objectiu un nucli de Linux amb la seguretat reforçada i superfícies d'atac reduïdes. Vam executar el pipeline sobre la versió més recent del nucli de Linux en l'entorn de kernelCTF. Com que aquesta versió era incompatible amb la mitigació SLAB_VIRTUAL de kernelCTF, la vam eliminar de la configuració. Vam obtenir 25 proves de concepte de filtració d'informació i 21 explotadors d'escalada local de privilegis. A tall de comparació, en el moment de redactar aquest text, kernelCTF havia acceptat 26 explotadors d'LPE de dia zero confirmats durant el 2026. La campanya sencera va durar 112 hores i va tenir un cost aproximat de 32.936 USD en crèdits de l'API. La descoberta de vulnerabilitats va representar el 83,7 % del cost de l'API. Si el programa acceptés les 21 vulnerabilitats, la recompensa seria d'uns 1,5 milions de dòlars, aproximadament 45 vegades el cost.

Conclusió clau: segons els imports públics de les recompenses, amb els models actuals amb capacitats de ciberseguretat, el nostre pipeline de recerca de vulnerabilitats hauria generat un benefici net en el moment d'aquesta recerca. Els defensors haurien d'analitzar proactivament el seu programari perquè explotar-lo tingui un cost prohibitiu per als atacants.

Durant l'avaluació de l'explotabilitat, els agents ExploitDev rebien un informe de vulnerabilitat i l'encàrrec de crear un explotador plenament funcional. El nostre pipeline marcava una vulnerabilitat com a explotada si s'aconseguia obtenir un intèrpret d'ordres amb privilegis root. Durant una de les primeres execucions, la fase d'explotació va informar de 200 explotadors d'escalada local de privilegis reeixits. Tanmateix, després de la revisió humana, vam descobrir que 20 d'aquests havien aconseguit privilegis root mitjançant una vulnerabilitat de dia zero diferent de l'assignada. Això suggereix que fins i tot les explotacions reeixides dels agents necessiten una validació adequada.

Posteriorment, vam endurir les restriccions de la tasca i vam afegir una comprovació independent per confirmar que cada explotador final utilitzava la vulnerabilitat assignada.

Conclusió clau: en la recerca autònoma en seguretat, cal verificar el camí que porta a un resultat, a més del resultat mateix; l'aïllament, el monitoratge i les comprovacions independents són controls necessaris.

Al principi d'aquesta recerca, vam estudiar si convenia dissenyar una orquestració complexa al voltant de l'agent per millorar-ne les capacitats de ciberseguretat. El resultat va suggerir que els models més potents necessiten menys orquestració i guiatge. I la millora marginal no justifica el cost de manteniment. Per això, vam decidir eliminar l'orquestració complexa.

L'experiment comparava GPT‑5.5 Cyber i GPT‑5.6 Cyber. Segons el que vam observar, GPT‑5.5 Cyber no identificava de manera consistent quan i com calia aplicar les tècniques existents d'explotació del nucli de Linux. Aleshores vam recopilar 103 tècniques en un format fàcil d'utilitzar per al model, les vam posar a disposició de l'agent en el seu entorn i li vam indicar que les fes servir. En 63 possibles vulnerabilitats per explotar, això va augmentar la taxa d'èxit del 76,2 % al 88,9 %.

Quan ho vam repetir amb GPT‑5.6 Cyber, el model va mostrar més capacitat per trobar, seleccionar i aplicar les tècniques pertinents per si sol. Vam eliminar l'orquestració de tècniques i habilitats, i aquest flux amb GPT‑5.6 Cyber i una orquestració lleugera va superar el flux amb GPT‑5.5 Cyber, que disposava d'una estructura de suport més complexa. Tornar a afegir la capa addicional de tècniques a GPT‑5.6 Cyber només va aportar una millora marginal d'1,5 punts percentuals.

Conclusió clau: cal reavaluar l'orquestració i l'entorn d'execució a mesura que canviïn les capacitats del model base. Una estructura de suport que millora substancialment una generació de models pot aportar poc valor a un model més potent, i cal avaluar si compensa el cost de manteniment.

Inicialment, quan se li demanava directament al model que generés propostes de pedaços, aquest creava pedaços funcionalment correctes que mitigaven la prova de concepte, però de vegades introduïen altres problemes: més codi del necessari, possibles perjudicis per al rendiment o desviacions de les convencions de programació. També podia passar que no examinés el codi relacionat per cercar-hi variants de la mateixa vulnerabilitat, cosa que donava lloc a la creació de pedaços incomplets.

Les instruccions addicionals i les iteracions del procés de generació van millorar la qualitat dels pedaços. Això apunta al fet que, amb una gestió adequada, els pedaços de seguretat generats per IA poden ser correctes, mínims i coherents amb les convencions del codi existent. És un àmbit de recerca actiu, i creiem que amb els futurs models aquest procés serà més fàcil i eficaç. En alguns casos, el nostre prototip de recerca també va poder identificar problemes en pedaços escrits per experts humans, que es van corregir abans d'integrar-los.

Conclusió clau: els models poden accelerar el procés de correcció, però les habilitats i els entorns d'execució per generar pedaços poden requerir iteracions per garantir que els pedaços compleixin de manera fiable tant els requisits funcionals com els no funcionals. A més, recomanem utilitzar models per revisar els pedaços generats per humans i per IA des de la perspectiva d'un atacant. Això pot permetre detectar problemes com ara la possibilitat d'eludir el pedaç o l'existència d'altres vies d'atac o variants no cobertes.

En l'execució amb kernelCTF, a més dels 21 explotadors de dia zero del nucli de Linux, el nostre prototip de recerca també va trobar i explotar una vulnerabilitat de QEMU TCG. L'agent analista tenia assignada la tasca d'analitzar el codi d'entrada de les crides al sistema i, mentre escrivia programes per experimentar amb les transicions de privilegis, es va trobar amb un error inesperat del nucli. Després de fer-ne el triatge, va rastrejar el problema fins a QEMU TCG, sense tenir accés al codi font de QEMU, i va incloure la vulnerabilitat a l'informe. Posteriorment, l'agent ExploitDev va desenvolupar amb èxit un explotador d'escalada local de privilegis per a aquesta vulnerabilitat. Vam descobrir aquesta vulnerabilitat de QEMU en analitzar manualment els explotadors i vam confirmar que ja s'havia corregit al projecte original de QEMU, però no a la compilació publicada que es va utilitzar durant l'experiment.

Conclusió clau: els models d'avantguarda amb capacitats de ciberseguretat poden trobar vulnerabilitats en la infraestructura de proves. Recomanem provar cada part de la infraestructura abans de dur a terme recerca ofensiva de vulnerabilitats. Hem provat proactivament la nostra infraestructura i hem divulgat i corregit moltes vulnerabilitats de Kata, Moby/Docker, gVisor i altres projectes.

El nostre objectiu és convertir les capacitats creixents dels models en un avantatge durador per a les persones que protegeixen Internet. Aquesta recerca demostra que les capacitats creixents dels models d'avantguarda en ciberseguretat es poden utilitzar per cercar eficaçment vulnerabilitats en programari complex, com ara el nucli de Linux. Reforçar la seguretat de projectes de programari crítics com Linux i altres projectes de codi obert pot protegir molts sistemes i usuaris que en depenen.

A través de Patch the Planet, una iniciativa de Daybreak, volem ampliar aquesta recerca a més projectes de programari crítics i desenvolupar un sistema fiable d'aplicació automatitzada de pedaços, juntament amb els responsables del manteniment i els socis de seguretat. Volem reduir progressivament les oportunitats a l'abast dels atacants i augmentar el cost de trobar i explotar vulnerabilitats, fins que el benefici esperat ja no justifiqui l'atac.

Cada generació de models ens hauria d'ajudar a crear programari que la generació següent trobi més difícil de comprometre. Continuarem treballant per construir una Internet segura on tothom pugui gaudir creant.