CVE-2026-31431 (Copy Fail) - Jak jsme ji zmírnili

Minulý týden byla zveřejněna závažná lokální eskalace oprávnění v Linux kernelu: CVE-2026-31431, přezdívaná "Copy Fail". Ovlivňuje širokou škálu verzí kernelu napříč moderními Linux distribucemi a krátce po zveřejnění se objevil veřejný exploit.

Chci otevřeně popsat, co se stalo, co to znamená pro Appbox a co jsme s tím udělali. Krátká verze: díky tomu, jak jsou naše kontejnery postavené, byly aplikace běžící s user namespace remappingem už před nasazením opravených kernelů chráněné proti tomu, aby se z této chyby stal host root. Včera (4. května 2026) jsme také provedli nouzovou údržbu a upgradovali každý server na opravený kernel, takže chyba je teď z naší flotily plně odstraněna.

Co je "Copy Fail"?

CVE-2026-31431 je chyba v kryptografickém API kernelu AF_ALG. Navázáním na konkrétní cipher (authencesn(hmac(sha256),cbc(aes))) a zneužitím způsobu, jakým kernel vkládá stránky do dočasného bufferu, může neprivilegovaný lokální uživatel zapisovat libovolné 4bajtové úseky přímo do page cache souborů, které by neměl mít oprávnění upravovat - včetně SUID binárek jako /usr/bin/su.

Jakmile je kopie su v page cache přepsaná malým škodlivým ELF souborem, další spuštění spustí útočníkův kód jako UID 0. Pro hostitele konec hry.

Pro drsné technické detaily (disassembly shellcodu, syscall traces a všechno kolem) je výborný writeup Andrey Veriho: CVE-2026-31431: Copy Fail vs. rootless containers. Udělal také práci, která pomocí eBPF a důkazů uid_map přesně ukazuje to, o čem budeme mluvit dál: že user namespaces tento exploit neutralizují.

Proč byly Appbox aplikace už chráněné

Exploit spoléhá na to, že setuid(0) skutečně udělí host root. V kontejneru se zapnutými user namespaces se to nestane.

User namespaces mapují UID prostor kontejneru na jiný (neprivilegovaný) rozsah UID na hostiteli. Když tedy exploit uvnitř kontejneru uspěje a setuid(0) vrátí úspěch, výsledný "root" shell je na hostiteli namapovaný na běžného neprivilegovaného uživatele - ne na skutečného roota. Shellcode běží, prompt se změní na #, ale na hostiteli:

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

To je celé. Žádný přístup k souborům hostitele, žádné /etc/shadow, žádný host root. Namespace hranice kontejneru zabrání tomu, aby se z toho stal únik na host roota.

Na úrovni platformy má každý Appbox vlastní Docker daemon spuštěný se zapnutým user namespace remappingem. V pseudokódu to vypadá zhruba takto:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Toto mapování je podložené dedikovaným subordinate UID/GID rozsahem na hostiteli:

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

Kromě toho mohou definice aplikací stále výslovně přepsat UsernsMode, když aplikace potřebuje zvláštní zacházení:

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

Přesný popis tedy je: user namespace remapping je součástí výchozího nastavení platformy a výjimky pro jednotlivé aplikace jsou výslovné. Existuje malý počet aplikací, které potřebují jiné nastavení, protože zpřístupňují funkce vyžadující další capabilities, a tyto případy řešíme samostatně.

Jinými slovy: u aplikací běžících v normálním remapovaném nastavení nemohl Copy Fail proměnit kompromitaci kontejneru v host root.

Co jsme přesto chtěli opravit

User namespaces zastaví únik na hostitele, ale neodstraní chybu uvnitř kontejneru. Útočník by se stále mohl v rámci hranic aplikace eskalovat na "container root", což je sice izolované, ale pořád špatný stav. Samotný kernel byl zranitelný a chtěli jsme to odstranit.

Jakmile jsme se o chybě dozvěděli, okamžitě jsme začali posuzovat naši expozici. I když user namespace remapping už u našeho běžného nastavení aplikací blokoval host-escape část problému, stále jsme chtěli podkladovou chybu kernelu odstranit co nejrychleji.

Co jsme udělali včera

V neděli večer jsme naplánovali nouzovou údržbu na pondělí 4. května 2026, nejbližší okno, ve kterém jsme mohli nasadit upgrade kernelu napříč celou flotilou.

Během okna:

• Každý hostitel byl upgradován pomocí oficiálních Debian kernel balíčků obsahujících opravu "Copy Fail".
• Cíl byl jednoduchý: odstranit zranitelnou cestu v kernelu úplně, ne se jen spoléhat na naši stávající namespace izolaci.

Údržba je dokončena. Každý Appbox hostitel teď běží na opraveném kernelu.

Co to pro vás znamená

• Nemuseli jste nic dělat. Vaše aplikace dál běžely a jediné zákaznicky viditelné dopady byly případné krátké výpadky během údržbového okna.
• Už před včerejší opravou user namespace remapping znamenal, že tato chyba nemohla proměnit kompromitaci běžné aplikace v host root. Přesně pro takový scénář tento model izolace existuje.
• Do budoucna se naše politika nemění: user namespaces zůstávají ve výchozím nastavení zapnuté a velmi málo výjimek prochází dodatečnou bezpečnostní kontrolou.

Širší pohled

Tohle je jedno z těch CVE, kde titulek ("lokální eskalace oprávnění, veřejný exploit, zasažený každý moderní kernel") zní katastroficky, a pro mnoho sdílených multi-tenant prostředí to katastrofické opravdu bylo. Důvod, proč to nebylo katastrofické pro nás, je stejný důvod, proč jsme před lety udělali architektonická rozhodnutí, která nás občas stojí trochu kompatibility: aplikace provozujeme s principem nejmenších oprávnění zabudovaným přímo v kontejnerové vrstvě, ne přilepeným dodatečně.

Defence in depth skutečně funguje. Chyba ve vrstvě kernelu? Zachytila ji namespace vrstva. Chyba v namespace vrstvě? Capability drops a seccomp zachytí většinu zbytku. Netváříme se, že je jakákoli jednotlivá vrstva dokonalá, jen zajišťujeme, aby vždy existovala další.

Pokud k tomu máte jakékoli otázky nebo se chcete zeptat, jak jsou nakonfigurované vaše konkrétní aplikace, ozvěte se nám.

Máte otázky? Kontaktujte nás na support@appbox.co nebo otevřete ticket na billing.appbox.co.