CVE-2026-31431 (Copy Fail) – Wie wir es mitigiert haben

Letzte Woche wurde eine schwerwiegende lokale Privilegieneskalation im Linux-Kernel veröffentlicht: CVE-2026-31431, mit dem Spitznamen "Copy Fail". Sie betrifft eine breite Auswahl an Kernel-Versionen in modernen Linux-Distributionen, und kurz nach der Offenlegung tauchte bereits ein öffentlicher Exploit auf.

Ich möchte offen darlegen, was passiert ist, was das für Appbox bedeutet und was wir dagegen getan haben. Die Kurzfassung: Durch die Art, wie unsere Container aufgebaut sind, waren Apps mit aktiviertem User-Namespace-Remapping bereits davor geschützt, dass daraus Host-Root werden konnte, noch bevor wir gepatchte Kernel ausgerollt haben. Gestern (4. Mai 2026) haben wir zusätzlich eine Notfall-Wartung durchgeführt und jeden Server auf einen gepatchten Kernel aktualisiert, sodass die Schwachstelle jetzt vollständig aus unserer Flotte verschwunden ist.

Was ist "Copy Fail"?

CVE-2026-31431 ist ein Fehler in der AF_ALG-Krypto-API des Kernels. Durch das Binden an einen bestimmten Cipher (authencesn(hmac(sha256),cbc(aes))) und das Ausnutzen der Art, wie der Kernel Seiten in einen Scratch-Buffer spliced, kann ein nicht privilegierter lokaler Nutzer beliebige 4-Byte-Blöcke direkt in den Page Cache von Dateien schreiben, die eigentlich gar nicht veränderbar sein sollten - einschliesslich SUID-Binaries wie /usr/bin/su.

Sobald die Page-Cache-Kopie von su mit einer kleinen bösartigen ELF überschrieben wurde, führt der nächste Aufruf den Code des Angreifers als UID 0 aus. Auf einem ungeschützten Host ist das das Spiel vorbei.

Für die technischen Details (Shellcode-Disassembly, Syscall-Traces und alles drum herum) ist Andrea Veris Write-up hervorragend: CVE-2026-31431: Copy Fail vs. rootless containers. Er hat dort auch genau demonstriert - mit eBPF und uid_map-Nachweisen - worauf wir jetzt hinauswollen: dass User Namespaces diesen Exploit neutralisieren.

Warum Appbox-Apps bereits mitigiert waren

Der Exploit setzt darauf, dass setuid(0) tatsächlich Host-Root ergibt. In einem Container mit aktivierten User Namespaces passiert genau das nicht.

User Namespaces mappen den UID-Bereich des Containers auf einen anderen (nicht privilegierten) UID-Bereich auf dem Host. Wenn der Exploit also im Container erfolgreich ist und setuid(0) Erfolg meldet, wird die resultierende "Root"-Shell auf einen normalen, nicht privilegierten Host-User gemappt - nicht auf echten Root. Der Shellcode läuft, der Prompt wechselt zu #, aber auf dem Host:

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

Das war es. Kein Zugriff auf Host-Dateien, kein /etc/shadow, kein Host-Root. Die Namespace-Grenze des Containers verhindert, dass daraus ein Host-Root-Escape wird.

Auf Plattform-Ebene bekommt jede Appbox ihren eigenen Docker-Daemon, der mit aktiviertem User-Namespace-Remapping startet. Als Pseudocode sieht das eher so aus:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Dieses Mapping wird durch einen dedizierten Subordinate-UID/GID-Bereich auf dem Host abgesichert:

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

Zusätzlich können App-Definitionen UsernsMode weiterhin explizit überschreiben, wenn eine App spezielles Handling braucht:

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

Die präzise Aussage ist also: User-Namespace-Remapping ist Teil unseres Plattform-Standards, und Ausnahmen pro App sind explizit definiert. Es gibt eine kleine Zahl von Apps, die andere Einstellungen brauchen, weil sie Funktionen bereitstellen, die zusätzliche Capabilities erfordern. Diese Fälle behandeln wir separat.

Mit anderen Worten: Für Apps, die mit dem normalen remappten Setup laufen, konnte Copy Fail aus einer Container-Kompromittierung kein Host-Root machen.

Was wir trotzdem beheben wollten

User Namespaces verhindern den Host-Escape, aber sie lassen den Bug im Container nicht verschwinden. Ein Angreifer könnte sich innerhalb der App-Grenze immer noch zu "Container-Root" hocheskalieren. Das bleibt zwar isoliert, ist aber trotzdem keine saubere Situation. Der Kernel selbst war verwundbar, und wir wollten das vollständig beseitigen.

Sobald wir von der Schwachstelle erfahren haben, haben wir sofort unsere Exposition bewertet. Auch wenn User-Namespace-Remapping die Host-Escape-Seite des Problems für unser normales App-Setup bereits blockiert hat, wollten wir den zugrunde liegenden Kernel-Bug so schnell wie möglich vollständig loswerden.

Was wir gestern getan haben

Am Sonntagabend haben wir eine Notfall-Wartung für Montag, den 4. Mai 2026, angesetzt - das frühestmögliche Fenster, in dem wir ein flächendeckendes Kernel-Upgrade ausrollen konnten.

Während des Wartungsfensters:

• wurde jeder Host mit den offiziellen Debian-Kernel-Paketen aktualisiert, die den "Copy Fail"-Fix enthalten.
• war das Ziel einfach: den verwundbaren Kernel-Pfad komplett zu entfernen, statt uns nur auf unsere bestehende Namespace-Isolation zu verlassen.

Die Wartung ist abgeschlossen. Jeder Appbox-Host läuft jetzt mit einem gepatchten Kernel.

Was das für euch bedeutet

• Ihr musstet nichts tun. Eure Apps liefen weiter, und eventuelle kurze Unterbrechungen während des Wartungsfensters waren der einzige sichtbare Effekt.
• Schon vor dem Patch von gestern bedeutete User-Namespace-Remapping, dass dieser Bug aus einer normalen App-Kompromittierung kein Host-Root machen konnte. Genau für solche Szenarien gibt es dieses Isolationsmodell.
• Unsere Richtlinie bleibt unverändert: User Namespaces bleiben standardmässig aktiviert, und die sehr wenigen Ausnahmen gehen durch zusätzliche Sicherheitsprüfung.

Das grössere Bild

Das ist eine dieser CVEs, bei denen die Schlagzeile ("lokale Privilegieneskalation, öffentlicher Exploit, praktisch jeder moderne Kernel betroffen") katastrophal klingt - und für viele Multi-Tenant-Umgebungen war sie das auch. Dass sie für uns nicht katastrophal war, liegt am selben Grund, warum wir schon vor Jahren Architekturentscheidungen getroffen haben, die uns gelegentlich etwas Kompatibilität kosten: Wir bauen das Prinzip der geringstmöglichen Rechte direkt in die Container-Schicht ein, statt Sicherheit erst im Nachhinein draufzusetzen.

Defence in depth funktioniert wirklich. Bug auf Kernel-Ebene? Die Namespace-Schicht fängt ihn ab. Bug auf Namespace-Ebene? Capability-Drops und seccomp fangen einen Grossteil davon ab. Wir tun nicht so, als wäre irgendeine einzelne Schicht perfekt - wir sorgen einfach dafür, dass es immer noch eine nächste gibt.

Wenn ihr dazu Fragen habt oder wissen möchtet, wie eure konkreten Apps konfiguriert sind, meldet euch gern.

Fragen? Schreibt uns an support@appbox.co oder eröffnet ein Ticket unter billing.appbox.co.