Computeren sagde nej. AI’en fandt en anden vej
Et program starter med begrænsede rettigheder og ender med computerens hovednøgle. OpenAI beskriver, hvordan AI kan finde vejen. Men forsøget rummer også en mere besværlig opdagelse: At nå frem er ikke det samme som at have bevist, hvordan man kom derhen.
I «A thousand fewer paths to root», offentliggjort 4. november, oplyser OpenAI, at et forskningssystem med en kommende cybermodel fandt 948 særskilte muligheder for lokal privilegieeskalering i Linux og udarbejdede forslag til rettelser.1
Det lyder som en historie om en særligt dygtig indbrudstyv. Men det afgørende ord er rettigheder. Et program kan allerede være inde på en computer og stadig være afskåret fra at bestemme over resten.
Hovednøglen hedder root
På en computer får et program en identitet og et sæt tilladelser. Det kan eksempelvis få lov at læse dine dokumenter uden at få lov til at ændre systemets indstillinger eller læse en anden brugers filer. Kernen er den centrale del af operativsystemet, som blandt andet håndhæver den opdeling.2
Root er navnet på den traditionelle superbruger i Unix-systemer, som Linux bygger videre på idéer fra. Den kan omgå mange af de sædvanlige adgangskontroller. Derfor er hovednøglen et brugbart billede.3
Billedet har en grænse. Moderne Linux kan opdele privilegier i mindre enheder og bruge flere lag af isolation. Root inde i ét afgrænset miljø er ikke automatisk herredømme over alle andre computere omkring det.
For en almindelig bruger er forskellen praktisk: Et program, der får adgang til mere end sin opgave kræver, kan gøre mere skade, hvis det fejler eller bliver misbrugt. Det gælder også et program, som man selv har bedt om hjælp.
En regel fra længe før ChatGPT
I 1975 beskrev Jerome Saltzer og Michael Schroeder et princip, der stadig er let at forstå: Programmer og brugere bør kun arbejde med de rettigheder, som deres opgave kræver.4
Det var en del af en større undersøgelse af, hvordan mennesker kan dele computersystemer uden at få samme magt over hinandens information. Spørgsmålet var både teknisk og organisatorisk: Hvem må se en oplysning, og hvem må ændre den?
Tænk på en medarbejder, der skal rette en stavefejl i et dokument. Opgaven kræver adgang til dokumentet. Den kræver normalt ikke adgang til virksomhedens lønarkiv. At medarbejderen er identificeret og ansat, besvarer ikke alene spørgsmålet om, hvad vedkommende skal have lov til.
Det er samme skel, vi nu skal forstå, når en AI får værktøjer og kan starte programmer på vores vegne. Tilliden til hjælperen og begrænsningen af dens adgang er to forskellige forhold.
Illustration: Folkets. Grundlag: Linux-dokumentationen og Saltzer/Schroeder.. Datagrundlag.
Angriberen kan allerede være indenfor
Lokal privilegieeskalering betyder, at kode, der allerede kan køre på det berørte system med begrænsede rettigheder, skaffer sig større beføjelser. Den kan være et senere led i et angreb. Begrebet betyder ikke i sig selv, at en person ude på internettet kan overtage maskinen uden først at opnå adgang.
Linux-projektets egen beskrivelse af trusselsmodellen gør netop isolation mellem brugere og beskyttelse af systemets tilstand til centrale opgaver for kernen.2 Hvis en almindelig proces kan bryde den grænse gennem en fejl, rammer det en af systemets grundlæggende aftaler.
Derfor er det heller ikke nok at spørge, om en bruger har logget ind lovligt. En legitim adgang til en afgrænset opgave skal kunne forblive afgrænset, også når programmet stiller uventede krav.
Tre tal, der beskriver forskellige ting
OpenAI opgiver disse trin i forsøget:1
| Trin | Antal |
|---|---|
| Mulige fund | 2.308 |
| Fejl genskabt i test | 1.724 |
| Særskilte eskaleringsfund | 948 |
De 948 er selskabets optælling efter analyse af varianter og udarbejdelse af særskilte rettelsesforslag. Tallene er OpenAI's egne resultater. Selskabet udvikler selv modellerne og har en kommerciel interesse i deres anvendelse. De dokumenterer ikke, at alle fund var hidtil ukendte, at alle rettelser er godkendt, eller at alle berørte installationer er opdateret.
Forskellen mellem en mistanke og en genskabt fejl er væsentlig. En rapport kan lyde overbevisende og stadig bygge på en situation, som ikke kan opstå. En reproducerbar hændelse giver udvikleren noget konkret at undersøge.
Den rigtige hovednøgle gennem den forkerte dør
I et tidligt forsøg registrerede OpenAI 200 vellykkede eskaleringer. Ved menneskelig gennemgang viste 20 sig at bruge en anden hidtil ukendt sårbarhed end den, agenten var sat til at undersøge. Holdet indførte derefter en særskilt kontrol af angrebsvejen.1
Set fra den angrebne maskine var resultatet alvorligt: Adgangsgrænsen var overskredet. Set fra forskernes opgave var det utilstrækkeligt. De ville afgøre, om en bestemt fejl kunne udnyttes. Hvis adgangen kom gennem en anden fejl, var netop det spørgsmål stadig ubesvaret.
Det er som at undersøge en defekt lås og opdage, at testpersonen kom ind gennem et åbent vindue. Indtrængningen er virkelig. Den fortæller bare ikke, om låsen virker.
Den forskel rækker ud over sikkerhedsforskning. Når vi bedømmer en AI efter, om skærmen viser det ønskede resultat, kan vi overse, hvilke tilladelser den brugte, og hvilke antagelser der faktisk blev prøvet af. Resultatkontrol og kontrol af fremgangsmåden har hver sin opgave.
Et hul er først lukket, når arbejdet er gjort
Linux-udviklernes vejledning kræver blandt andet en præcis version, en beskrivelse af problemet og en måde at genskabe det på. Betingelser som indstillinger og nødvendige tilladelser skal også fremgå. Allerede rettede fejl er en kendt kilde til overflødige rapporter.5
Det forklarer, hvorfor en stor stak AI-fund kan være både en hjælp og en arbejdsbyrde. Den nyttige rapport gør det lettere at afgøre, hvad der er galt, og om rettelsen virker. Den mangelfulde flytter undersøgelsen over til dem, der allerede har ansvaret for at vedligeholde systemet.
Et rettelsesforslag skal gennemgås. En godkendt ændring skal nå de versioner, folk bruger. Og installationerne skal faktisk opdateres. Antallet af fund og antallet af beskyttede computere er derfor forskellige mål for fremskridt.
Hjælperen behøver heller ikke hele huset
En sandbox er et afgrænset miljø, hvor et program får et mindre område at arbejde i. Projektet gVisor beskriver eksempelvis en løsning, der lægger et ekstra softwarelag mellem et program og værtsystemet. Formålet er at mindske den direkte kontakt med værtskernens funktioner.6
Sådan isolation er et supplement til begrænsede rettigheder. Den gør heller ikke de oplysninger ufølsomme, som man faktisk lægger ind i miljøet. Et program kan stadig misbruge adgang, det allerede har fået.
For en dansk virksomhed, der giver en AI adgang til filer eller udviklingsværktøjer, er den gamle regel derfor meget nutidig: Giv adgang ud fra opgaven, og undersøg både det udførte arbejde og den vej, programmet tog.
I historien om den hemmelige besked til eksperternes AI handlede det om påvirkning gennem information. Her handler det om de tekniske grænser for handling. Begge spørgsmål bliver konkrete, når hjælperen får lov at gøre noget.
Den dygtigste hjælper kan have brug for en nøgle. Den behøver ikke af den grund alle nøglerne.
OpenAI: «A thousand fewer paths to root», 4. november 2026. Selskabets forskningsbeskrivelse, herunder optælling efter variantanalyse og afsnittet om den forkerte sårbarhed i et tidligt forsøg. Resultaterne er ikke uafhængigt reproduceret af Folkets. Ingen angrebskode er afprøvet. ↩ ↩ ↩
Linux-kernens dokumentation: trusselsmodel. Ansvar for isolation, tilladelser og beskyttelse af systemets tilstand. At et program kan køre lokalt, er ikke det samme som at have ret til at ændre hele systemet. ↩ ↩
Linux manual pages: capabilities. Traditionel root-identitet og opdeling i særskilte privilegier. Hovednøglen er en forklarende metafor; den ophæver ikke betydningen af isolation og andre sikkerhedslag. ↩
Jerome Saltzer og Michael Schroeder: «The Protection of Information in Computer Systems», principper. Forfatterens publikationsliste daterer artiklen til september 1975. Princippet om mindst mulige privilegier er gengivet med egne ord. ↩
Linux-kernens dokumentation: sikkerhedsfejl og krav til rapporter. Versionsangivelse, reproducerbarhed, betingelser og forslag til rettelse. Skellet mellem forslag, godkendelse og installeret rettelse er en del af denne histories forklaring, ikke en opgørelse over OpenAI-fundenes aktuelle status. ↩
gVisor: introduktion til sikkerhedsarkitekturen. Projektets egen forklaring af isolation og dens begrænsninger. Omtalen er et eksempel på et ekstra sikkerhedslag, ikke en anbefaling af en bestemt løsning til alle installationer. ↩