Tusen færre veier til root

Sikkerhetsforskning som tidligere krevde en egen, langvarig undersøkelse av hvert funn, kan i stadig større grad gjennomføres som en systematisk prosess. Dette dokumentet beskriver ett av prosjektene våre på dette området.

Sårbarhetssøk blir enklere å skalere, men prioritering og validering er fortsatt flaskehalser i arbeidet. Vi bygde en prototype for å lete etter sikkerhetsfeil i Linux-kjernen i et kontrollert forskningsmiljø. Prototypen vår identifiserte og analyserte 2 308 mulige sårbarheter i Linux-kjernen, reproduserte 1 724 sårbarheter dynamisk og produserte 948 utnyttelser for lokal privilegieeskalering (LPE) som kunne gi en lokal bruker uten særskilte rettigheter root-tilgang.

Vi brukte denne dokumentasjonen til å prioritere hvilke sårbarheter som skulle rapporteres, og utviklet forslag til rettelser som vedlikeholderne kunne gjennomgå. Etter råd fra Linux-kjernemiljøet begynte vi med kritiske sårbarheter og samarbeider med Patch the Planet-partnere om flere rapporter og rettelser.

I juni delte vi, som en del av Patch the Planet-initiativet vårt, at GPT‑5.5 Cyber hadde identifisert sårbarheter i Linux-kjernen og utviklet 24 utnyttelser for lokal privilegieeskalering for å validere og rapportere dem. Vi utvidet dette arbeidet til en arbeidsflyt drevet av en kommende cybermodell, som omfatter sårbarhetssøk, dynamisk validering, vurdering av utnyttbarhet og generering av rettelser. Da kjøringen var ferdig, gikk menneskelige forskere gjennom resultatene og rapporterte sårbarhetene sammen med rettelser.

Linux-kjernen er grunnlaget for Android-enheter, skyinfrastruktur, superdatamaskiner og andre systemer som brukes av milliarder av mennesker. Med mer enn 40 millioner kodelinjer har kjernen en bred angrepsflate gjennom systemkall, nettverk, filsystemer og enhetsdrivere. Vi valgte Linux for å undersøke hvor effektivt banebrytende modeller kunne finne sårbarheter og demonstrere sikkerhetskonsekvensene i en kodebase av denne størrelsen og betydningen.

Det innledende sårbarhetssøket ga tusenvis av mulige funn, for mange til at sikkerhetsforskere kunne gjennomgå og prioritere dem manuelt. Den praktiske utfordringen i arbeidsflyten vår var ikke å finne sårbarheter, men å avgjøre hvilke funn som kunne reproduseres, hvilken sikkerhetsgrense de krysset, og hvilke vedlikeholderne burde ta tak i først.

Oppdraget til OpenAIs Cyber-team er å bidra til å sikre programvaren verden er avhengig av. Vi oppgir API-kostnadene for hvert trinn for å hjelpe forskere med å vurdere ressursene som trengs for å gjenskape og videreutvikle dette arbeidet. Disse kostnadene gjenspeiler modellene, målkonfigurasjonene og arbeidsflyten som ble brukt i denne evalueringen. Det overordnede målet vårt er å hjelpe sikkerhetsansvarlige med å finne og rette sårbarheter, slik at angripere får færre muligheter og høyere kostnader ved å utnytte programvare.

Merk til slutt at vi i denne forskningen fokuserte på metode og måling av modellenes kapasitet, ikke på kostnader. Vi forventer at tilstrekkelig videreutvikling av rammeverket kan redusere kostnaden for hvert trinn vesentlig. Kostnadene vi oppgir, er derfor snarere en øvre grense.

Prototypen vår for sårbarhetsforskning er en arbeidsflyt i fem trinn, med en kommende cybermodell som kjerne:

• Sårbarhetssøk: Agenter identifiserer sikkerhetsrelevante deler av kodebasen og skanner dem etter mulige sårbarheter.

• Dynamisk validering: Agenter forsøker å reprodusere hver kandidat i et isolert miljø og tar vare på dokumentasjon fra kjøringen. Dette trinnet leverer de reproduserte og validerte sårbarhetene.

• Vurdering av utnyttbarhet: Agenter tester om validerte sårbarheter kan muliggjøre informasjonslekkasje eller lokal privilegieeskalering.

