Tusind færre veje til root

Sikkerhedsforskning, der tidligere krævede en særskilt, længerevarende undersøgelse af hvert fund, kan i stigende grad gennemføres som en systematisk proces. Dette dokument beskriver en af vores indsatser på området.

Sårbarhedssøgning bliver lettere at skalere, men prioritering og validering er stadig operationelle flaskehalse. Vi byggede en prototype til at lede efter sikkerhedsfejl i Linux-kernen i et kontrolleret forskningsmiljø. Vores prototype identificerede og analyserede 2.308 potentielle sårbarheder i Linux-kernen, reproducerede dynamisk 1.724 sårbarheder og udviklede 948 exploits til lokal rettighedsforøgelse (LPE), som kunne give en lokal bruger uden særlige rettigheder root-adgang.

Vi brugte denne dokumentation til at prioritere, hvilke sårbarheder der skulle rapporteres, og udarbejdede patchforslag til vedligeholdernes gennemgang. Efter vejledning fra Linux-kernefællesskabet begyndte vi med de kritiske sårbarheder og arbejder sammen med Patch the Planet-partnere om flere rapporter og patches.

I juni fortalte vi som led i vores Patch the Planet-initiativ, at GPT‑5.5 Cyber havde identificeret sårbarheder i Linux-kernen og udviklet 24 exploits til lokal rettighedsforøgelse for at validere og rapportere dem. Vi udvidede arbejdet til en pipeline drevet af en kommende cybermodel, som omfatter sårbarhedssøgning, dynamisk validering, vurdering af udnyttelsesmuligheder og generering af patches. Da den var færdig, gennemgik menneskelige forskere resultaterne og rapporterede de fundne sårbarheder sammen med patches.

Linux-kernen er grundlaget for Android-enheder, cloudinfrastruktur, supercomputere og andre systemer, som bruges af milliarder af mennesker. Med mere end 40 millioner kodelinjer har kernen en bred angrebsflade gennem systemkald, netværk, filsystemer og enhedsdrivere. Vi valgte Linux for at undersøge, hvor effektivt banebrydende modeller kunne finde sårbarheder og påvise deres sikkerhedsmæssige konsekvenser i en kodebase af denne størrelse og betydning.

Det indledende trin med sårbarhedssøgning gav tusindvis af potentielle fund, for mange til at sikkerhedsforskere manuelt kunne gennemgå og prioritere dem. Den operationelle udfordring i vores pipeline var ikke at finde sårbarheder, men at afgøre, hvilke fund der kunne reproduceres, hvilken sikkerhedsgrænse de overskred, og hvilke vedligeholderne burde tage sig af først.

OpenAI's Cyber-team har til opgave at hjælpe med at sikre den software, verden er afhængig af. Vi oplyser API-omkostningerne for hvert trin, så forskere kan vurdere, hvilke ressourcer der kræves for at gentage og videreudvikle arbejdet. Omkostningerne afspejler de modeller, målkonfigurationer og den arbejdsgang, der blev brugt i evalueringen. Vores bredere mål er at hjælpe sikkerhedsansvarlige med at finde og rette sårbarheder, begrænse angribernes muligheder og gøre det dyrere for dem at udnytte software.

Bemærk til sidst, at denne forskning fokuserede på metode og måling af modellernes kapacitet, ikke på omkostninger. Vi forventer, at tilstrækkelig optimering af vores harness kan reducere omkostningerne væsentligt på hvert trin. De oplyste omkostninger skal derfor snarere ses som en øvre grænse.

Vores prototype til sårbarhedsforskning er en pipeline med fem trin, der bygger på en kommende cybermodel:

• Sårbarhedssøgning: Agenter identificerer sikkerhedsrelevante dele af kodebasen og scanner dem for potentielle sårbarheder.

• Dynamisk validering: Agenter forsøger at reproducere hvert potentielt fund i et isoleret miljø og gemmer dokumentation fra kørslen. Dette trin leverer de reproducerede og validerede sårbarheder.

• Vurdering af udnyttelsesmuligheder: Agenter tester, om validerede sårbarheder kan muliggøre informationslækage eller lokal rettighedsforøgelse.

