CVE-2026-31431 (Copy Fail) - Sådan afbød vi den

I sidste uge blev en alvorlig lokal privilegieeskalering i Linux-kernen offentliggjort: CVE-2026-31431, med tilnavnet "Copy Fail". Den påvirker en bred vifte af kernelversioner på tværs af moderne Linux-distributioner, og en offentlig exploit dukkede hurtigt op efter offentliggørelsen.

Jeg vil være helt åben om, hvad der skete, hvad det betyder for Appbox, og hvad vi har gjort ved det. Den korte version: takket være den måde vores containere er bygget på, var apps, der kører med user namespace remapping, allerede beskyttet mod, at dette kunne blive til host root, selv før patchede kerner blev udrullet. I går (May 4, 2026) udførte vi også akut vedligeholdelse for at opgradere hver server til en patched kernel, så fejlen nu er fuldstændigt fjernet fra vores flåde.

Hvad er "Copy Fail"?

CVE-2026-31431 er en fejl i kernens kryptografiske AF_ALG API. Ved at binde til en bestemt cipher (authencesn(hmac(sha256),cbc(aes))) og misbruge den måde, kernen splejser sider ind i en scratch buffer på, kan en uprivilegeret lokal bruger skrive vilkårlige 4-byte chunks direkte ind i page cache for filer, de ikke burde have tilladelse til at ændre - inklusive SUID-binære filer som /usr/bin/su.

Når page cache-kopien af su er blevet overskrevet med en lille ondsindet ELF, kører næste invocation angriberens kode som UID 0. Game over for hosten.

For de detaljerede tekniske detaljer (shellcode-disassembly, syscall traces, det hele) er Andrea Veris gennemgang fremragende: CVE-2026-31431: Copy Fail vs. rootless containers. Han gjorde også arbejdet med at demonstrere - med eBPF og uid_map-beviser - præcis det, vi taler om nu: at user namespaces neutraliserer denne exploit.

Hvorfor Appbox-apps allerede var afbødet

Exploitten er afhængig af, at setuid(0) faktisk giver host root. I en container, der kører med user namespaces aktiveret, er det ikke det, der sker.

User namespaces mapper containerens UID-rum til et andet (uprivilegeret) UID-område på hosten. Så når exploitten lykkes inde i containeren, og setuid(0) returnerer succes, bliver den resulterende "root"-shell mappet til en almindelig uprivilegeret host-bruger - ikke rigtig root. Shellcoden kører, prompten ændrer sig til #, men på hosten:

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

Det er det. Ingen adgang til host-filer, ingen /etc/shadow, ingen host root. Containerens namespace-grænse forhindrer dette i at blive til et host-root escape.

På platformsniveau får hver Appbox sin egen Docker daemon startet med user namespace remapping aktiveret. I pseudokode ser det mere sådan ud:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Den mapping understøttes af et dedikeret subordinate UID/GID-område på hosten:

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

Oven i det kan appdefinitioner stadig eksplicit tilsidesætte UsernsMode, når en app kræver særlig håndtering:

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

Så den præcise måde at beskrive det på er: user namespace remapping er en del af platformens standard, og undtagelser pr. app er eksplicitte. Der er et lille antal apps, der kræver andre indstillinger, fordi de eksponerer funktionalitet, som kræver yderligere capabilities, og de tilfælde håndteres separat.

Med andre ord: for apps, der kører med den normale remappede opsætning, kunne Copy Fail ikke gøre et containerkompromis til host root.

Hvad vi stadig ville rette

User namespaces stopper host escape, men de får ikke fejlen til at forsvinde inde i containeren. En angriber kunne stadig eskalere til "container root" inden for appens grænse, hvilket, selvom det er indkapslet, stadig er dårlig housekeeping. Selve kernen var sårbar, og vi ville have det fjernet.

Da vi fik kendskab til fejlen, begyndte vi straks at vurdere vores eksponering. Selvom user namespace remapping allerede blokerede host-escape-delen af problemet for vores normale appopsætning, ville vi stadig have den underliggende kernel-fejl fjernet så hurtigt som muligt.

Hvad vi gjorde i går

Søndag aften planlagde vi akut vedligeholdelse til Monday, May 4, 2026, det tidligste vindue hvor vi kunne udrulle en kernelopgradering på tværs af hele flåden.

I vinduet:

• Blev hver host opgraderet med de officielle Debian-kernelpakker, der indeholder rettelsen til "Copy Fail".
• Målet var enkelt: fjern den sårbare kernelsti helt, ikke kun at stole på vores eksisterende namespace-isolering.

Vedligeholdelsen er afsluttet. Hver Appbox-host kører nu en patched kernel.

Hvad det betyder for dig

• Du behøvede ikke at gøre noget. Dine apps fortsatte med at køre, og eventuelle korte udfald under vedligeholdelsesvinduet var den eneste kundesynlige effekt.
• Selv før gårsdagens patch betød user namespace remapping, at denne fejl ikke kunne gøre et normalt appkompromis til host root. Det er præcis den slags scenarie, denne isoleringsmodel er designet til.
• Fremover er vores politik uændret: user namespaces forbliver slået til som standard, og de meget få undtagelser gennemgår ekstra sikkerhedsgennemgang.

Det større billede

Dette er en af de CVE'er, hvor overskriften ("lokal privilegieeskalering, offentlig exploit, alle moderne kerner påvirket") lyder katastrofal, og for mange shared-tenant-miljøer var den det virkelig. Grunden til, at den ikke var katastrofal for os, er den samme grund til, at vi for år tilbage traf arkitektoniske beslutninger, som lejlighedsvis koster os lidt kompatibilitet: vi kører apps med princippet om mindst mulige privilegier indbygget i containerlaget, ikke boltet på bagefter.

Defence in depth virker faktisk. Fejl i kernellaget? Namespace-laget fangede den. Fejl i namespace-laget? Capability drops og seccomp fanger det meste. Vi foregiver ikke, at et enkelt lag er perfekt, vi sørger bare for, at der altid er et næste.

Hvis du har spørgsmål om dette eller om, hvordan dine specifikke apps er konfigureret, er du velkommen til at kontakte os.

Har du spørgsmål? Kontakt os på support@appbox.co eller opret en ticket på billing.appbox.co.