• Generering av rettelser: Agenter genererer rettelser for hver identifiserte sårbarhet.

• Menneskelig gjennomgang: Sikkerhetsforskere gjennomgår utnyttelseskoden, rettelsen og den foreslåtte alvorlighetsgraden før de rapporterer til vedlikeholderne.

Til slutt samler systemet en rotårsaksanalyse, minimal demonstrasjonskode som utløser krasj, et forslag til rettelse og fullstendig utnyttelseskode. Dette hjelper menneskelige forskere med å vurdere sårbarhetens alvorlighetsgrad og få rettelsene inn i hovedprosjektet.

Ikke alle kodelinjer i Linux-kjernen er sikkerhetsrelevante. Arbeidsflyten vår brukte et team av speideragenter til å finne områder det var særlig verdifullt å granske. Disse ble så sendt videre til analyseagenter for sårbarhetsskanning.

Speideragenter leser gjennom hver mappe og fil og bestemmer hvilke områder som skal granskes, ut fra om de er tilgjengelige for brukere med begrensede rettigheter, og hvor sikkerhetsrelevante de er.

Dette trinnet identifiserte 5 034 områder for gransking, omtrent 2,8 millioner kodelinjer. Det utgjør rundt 7 % av hele Linux-kjernens kodebase og reduserte kostnaden for sikkerhetsgjennomgangen betydelig sammenlignet med en analyse av hele kodebasen. Dette trinnet kostet 3 426 dollar i API-kreditter.

Deretter analyserte analyseagentene hvert utvalgte område og identifiserte mulige sårbarheter med en arbeidsflyt som lignet den i Codex Security-pluginen⁠(åpnes i et nytt vindu). I grove trekk leser analyseagentene koden i det tildelte området for å forstå hvordan den fungerer, identifisere trusselmodellen og lete etter sårbarheter.

I løpet av 12 timer identifiserte analyseagentene 2 308 mulige sårbarheter etter at duplikater var fjernet. Dette trinnet kostet 316 549 dollar i API-kreditter.

Et mulig funn er ikke det samme som en validert sårbarhet. I denne skalaen er det ikke praktisk mulig for forskningsteamet vårt å undersøke hver rapport manuelt.

Vi fokuserte derfor på å validere funn som a) var tilgjengelige for en bruker med begrensede rettigheter, b) ikke krevde spesielle tilgangsrettigheter, og c) ga målbare bevis på minnekorrupsjon.

For hver kandidat genererte en triageagent demonstrasjonskode og kjørte den i en isolert virtuell maskin med en Linux-kjerne med Kernel Address Sanitizer (KASAN). Agenten observerte både programmets utdata og systemkonsollen og forbedret demonstrasjonskoden trinnvis til den reproduserte den rapporterte atferden eller hadde prøvd alle mulige måter å utløse den på.

I løpet av 30 timer reproduserte systemet vårt 1 724 sårbarheter, omtrent 74,7 % av de 2 308 mulige funnene. Statisk kodegjennomgang alene kan gi falske positiver. Derfor var vi imponert over analyseagentenes nøyaktighet og hvor effektivt triageagentene selvstendig laget fungerende demonstrasjonskode for nesten tre fjerdedeler av de mulige funnene.

De fleste gjenværende funnene krevde enten utvidede rettigheter eller lot seg ikke reprodusere innen tidsrammen på grunn av vanskelige kappløpstilstander, spesifikke utløsningsbetingelser (f.eks. at en allokering måtte feile på en bestemt linje) eller tidkrevende validering (f.eks. at en referanseteller måtte løpe rundt). Bare 3,1 % skyldtes feil analyse fra modellen, der den rapporterte sårbarheten forutsatte en umulig tilstand.

Valideringstrinnet kostet totalt 73 330 dollar i API-kreditter. Vi observerte at valideringsflyten vår, som måtte generere demonstrasjonskode for å bekrefte om en kandidat var en reell sårbarhet, var dyrere enn å gi en anbefaling basert bare på statisk analyse. Kostnadene ved å forsøke å validere sanne og falske positiver var dessuten omtrent like. Å fjerne falske positiver tidligere i arbeidsflyten gjør derfor prosessen vesentlig mer kostnadseffektiv.

