CVE-2026-31431 (Copy Fail) - hoe wij dit hebben beperkt

Vorige week werd een ernstige lokale privilege-escalatie in de Linux-kernel bekendgemaakt: CVE-2026-31431, bijgenaamd "Copy Fail". Deze treft een breed scala aan kernelversies in moderne Linux-distributies, en kort na de bekendmaking verscheen er een openbare exploit.

Ik wil duidelijk zijn over wat er is gebeurd, wat dit betekent voor Appbox, en wat we eraan hebben gedaan. De korte versie: dankzij de manier waarop onze containers zijn gebouwd, waren apps die met user namespace remapping draaien al beschermd tegen escalatie naar host root, zelfs voordat gepatchte kernels werden uitgerold. Gisteren (May 4, 2026) hebben we ook noodonderhoud uitgevoerd om elke server te upgraden naar een gepatchte kernel, waardoor de bug nu volledig uit onze fleet is verdwenen.

Wat is "Copy Fail"?

CVE-2026-31431 is een fout in de cryptografische API AF_ALG van de kernel. Door te binden aan een specifieke cipher (authencesn(hmac(sha256),cbc(aes))) en misbruik te maken van de manier waarop de kernel pages naar een scratchbuffer splice't, kan een lokale gebruiker zonder privileges willekeurige chunks van 4 bytes direct in de page cache schrijven van bestanden waarvoor die gebruiker geen wijzigingsrechten zou mogen hebben - inclusief SUID-binaries zoals /usr/bin/su.

Zodra de page-cachekopie van su is overschreven met een kleine kwaadaardige ELF, voert de volgende aanroep de code van de aanvaller uit als UID 0. Einde verhaal voor de host.

Voor de technische details (shellcode-disassembly, syscall-traces, alles erop en eraan) is de write-up van Andrea Veri uitstekend: CVE-2026-31431: Copy Fail vs. rootless containers. Hij heeft ook aangetoond - met eBPF en uid_map-bewijzen - waar we het hierna over hebben: dat user namespaces deze exploit neutraliseren.

Waarom Appbox-apps al beschermd waren

De exploit vertrouwt erop dat setuid(0) daadwerkelijk host root geeft. In een container waarin user namespaces zijn ingeschakeld, gebeurt dat niet.

User namespaces mappen de UID-ruimte van de container naar een andere (niet-geprivilegieerde) UID-reeks op de host. Dus wanneer de exploit binnen de container slaagt en setuid(0) succesvol terugkeert, wordt de resulterende "root"-shell gemapt naar een gewone niet-geprivilegieerde hostgebruiker - niet naar echte root. De shellcode draait, de prompt verandert naar #, maar op de host:

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

Dat is alles. Geen toegang tot hostbestanden, geen /etc/shadow, geen host root. De namespacegrens van de container voorkomt dat dit een host-root escape wordt.

Op platformniveau krijgt elke Appbox zijn eigen Docker-daemon, gestart met ingeschakelde user namespace remapping. In pseudocode lijkt dat meer op dit:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Die mapping wordt ondersteund door een toegewezen subordinate UID/GID-reeks op de host:

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

Daarbovenop kunnen appdefinities UsernsMode nog steeds expliciet overschrijven wanneer een app speciale behandeling nodig heeft:

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

De juiste manier om het te beschrijven is dus: user namespace remapping is onderdeel van de standaardinstelling van het platform, en uitzonderingen per app zijn expliciet. Er is een klein aantal apps dat andere instellingen nodig heeft omdat ze functionaliteit bieden waarvoor extra capabilities nodig zijn, en die gevallen worden apart behandeld.

Met andere woorden: voor apps die met de normale remapped setup draaien, kon Copy Fail een containercompromis niet omzetten in host root.

Wat we nog wilden oplossen

User namespaces voorkomen de host escape, maar ze laten de bug binnen de container niet verdwijnen. Een aanvaller kon nog steeds escaleren naar "container root" binnen de appgrens. Dat is weliswaar ingeperkt, maar nog steeds geen goede situatie. De kernel zelf was kwetsbaar, en we wilden dat oplossen.

Zodra we over de bug hoorden, zijn we direct onze blootstelling gaan beoordelen. Hoewel user namespace remapping de host-escape-kant van het probleem voor onze normale appsetup al blokkeerde, wilden we de onderliggende kernelbug zo snel mogelijk weg hebben.

Wat we gisteren hebben gedaan

Op zondagavond hebben we noodonderhoud gepland voor Monday, May 4, 2026, het vroegste venster waarin we een fleet-wide kernelupgrade konden uitrollen.

Tijdens het venster:

• Elke host is geupgraded met de officiële Debian-kernelpakketten die de "Copy Fail"-fix bevatten.
• Het doel was eenvoudig: het kwetsbare kernelpad volledig verwijderen, niet alleen vertrouwen op onze bestaande namespace-isolatie.

Het onderhoud is voltooid. Elke Appbox-host draait nu een gepatchte kernel.

Wat dit voor jou betekent

• Je hoefde niets te doen. Je apps bleven draaien en eventuele korte haperingen tijdens het onderhoudsvenster waren het enige klantzichtbare effect.
• Zelfs voor de patch van gisteren betekende user namespace remapping dat deze bug een normaal appcompromis niet kon omzetten in host root. Dat is precies het soort scenario waarvoor dit isolatiemodel bestaat.
• In de toekomst blijft ons beleid ongewijzigd: user namespaces blijven standaard ingeschakeld, en de zeer weinige uitzonderingen gaan door extra security review.

Het grotere plaatje

Dit is een van die CVE's waarbij de kop ("lokale privilege-escalatie, openbare exploit, elke moderne kernel getroffen") catastrofaal klinkt, en voor veel shared-tenant omgevingen was dat het ook echt. De reden dat het voor ons niet catastrofaal was, is dezelfde reden waarom we jaren geleden architectuurkeuzes hebben gemaakt die ons soms wat compatibiliteit kosten: we draaien apps met het principle of least privilege ingebakken in de containerlaag, niet er achteraf bovenop geplakt.

Defense-in-depth werkt echt. Bug in de kernellaag? De namespacelaag ving hem op. Bug in de namespacelaag? Capability drops en seccomp vangen het meeste op. We doen niet alsof een enkele laag perfect is; we zorgen er gewoon voor dat er altijd een volgende is.

Als je vragen hebt hierover, of over hoe je specifieke apps zijn geconfigureerd, neem dan contact met ons op.

Vragen? Neem contact met ons op via support@appbox.co of open een ticket op billing.appbox.co.