• Generering af patches: Agenter genererer patches, der retter hver identificeret sårbarhed.

• Menneskelig gennemgang: Sikkerhedsforskere gennemgår exploitet, patchen og den foreslåede alvorlighedsgrad, før sårbarheden rapporteres til vedligeholderne.

Til sidst samler systemet en analyse af den grundlæggende årsag, et minimalt proof of concept, der udløser et nedbrud, et patchforslag og et fuldt exploit. Det hjælper menneskelige forskere med at vurdere sårbarhedens alvor og få rettelserne indarbejdet i hovedprojektet.

Ikke alle kodelinjer i Linux-kernen er relevante for sikkerheden. Vores pipeline brugte et hold spejderagenter til at identificere særligt relevante kodeområder, som derefter blev sendt videre til analyseagenter til sårbarhedsscanning.

Spejderagenter gennemgår hver mappe og fil og afgør, hvilke kodeområder der skal undersøges, ud fra deres tilgængelighed for brugere med begrænsede rettigheder og deres sikkerhedsrelevans.

Dette trin identificerede 5.034 kodeområder til undersøgelse, cirka 2,8 millioner kodelinjer. Det svarer til omtrent 7 % af hele Linux-kernens kodebase og reducerer omkostningerne ved sikkerhedsrevisionen markant sammenlignet med en analyse af hele kodebasen. Dette trin kostede 3.426 USD i API-kreditter.

Derefter analyserede analyseagenterne hvert udvalgt kodeområde og identificerede potentielle sårbarheder med en arbejdsgang, der minder om den i Codex Security-pluginet⁠(åbner i et nyt vindue). Overordnet læser analyseagenterne koden i det tildelte område for at forstå, hvordan den fungerer, identificere dens trusselsmodel og lede efter sårbarheder.

Inden for 12 timer havde analyseagenterne identificeret 2.308 potentielle sårbarheder efter fjernelse af dubletter. Dette trin kostede 316.549 USD i API-kreditter.

Et potentielt fund er ikke det samme som en valideret sårbarhed. Med så mange fund er det ikke praktisk muligt for vores forskerteam at undersøge hver rapport manuelt.

Vi fokuserede derfor på at validere fund, som a) var tilgængelige for en bruger med begrænsede rettigheder, b) ikke krævede særlige capabilities og c) gav målbare tegn på hukommelseskorruption.

For hver potentiel sårbarhed genererede en triageagent et proof of concept og kørte det i en isoleret virtuel maskine med en Linux-kerne med Kernel Address Sanitizer (KASAN). Agenten overvågede både programmets output og systemkonsollen og forbedrede derefter sit proof of concept iterativt, indtil det reproducerede den rapporterede adfærd, eller alle mulige måder at udløse den på var afprøvet.

Inden for 30 timer reproducerede vores system 1.724 sårbarheder, cirka 74,7 % af de 2.308 potentielle fund. Statisk kodegennemgang alene kan give falske positiver. Derfor var vi imponerede over analyseagenternes nøjagtighed og triageagenternes evne til selvstændigt at skabe fungerende proofs of concept for næsten tre fjerdedele af de potentielle fund.

De fleste resterende fund krævede enten forhøjede rettigheder eller kunne ikke reproduceres inden for tidsrammen på grund af vanskelige race conditions, specifikke udløsningsbetingelser (f.eks. en nødvendig allokeringsfejl ved en bestemt linje) eller tidskrævende validering (f.eks. overløb i en referencetæller). Kun 3,1 % skyldtes forkert analyse fra modellens side, hvor den rapporterede sårbarhed forudsatte en umulig betingelse.

Valideringstrinnet kostede i alt 73.330 USD i API-kreditter. I vores valideringspipeline skulle der genereres et proof of concept for at bekræfte, om et potentielt fund var en reel sårbarhed. Vi konstaterede, at denne proces var dyrere end at give en anbefaling udelukkende ud fra statisk analyse, og at forsøg på at validere sande og falske positiver kostede omtrent det samme. At fjerne falske positiver tidligere i pipelinen gør derfor processen væsentligt mere omkostningseffektiv.