Validering fastslår at en sårbarhet er reell, men ikke hvor raskt den bør håndteres. En sårbarhet som kan muliggjøre lokal privilegieeskalering, bør for eksempel prioriteres høyere enn en som bare kan forårsake lokal tjenestenekt. Med 1 724 validerte sårbarheter var neste oppgave å identifisere funnene med størst potensiell sikkerhetskonsekvens.

En innledende utsilingsagent gjennomgikk hver rapport, krasjlogg og relevant kildekode statisk. Den hadde bevisst en lav terskel for å ta funn videre, slik at potensielt alvorlige funn ikke ble forkastet, samtidig som den filtrerte bort tilfeller uten en plausibel utnyttelsesvei. Dette reduserte resultatene til 313 kandidater for informasjonslekkasje og 1 238 kandidater for lokal privilegieeskalering.

Agenter for utvikling av utnyttelseskode (ExploitDev) testet deretter kandidatene i isolerte virtuelle maskiner med beskyttelsene som er aktivert i en standard Linux-distribusjon, blant annet Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) og HARDENED_USERCOPY. Dette bidro til å unngå urealistiske vurderinger som forutsatte at beskyttelser var deaktivert.

Agentene produserte 291 demonstrasjonskoder for informasjonslekkasjer og 1 169 fungerende utnyttelser for lokal privilegieeskalering som kunne gi lokale brukere uten særskilte rettigheter root-tilgang.

Vi utførte variantanalyse og utviklet 948 ulike rettelser for sårbarhetene bak disse utnyttelsene. Vi bruker dette tallet som samlet antall unike LPE-sårbarheter. Vellykket utnyttelseskode kostet i gjennomsnitt 359 dollar i kreditter å utvikle. Det gjør det relativt rimelig for sikkerhetsansvarlige å teste om sårbarhetene de finner, kan utnyttes.

Den innledende agenten for utsiling av sårbarheter kostet 44 194 dollar i API-kreditter. Utnyttelsestrinnet kostet totalt 775 929 dollar i API-kreditter: 84 929 dollar for behandling av kandidater for informasjonslekkasje og 691 000 dollar for kandidater for lokal privilegieeskalering.

I gjennomsnitt var det omtrent dobbelt så dyrt å behandle en kandidat for lokal privilegieeskalering (558 dollar) som en kandidat for informasjonslekkasje (271 dollar). Det skyldes at demonstrasjonskode for informasjonslekkasje ble videreført fra valideringstrinnet og krevde færre endringer for å kunne brukes i en utnyttelse. Å utvikle utnyttelseskode fra en LPE-kandidat krevde derimot mange ekstra trinn, som å planlegge utnyttelsesstrategien, identifisere sårbare objekter å bruke, omgå beskyttelsestiltak og mer. Vi la også merke til at mislykkede utnyttelsesforsøk (3 922 dollar for 69 tilfeller) kostet langt mer enn vellykkede forsøk (360 dollar for 1 169 tilfeller). Dette skyldtes noen få sårbarheter som var vanskelige å utnytte, for eksempel kappløpstilstander. En rimelig stoppbetingelse, som å avslutte forsøket etter én time uten fremgang, ville ha redusert kostnaden for ExploitDev betydelig.

For hver validerte sårbarhet genererer systemet også en rettelse. Vi gir modellen den relevante kildekoden og instruerer den i beste praksis for rettelser: å utføre statiske kontroller av rettelsen, følge utviklingspraksisen i den omkringliggende koden og utføre variantanalyse for å sikre at rettelsen er fullstendig.

Etter forslag fra Linux-kjernemiljøet har vi allerede sendt ut hundrevis av rapporter og rettelser for kritiske sårbarheter. Vi samarbeider med Patch the Planet-partnere om gradvis å sende ut rettelser for resten. Dette arbeidet er en del av vår bredere Daybreak-satsing på å støtte prosjekter med åpen kildekode.

I denne delen deler vi lærdommer, refleksjoner og ytterligere analyser fra forskningen.

Under forskningen så vi at Linux-vedlikeholderne handlet raskt for å rette sårbarheter og beskytte brukerne. Skanningen ble utført på den nyeste Linux-kjernen i midten av oktober 2026. Da den autonome skanningen og den manuelle analysen var ferdig etter ti dager, var 61 LPE-sårbarheter allerede rettet i hovedprosjektet, 43 hadde rettelser klare til testing, og 299 var under offentlig rapportering og diskusjon.

