CVE-2026-31431 (Copy Fail) - Slik reduserte vi risikoen

Forrige uke ble en alvorlig lokal rettighetseskaleringsfeil i Linux-kjernen offentliggjort: CVE-2026-31431, med kallenavnet "Copy Fail". Den påvirker et bredt utvalg av kjerneversjoner i moderne Linux-distribusjoner, og en offentlig utnyttelse dukket raskt opp etter offentliggjøringen.

Jeg vil være tydelig på hva som skjedde, hva det betyr for Appbox, og hva vi har gjort med det. Kortversjonen: takket være måten containerne våre er bygget på, var apper som kjører med ommapping av brukernavnerom allerede beskyttet mot at dette kunne bli til host root, selv før patchede kjerner ble rullet ut. I går (4. mai 2026) utførte vi også nødvedlikehold for å oppgradere alle servere til en patchet kjerne, så feilen er nå helt borte fra flåten vår.

Hva er "Copy Fail"?

CVE-2026-31431 er en feil i kjernens kryptografiske AF_ALG-API. Ved å binde seg til en bestemt cipher (authencesn(hmac(sha256),cbc(aes))) og misbruke måten kjernen spleiser sider inn i en scratch-buffer på, kan en uprivilegert lokal bruker skrive vilkårlige 4-byte-biter direkte inn i page cache for filer de ikke skal ha tillatelse til å endre - inkludert SUID-binærfiler som /usr/bin/su.

Når page cache-kopien av su er overskrevet med en liten ondsinnet ELF, kjører neste kall angriperens kode som UID 0. Da er spillet over for verten.

For de grundige tekniske detaljene (shellcode-disassemblering, syscall-spor, hele pakken) er Andrea Veris gjennomgang utmerket: CVE-2026-31431: Copy Fail vs. rootless containers. Han gjorde også arbeidet med å demonstrere - med eBPF og uid_map-bevis - akkurat det vi skal snakke om nå: at brukernavnerom nøytraliserer denne utnyttelsen.

Hvorfor Appbox-apper allerede var beskyttet

Utnyttelsen er avhengig av at setuid(0) faktisk gir host root. I en container som kjører med brukernavnerom aktivert, er det ikke det som skjer.

Brukernavnerom mapper containerens UID-rom til et annet (uprivilegert) UID-område på verten. Så når utnyttelsen lykkes inne i containeren og setuid(0) returnerer suksess, blir det resulterende "root"-skallet mappet til en vanlig uprivilegert vertsbruker - ikke ekte root. Shellcode kjører, prompten endres til #, men på verten:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

Det er alt. Ingen tilgang til vertsfiler, ingen /etc/shadow, ingen host root. Containerens navneromsgrense stopper dette fra å bli en host-root-flukt.

På plattformnivå får hver Appbox sin egen Docker-daemon startet med ommapping av brukernavnerom aktivert. I pseudokode ser det mer slik ut:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Den mappningen støttes av et dedikert underordnet UID/GID-område på verten:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

I tillegg kan appdefinisjoner fortsatt eksplisitt overstyre UsernsMode når en app trenger særskilt håndtering:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

Den presise måten å beskrive det på er derfor: ommapping av brukernavnerom er en del av plattformens standardoppsett, og unntak per app er eksplisitte. Det finnes et lite antall apper som trenger andre innstillinger fordi de eksponerer funksjonalitet som krever ekstra kapabiliteter, og disse tilfellene håndteres separat.

Med andre ord: for apper som kjører med det normale ommappede oppsettet, kunne Copy Fail ikke gjøre et containerkompromiss om til host root.

Hva vi likevel ville fikse

Brukernavnerom stopper vertflukten, men de får ikke feilen til å forsvinne inne i containeren. En angriper kunne fortsatt eskalere til "container root" innenfor appgrensen, noe som, selv om det er isolert, fortsatt er dårlig hygiene. Selve kjernen var sårbar, og vi ville ha det bort.

Så snart vi fikk vite om feilen, begynte vi umiddelbart å vurdere eksponeringen vår. Selv om ommapping av brukernavnerom allerede blokkerte host-escape-siden av problemet for vårt normale appoppsett, ønsket vi fortsatt å fjerne den underliggende kjernefeilen så raskt som mulig.

Hva vi gjorde i går

Søndag kveld planla vi nødvedlikehold for mandag 4. mai 2026, det tidligste vinduet vi kunne rulle ut en kjerneoppgradering på tvers av hele flåten.

Under vinduet:

• Hver vert ble oppgradert med de offisielle Debian-kjernepakkene som inneholdt "Copy Fail"-fiksen.
• Målet var enkelt: fjerne den sårbare kjernebanen helt, ikke bare lene oss på vår eksisterende navneromsisolasjon.

Vedlikeholdet er fullført. Alle Appbox-verter kjører nå en patchet kjerne.

Hva dette betyr for deg

• Du trengte ikke å gjøre noe. Appene dine fortsatte å kjøre, og eventuelle korte avbrudd under vedlikeholdsvinduet var den eneste effekten kundene kunne merke.
• Selv før gårsdagens patch betydde ommapping av brukernavnerom at denne feilen ikke kunne gjøre et normalt appkompromiss om til host root. Det er akkurat denne typen scenario denne isolasjonsmodellen finnes for.
• Fremover er retningslinjen vår uendret: brukernavnerom er på som standard, og de svært få unntakene går gjennom ekstra sikkerhetsgjennomgang.

Det større bildet

Dette er en av de CVE-ene der overskriften ("lokal rettighetseskalering, offentlig utnyttelse, alle moderne kjerner berørt") høres katastrofal ut, og for mange miljøer med delte leietakere var den virkelig det. Grunnen til at den ikke var katastrofal for oss, er den samme grunnen til at vi tok arkitektoniske valg for flere år siden som av og til koster oss litt kompatibilitet: vi kjører apper med prinsippet om minste privilegium bygget inn i containerlaget, ikke boltet på i etterkant.

Forsvar i dybden fungerer faktisk. Feil i kjernelaget? Navneromslaget fanget den. Feil i navneromslaget? Kapabilitetsdropp og seccomp fanger opp det meste. Vi later ikke som om ett enkelt lag er perfekt, vi sørger bare for at det alltid finnes et neste lag.

Hvis du har spørsmål om dette, eller om hvordan de spesifikke appene dine er konfigurert, ta gjerne kontakt.

Har du spørsmål? Kontakt oss på support@appbox.co eller åpne en sak på billing.appbox.co.