Validering fastslår, at en sårbarhed er reel, men ikke hvor hurtigt den bør håndteres. En sårbarhed, der kan muliggøre lokal rettighedsforøgelse, bør for eksempel prioriteres højere end en, der kun kan forårsage et lokalt tjenestenægtelsesangreb. Med 1.724 validerede sårbarheder var næste opgave at identificere de fund, der kunne have størst betydning for sikkerheden.

En indledende screeningsagent gennemgik hver rapport, nedbrudslog og relevant kildekode statisk. Den havde bevidst lempelige kriterier for ikke at frasortere potentielt alvorlige fund, men filtrerede tilfælde uden en plausibel vej til udnyttelse fra. Det indsnævrede resultaterne til 313 mulige informationslækager og 1.238 mulige lokale rettighedsforøgelser.

Agenter til exploitudvikling (ExploitDev) testede derefter disse potentielle sårbarheder i isolerede virtuelle maskiner med de beskyttelser, der er aktiveret i en standard-Linux-distribution, herunder Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) og HARDENED_USERCOPY. Det bidrog til at undgå urealistiske vurderinger, som forudsatte, at beskyttelser var deaktiveret.

Agenterne udviklede 291 proofs of concept for informationslækager og 1.169 fungerende exploits til lokal rettighedsforøgelse, som kunne give lokale brugere uden særlige rettigheder root-adgang.

Vi udførte variantanalyse og udviklede 948 særskilte patches til sårbarhederne bag disse exploits. Vi bruger dette tal som det samlede antal unikke LPE'er. Vellykkede exploits kostede i gennemsnit 359 USD i kreditter at udvikle. Det gør det relativt billigt for sikkerhedsansvarlige at teste, om fundne sårbarheder kan udnyttes.

Den indledende agent til sårbarhedsscreening kostede 44.194 USD i API-kreditter. Udnyttelsestrinnet kostede i alt 775.929 USD i API-kreditter: 84.929 USD til behandling af mulige informationslækager og 691.000 USD til mulige lokale rettighedsforøgelser.

I gennemsnit var det omtrent dobbelt så dyrt at behandle en mulig lokal rettighedsforøgelse (558 USD) som en mulig informationslækage (271 USD). Det skyldes, at PoC'er for informationslækage blev videreført fra valideringstrinnet og krævede færre ændringer for at kunne bruges i et exploit. Derimod krævede udviklingen af et exploit fra en mulig LPE mange ekstra trin, såsom planlægning af udnyttelsesstrategien, identifikation af sårbare objekter, der kunne bruges, omgåelse af beskyttelsesmekanismer med mere. Vi bemærkede også, at mislykkede udnyttelsesforsøg (3.922 USD for 69 tilfælde) kostede langt mere end vellykkede forsøg (360 USD for 1.169 tilfælde). Det skyldtes nogle få sårbarheder, der var svære at udnytte (f.eks. race conditions). Et rimeligt stopkriterium, som at afslutte forsøget efter en time uden fremskridt, ville have reduceret omkostningerne ved ExploitDev betydeligt.

Systemet genererer også en patch til hver valideret sårbarhed. Vi giver modellen den relevante kildekode og instruerer den i bedste praksis for patchudvikling, såsom at udføre statiske kontroller af patchen, følge udviklingspraksis i den omgivende kode og udføre variantanalyse for at sikre, at patchen er dækkende.

Efter forslag fra Linux-kernefællesskabet har vi allerede udsendt hundredvis af rapporter og patches til kritiske sårbarheder og arbejder sammen med Patch the Planet-partnere om gradvist at udsende patches til resten. Arbejdet er en del af vores bredere indsats under Daybreak for at støtte open source-projekter.

I dette afsnit deler vi erfaringer, refleksioner og yderligere analyser fra forskningen.

Under forskningen så vi, at Linux-vedligeholderne arbejdede hurtigt på at rette sårbarheder og beskytte brugerne. Scanningen blev udført på den nyeste Linux-kerne i midten af oktober 2026. Da den autonome scanning og den manuelle analyse var færdige efter 10 dage, var 61 LPE'er allerede rettet i hovedprojektet, 43 havde patches under klargøring, og 299 var ved at blive rapporteret og diskuteret offentligt.