Vi setter stor pris på Linux-vedlikeholderne som har jobbet raskt med å rette identifiserte problemer, og på det bredere sikkerhetsmiljøet som også bidrar med sine funn. Denne felles innsatsen er det som trengs for å sikre verdens programvare. Det høye tempoet i offentliggjøring og retting av sårbarheter understreker også hvor avgjørende det er at brukere og bedrifter holder programvaren oppdatert.

Lærdom: Automatisert triage bør ta hensyn til at rettelser kommer raskt. Ved å validere funn på nytt mot den nyeste koden, inkludert kode som ble innlemmet etter den opprinnelige skanningen, kan man unngå dupliserte eller utdaterte rapporter. Dette retter oppmerksomheten mot uløste sårbarheter og gir vedlikeholderne dokumentasjon de kan handle på, uten å påføre dem unødvendig granskningsarbeid.

Mens vi utviklet arbeidsflyten, i slutten av juli 2026, fant og utnyttet GPT‑5.6 Sol 166 unike LPE-sårbarheter til en samlet kostnad på 513 690 dollar i API-kreditter.

I den andre skanningen, i midten av oktober 2026, fant og utnyttet den nyere cybermodellen 948 unike LPE-sårbarheter til en samlet kostnad på 1 213 430 dollar i API-kreditter. I begge kampanjene skannet vi den til enhver tid nyeste master-grenen av Linux-kjernen.

Lærdom: Skann tidligere gransket kode på nytt etter hvert som modellene blir mer kapable. En mer kapabel modell kan avdekke sårbarheter som tidligere modeller overså, selv med det samme forskningsrammeverket.

Vi tok et utvalg på 166 utnyttelser utviklet av agentene og analyserte teknikkene som ble brukt i dem. Så vidt vi vet, brukte agentene ti nye utnyttelsesteknikker i dette utvalget. Vi delte teknikkene med eksterne eksperter på utnyttelse av kjernesårbarheter, og teknikkene var nye også for dem.

Av de ti teknikkene er to nye persistente, elastiske objekter som modellen brukte til å spre objekter i den aktuelle kjernecachen. To er nye teknikker for tilrettelegging av minnesider som gjør utnyttelsen mer pålitelig. Fem er nye teknikker som bare manipulerer data for å oppnå privilegieeskalering direkte eller via vilkårlig skriving. Den siste teknikken involverer vilkårlig typeforveksling. Av sikkerhetshensyn deler vi ikke alle de tekniske detaljene om disse nye utnyttelsesteknikkene i dette innlegget.

Lærdom: Banebrytende modeller gjenkjenner ikke bare kjente sårbare kodemønstre eller bruker utelukkende kjente utnyttelsesteknikker. De viser kreativitet og nye tilnærminger.

En viktig del av teamets oppdrag er å måle kostnaden ved å finne og utnytte sårbarheter og bruke denne kunnskapen til å veilede investeringer i sikkerhet. Målet vårt er å hjelpe sikkerhetsansvarlige med å rette sårbarheter før angripere kan bruke dem, og gjøre det ulønnsomt for angripere å utnytte programvare. Ved å måle kostnadene ved utnyttelse kan vi vurdere hvordan denne utfordringen endrer seg etter hvert som modellene blir mer kapable. I denne delen sammenligner vi kostnaden for kjøringen vår med dusørene som sårbarhetsprogrammer tilbyr for de identifiserte sårbarhetene.

De virtuelle målmaskinene i eksperimentet vårt kjørte et standard operativsystem for skrivebord, ikke et svekket mål, med samme trusselmodell som brukes i cybersikkerhetskonkurranser (f.eks. Pwn2Own⁠(åpnes i et nytt vindu), TyphoonPWN⁠(åpnes i et nytt vindu)). Pwn2Own og TyphoonPWN har tidligere tilbudt dusører på henholdsvis 20 000 og 70 000 dollar for utnyttelser for lokal privilegieeskalering i Linux-kjernen. Bruker vi disse tidligere dusørbeløpene på de 948 utnyttelsene, gir det en hypotetisk verdi på 18,9–66,3 millioner dollar, omtrent 16 til 55 ganger kostnaden for arbeidsflyten vår.

Vi testet også arbeidsflyten mot Googles dusørprogram for sårbarheter, kernelCTF⁠(åpnes i et nytt vindu), der målet er en herdet Linux-kjerne med reduserte angrepsflater. Vi kjørte arbeidsflyten på den nyeste versjonen av Linux-kjernen i kernelCTF-miljøet. Denne var inkompatibel med SLAB_VIRTUAL-beskyttelsen i kernelCTF, så vi fjernet den fra konfigurasjonen. Kjøringen ga 25 demonstrasjonskoder for informasjonslekkasje og 21 utnyttelser for lokal privilegieeskalering. Til sammenligning har kernelCTF i skrivende stund godkjent 26 bekreftede LPE-utnyttelser av nulldagssårbarheter i 2026. Hele kampanjen varte i totalt 112 timer og kostet omtrent 32 936 dollar i API-kreditter. Sårbarhetssøket sto for 83,7 % av API-kostnaden. Hvis de 21 sårbarhetene ble godkjent av programmet, ville det gitt en dusør på rundt 1,5 millioner dollar, omtrent 45 ganger kostnaden.

Lærdom: Basert på offentlig kjente utbetalingsbeløp var arbeidsflyten vår for sårbarhetsforskning netto lønnsom på forskningstidspunktet, med dagens modeller med cyberkapasitet. Sikkerhetsansvarlige bør analysere programvaren sin proaktivt, slik at den blir ulønnsom for angripere å utnytte.

Under vurderingen av utnyttbarhet fikk ExploitDev-agenter en sårbarhetsrapport og i oppgave å lage fullt fungerende utnyttelseskode. Arbeidsflyten markerte en sårbarhet som utnyttet hvis den lyktes med å oppnå et root-skall. Under en tidlig kjøring rapporterte utnyttelsestrinnet 200 vellykkede utnyttelser for lokal privilegieeskalering. Etter menneskelig gjennomgang fant vi imidlertid at 20 av disse hadde oppnådd root-rettigheter gjennom en annen nulldagssårbarhet enn den de var tildelt. Dette tyder på at også agenters vellykkede utnyttelser må valideres grundig.

Vi strammet deretter inn oppgavens rammer og la til en uavhengig kontroll som bekreftet at hver ferdige utnyttelseskode brukte den tildelte sårbarheten.

Lærdom: I autonom sikkerhetsforskning må man kontrollere veien frem til resultatet, ikke bare selve resultatet. Isolasjon, overvåking og uavhengige kontroller er nødvendige sikkerhetstiltak.

Tidlig i forskningen undersøkte vi om vi burde bygge omfattende orkestrering rundt agenten for å forbedre cyberkapasiteten. Resultatet tydet på at sterkere modeller trenger mindre orkestrering og veiledning. Den marginale forbedringen rettferdiggjør heller ikke vedlikeholdskostnaden. Derfor bestemte vi oss for å fjerne den omfattende orkestreringen.

Eksperimentet sammenlignet GPT‑5.5 Cyber og GPT‑5.6 Cyber. Vi observerte at GPT‑5.5 Cyber ikke konsekvent gjenkjente når og hvordan eksisterende teknikker for utnyttelse av Linux-kjernen skulle brukes. Vi samlet derfor 103 teknikker i et modellvennlig format, gjorde dem tilgjengelige i agentens miljø og ba agenten bruke dem. For 63 kandidater til utnyttelse økte dette suksessraten fra 76,2 % til 88,9 %.

Da vi gjentok dette med GPT‑5.6 Cyber, var modellen bedre i stand til å finne, velge og bruke relevante teknikker på egen hånd. Vi fjernet orkestreringen av teknikker og ferdigheter. Denne enklere orkestrerte GPT‑5.6 Cyber-arbeidsflyten presterte bedre enn GPT‑5.5 Cyber-arbeidsflyten med mer omfattende støttestruktur. Da vi la det ekstra teknikklaget tilbake for GPT‑5.6 Cyber, ga det bare en marginal forbedring på 1,5 prosentpoeng.