Vi sætter stor pris på Linux-vedligeholdernes intensive arbejde med at rette de identificerede problemer og på det bredere sikkerhedsfællesskabs bidrag med egne fund. Det er netop en sådan fælles indsats, der skal til for at sikre verdens software. Det høje tempo i offentliggørelsen og rettelsen af sårbarheder understreger også, hvor afgørende det er, at brugere og virksomheder holder deres software opdateret.

Læring: Automatisk triage bør tage højde for den hurtige patchcyklus. Ved at validere fundene igen mod den nyeste kode, herunder kode, der er indarbejdet efter den oprindelige scanning, kan man undgå dubletter og forældede rapporter. Det retter opmærksomheden mod uløste sårbarheder og giver vedligeholderne dokumentation, de kan handle på, uden at pålægge dem unødigt gennemgangsarbejde.

Mens vi udviklede pipelinen, fandt og udnyttede GPT‑5.6 Sol i slutningen af juli 2026 166 unikke LPE-sårbarheder til en samlet pris på 513.690 USD i API-kreditter.

Ved den anden scanning i midten af oktober 2026 fandt og udnyttede den nyere cybermodel 948 unikke LPE-sårbarheder til en samlet pris på 1.213.430 USD i API-kreditter. I begge kampagner scannede vi den på det tidspunkt nyeste master-gren af Linux-kernen.

Læring: Scan tidligere gennemgået kode igen, efterhånden som modellerne bliver mere kapable. En mere kapabel model kan afdække sårbarheder, som tidligere modeller overså, selv med samme harness til forskningen.

Vi udtog en stikprøve på 166 exploits udviklet af agenterne og analyserede de anvendte udnyttelsesteknikker. Så vidt vi ved, brugte agenterne 10 nye udnyttelsesteknikker i stikprøvens exploits. Vi delte udnyttelsesteknikkerne med eksterne eksperter i kerneexploits, og teknikkerne var også nye for dem.

Af de 10 teknikker er to nye persistente elastiske objekter, som modellen brugte til at sprøjte objekter ind i den udvalgte kernecache. To er nye page grooming-teknikker, der øger exploitets pålidelighed. Fem er nye teknikker, som udelukkende manipulerer data for at opnå rettighedsforøgelse direkte eller via en vilkårlig skrivning. Den sidste teknik involverer vilkårlig typeforveksling. Af sikkerhedshensyn deler vi ikke de fulde tekniske detaljer om disse nye udnyttelsesteknikker i dette indlæg.

Læring: Banebrydende modeller genkender ikke blot kendte sårbare kodemønstre eller anvender udelukkende kendte udnyttelsesteknikker. De udviser kreativitet og finder nye tilgange.

En vigtig del af vores teams mission er at måle omkostningerne ved at finde og udnytte sårbarheder og bruge den viden til at vejlede investeringer i forsvar. Vores mål er at hjælpe sikkerhedsansvarlige med at rette sårbarheder, før angribere kan bruge dem, og gøre det uforholdsmæssigt dyrt for angribere at udnytte software. Ved at måle omkostningerne ved udnyttelse kan vi vurdere, hvordan udfordringen ændrer sig, efterhånden som modellerne bliver mere kapable. I dette afsnit sammenligner vi omkostningerne ved vores pipelinekørsel med bug bounty-programmers belønninger for de identificerede sårbarheder.

De virtuelle målmaskiner i vores forsøg kørte et standardoperativsystem til desktopbrug, ikke et svækket system, med den samme trusselsmodel som i cybersikkerhedskonkurrencer (f.eks. Pwn2Own⁠(åbner i et nyt vindue) og TyphoonPWN⁠(åbner i et nyt vindue)). Pwn2Own og TyphoonPWN har tidligere tilbudt bug bounty-belønninger på henholdsvis 20.000 og 70.000 USD for exploits til lokal rettighedsforøgelse i Linux-kernen. Anvender vi disse tidligere belønningsbeløb på de 948 exploits, giver det en hypotetisk værdi på 18,9–66,3 mio. USD, cirka 16 til 55 gange omkostningerne ved vores pipeline.

Vi testede også vores pipeline mod Googles belønningsprogram for sårbarheder, kernelCTF⁠(åbner i et nyt vindue), hvor målet er en sikkerhedshærdet Linux-kerne med reducerede angrebsflader. Vi kørte pipelinen på den nyeste version af Linux-kernen i kernelCTF-miljøet og opnåede 25 proofs of concept for informationslækage og 21 exploits til lokal rettighedsforøgelse. Kerneversionen var inkompatibel med SLAB_VIRTUAL-beskyttelsen i kernelCTF, så vi fjernede den fra konfigurationen. Til sammenligning har kernelCTF i skrivende stund accepteret 26 bekræftede 0-day-LPE-exploits i 2026. Hele kampagnen varede i alt 112 timer og kostede cirka 32.936 USD i API-kreditter. Sårbarhedssøgningen stod for 83,7 % af API-omkostningerne. Hvis programmet accepterede de 21 sårbarheder, ville det udløse en belønning på omkring 1,5 mio. USD, cirka 45 gange omkostningerne.

Læring: Ud fra offentlige belønningsbeløb var vores pipeline til sårbarhedsforskning på forskningstidspunktet rentabel med de daværende modeller med cyberkapacitet. Sikkerhedsansvarlige bør proaktivt analysere deres software, så det bliver uforholdsmæssigt dyrt for angribere at udnytte den.

Under vurderingen af udnyttelsesmuligheder fik ExploitDev-agenterne en sårbarhedsrapport og til opgave at skabe et fuldt fungerende exploit. Vores pipeline markerede en sårbarhed som udnyttet, hvis det lykkedes at få en root-shell. Under en tidlig kørsel rapporterede udnyttelsestrinnet 200 vellykkede exploits til lokal rettighedsforøgelse. Efter en menneskelig gennemgang fandt vi dog ud af, at 20 af dem havde opnået root-rettigheder via en anden 0-day-sårbarhed end den tildelte. Det tyder på, at agenters udnyttelse af sårbarheder skal valideres grundigt, selv når den lykkes.

Vi strammede efterfølgende opgavens rammer og tilføjede en uafhængig kontrol, som bekræftede, at hvert endeligt exploit brugte den tildelte sårbarhed.

Læring: Ved autonom sikkerhedsforskning skal både vejen til resultatet og selve resultatet verificeres. Isolering, overvågning og uafhængige kontroller er nødvendige kontrolforanstaltninger.

Tidligt i forskningen undersøgte vi, om vi skulle opbygge omfattende orkestrering omkring agenten for at forbedre dens cyberkapacitet. Vores resultat tydede på, at stærkere modeller kræver mindre orkestrering og vejledning. Og den marginale forbedring står ikke mål med vedligeholdelsesomkostningerne. Derfor besluttede vi at fjerne den omfattende orkestrering.

Forsøget sammenlignede GPT‑5.5 Cyber og GPT‑5.6 Cyber. Vi observerede, at GPT‑5.5 Cyber ikke konsekvent kunne identificere, hvornår og hvordan eksisterende teknikker til udnyttelse af sårbarheder i Linux-kernen skulle anvendes. Vi samlede derefter 103 teknikker i et modelvenligt format, gjorde dem tilgængelige i agentens miljø og instruerede agenten i at bruge dem. På tværs af 63 potentielt udnyttelige sårbarheder øgede det succesraten fra 76,2 % til 88,9 %.

Da vi gentog forsøget med GPT‑5.6 Cyber, var modellen bedre til selv at finde, vælge og anvende relevante teknikker. Vi fjernede orkestreringen af teknikker og færdigheder. Denne let orkestrerede arbejdsgang med GPT‑5.6 Cyber klarede sig bedre end arbejdsgangen med GPT‑5.5 Cyber og dens mere omfattende støttestruktur. Da vi tilføjede det ekstra tekniklag igen til GPT‑5.6 Cyber, gav det kun en marginal forbedring på 1,5 procentpoint.