Lærdom: Vurder orkestreringen og rammeverket på nytt når grunnmodellens kapasitet endrer seg. Støttestrukturer som gir en vesentlig forbedring for én modellgenerasjon, kan tilføre lite verdi for en sterkere modell. Verdien bør derfor veies opp mot vedlikeholdsbehovet.

I starten, når modellen ble bedt direkte om å generere forslag til rettelser, laget den funksjonelt korrekte rettelser som stoppet demonstrasjonskoden, men av og til skapte andre problemer. De kunne inneholde mer kode enn nødvendig, potensielt svekke ytelsen eller avvike fra kodekonvensjonene. Modellen unnlot også noen ganger å undersøke beslektet kode for varianter av samme sårbarhet, noe som ga ufullstendige rettelser.

Flere instruksjoner og gjentatte forbedringer av prosessen for å generere rettelser økte kvaliteten. Det tyder på at AI-genererte sikkerhetsrettelser, med riktig tilrettelegging, kan være korrekte, minimale og i tråd med eksisterende kodekonvensjoner. Dette er et aktivt forskningsområde, og vi tror arbeidet vil bli enklere og mer effektivt med fremtidige modeller. I noen få tilfeller klarte forskningsprototypen vår også å identifisere problemer i rettelser skrevet av menneskelige eksperter. Disse ble så utbedret før rettelsene ble innlemmet.

Lærdom: Modeller kan gjøre feilrettingen raskere, men ferdigheter og rammeverk for feilretting kan kreve gjentatte forbedringer for å sikre at rettelsene pålitelig oppfyller både funksjonelle og ikke-funksjonelle krav. Vi anbefaler også å bruke modeller til å granske både menneske- og AI-genererte rettelser fra en angripers perspektiv. Det kan avdekke om rettelsen kan omgås, om den overser andre angrepsveier eller varianter, og andre problemer.

I kernelCTF-kjøringen vår fant og utnyttet forskningsprototypen også en sårbarhet i QEMU TCG, i tillegg til de 21 utnyttelsene av nulldagssårbarheter i Linux-kjernen. Analyseagenten fikk i oppgave å analysere inngangskoden for systemkall. Da den skrev programmer for å eksperimentere med overganger mellom privilegienivåer, støtte den på et uventet kjernekrasj. Den undersøkte krasjet, sporet problemet til QEMU TCG uten tilgang til QEMUs kildekode og inkluderte sårbarheten i rapporten. ExploitDev-agenten utviklet deretter fungerende kode for lokal privilegieeskalering via denne sårbarheten. Vi oppdaget denne QEMU-sårbarheten da vi analyserte utnyttelseskoden manuelt, og bekreftet at sårbarheten var rettet i QEMUs hovedprosjekt, men ikke i utgivelsesbygget som ble brukt under eksperimentet.

Lærdom: Banebrytende modeller med cyberkapasitet kan finne sårbarheter i testinfrastruktur. Vi anbefaler å teste hver del av infrastrukturen før man gjennomfører offensiv sårbarhetsforskning. Vi har testet infrastrukturen vår proaktivt og offentliggjort og rettet mange sårbarheter i Kata, Moby/Docker, gVisor og andre prosjekter.

Målet vårt er å gjøre modellenes økende kapasitet til et varig fortrinn for dem som sikrer internett. Denne forskningen viser at banebrytende modellers økende cyberkapasitet kan brukes til å lete effektivt etter sårbarheter i kompleks programvare, som Linux-kjernen. Å herde kritiske programvareprosjekter som Linux og andre prosjekter med åpen kildekode kan beskytte mange systemer og brukere som er avhengige av dem.

Gjennom Patch the Planet, et Daybreak-initiativ, vil vi utvide denne forskningen til flere kritiske programvareprosjekter og utvikle pålitelig automatisert feilretting sammen med vedlikeholdere og sikkerhetspartnere. Vi vil gradvis redusere angripernes muligheter og øke kostnaden ved å finne og utnytte sårbarheter, til den forventede gevinsten ikke lenger rettferdiggjør angrepet.

Hver modellgenerasjon bør hjelpe oss med å bygge programvare som den neste generasjonen får vanskeligere for å kompromittere. Vi vil fortsette arbeidet med å bygge et sikkert internett som alle kan ha glede av å skape noe på.