Læring: Revurder orkestrering og harness, når grundmodellens kapacitet ændrer sig. En støttestruktur, der forbedrer én modelgeneration markant, kan tilføre en stærkere model begrænset værdi og bør vurderes i forhold til vedligeholdelsesbyrden.

Når modellen i begyndelsen blev bedt direkte om at generere patchforslag, skabte den funktionelt korrekte patches, der blokerede proof of concept-angrebet, men af og til skabte andre problemer: mere kode end nødvendigt, risiko for lavere ydeevne, afvigelser fra kodekonventioner eller manglende undersøgelse af relateret kode for varianter af samme sårbarhed. Det sidste førte til ufuldstændige patches.

Yderligere instruktioner og iterative forbedringer af patchgenereringsprocessen øgede patchenes kvalitet. Det tyder på, at AI-genererede sikkerhedspatches med den rette tilgang kan være korrekte, minimale og i overensstemmelse med eksisterende kodekonventioner. Det er et aktivt forskningsområde, og vi mener, at processen vil blive lettere og mere effektiv med fremtidige modeller. I nogle få tilfælde kunne vores forskningsprototype også identificere problemer i patches skrevet af menneskelige eksperter. Problemerne blev derefter rettet, før patchene blev indarbejdet.

Læring: Modeller kan fremskynde patchprocessen, men færdigheder og harness til patching kan kræve iterative forbedringer for at sikre, at patchene pålideligt opfylder både funktionelle og ikke-funktionelle krav. Vi anbefaler desuden at bruge modeller til at gennemgå menneske- og AI-genererede patches fra en angribers perspektiv. Det kan afsløre, om en patch kan omgås, overser andre angrebsveje eller varianter eller har andre problemer.

Under vores kernelCTF-kørsel fandt og udnyttede forskningsprototypen ud over de 21 0-day-exploits i Linux-kernen også en sårbarhed i QEMU TCG. Analyseagenten fik til opgave at analysere indgangskoden til systemkald. Da den skrev programmer til at eksperimentere med skift mellem rettighedsniveauer, stødte den på et uventet kernenedbrud. Den undersøgte nedbruddet og sporede problemet til QEMU TCG uden adgang til QEMU's kildekode og medtog sårbarheden i rapporten. ExploitDev-agenten udviklede efterfølgende et fungerende exploit til lokal rettighedsforøgelse for denne sårbarhed. Vi opdagede QEMU-sårbarheden under den manuelle analyse af vores exploits og bekræftede, at den var rettet i QEMU's hovedprojekt, men ikke i den udgivne version, som blev brugt i forsøget.

Læring: Banebrydende modeller med cyberkapacitet kan finde sårbarheder i testinfrastrukturen. Vi anbefaler at teste alle dele af infrastrukturen, før man udfører offensiv sårbarhedsforskning. Vi har proaktivt testet vores infrastruktur og offentliggjort og rettet mange sårbarheder i Kata, Moby/Docker, gVisor og andre projekter.

Vores mål er at omsætte modellernes voksende kapacitet til en varig fordel for dem, der sikrer internettet. Denne forskning viser, at banebrydende modellers voksende cyberkapacitet kan bruges til effektivt at finde sårbarheder i kompleks software som Linux-kernen. Ved at styrke sikkerheden i kritiske softwareprojekter som Linux og andre open source-projekter kan vi beskytte mange af de systemer og brugere, der er afhængige af dem.

Gennem Patch the Planet, et Daybreak-initiativ, vil vi udvide denne forskning til flere kritiske softwareprojekter og udvikle pålidelig automatisk patching sammen med vedligeholdere og sikkerhedspartnere. Vi vil løbende begrænse angribernes muligheder og øge omkostningerne ved at finde og udnytte sårbarheder, indtil det forventede udbytte ikke længere gør angrebet umagen værd.

Hver generation af modeller bør hjælpe os med at bygge software, som den næste generation får sværere ved at kompromittere. Vi vil fortsætte arbejdet med at skabe et sikkert internet, som alle kan bygge videre på med glæde.