CVE-2026-31431 (Copy Fail) - Hogyan mérsékeltük

A múlt héten nyilvánosságra hoztak egy súlyos helyi jogosultságkiterjesztési hibát a Linux kernelben: CVE-2026-31431, becenevén "Copy Fail". A modern Linux-disztribúciók kernelverzióinak széles körét érinti, és nem sokkal a közzététel után nyilvános exploit is megjelent hozzá.

Szeretnék őszintén beszámolni arról, mi történt, mit jelent ez az Appbox számára, és mit tettünk ellene. Röviden: a konténereink felépítésének köszönhetően a user namespace remappinggel futó appok már a javított kernelek bevezetése előtt is védettek voltak az ellen, hogy ebből host root legyen. Tegnap (2026. május 4-én) sürgősségi karbantartást is végeztünk, amely során minden szervert javított kernelre frissítettünk, így a hiba mára teljesen eltűnt a flottánkból.

Mi az a "Copy Fail"?

A CVE-2026-31431 a kernel AF_ALG kriptográfiai API-jának hibája. Egy meghatározott cipherhez (authencesn(hmac(sha256),cbc(aes))) való kötődéssel, valamint annak a módnak a kihasználásával, ahogyan a kernel oldalakat illeszt be egy scratch bufferbe, egy jogosulatlan helyi felhasználó tetszőleges 4 bájtos darabokat írhat közvetlenül a page cache-be olyan fájloknál, amelyek módosítására nem lenne jogosultsága - beleértve az olyan SUID binárisokat is, mint a /usr/bin/su.

Miután a su page cache-ben lévő példányát felülírták egy apró rosszindulatú ELF-fel, a következő futtatáskor a támadó kódja UID 0-ként indul el. A host szempontjából ezzel vége a játéknak.

A nyers technikai részletekhez (shellcode visszafejtés, syscall trace-ek, minden apróság) Andrea Veri írása kiváló: CVE-2026-31431: Copy Fail vs. rootless containers. Ő azt is bemutatta - eBPF-fel és uid_map bizonyítékokkal -, amiről most beszélni fogunk: hogy a user namespace-ek semlegesítik ezt az exploitot.

Miért voltak már mérsékelve az Appbox appok

Az exploit arra épít, hogy a setuid(0) valóban host root jogosultságot ad. Egy user namespaces módban futó konténerben azonban nem ez történik.

A user namespace-ek a konténer UID-terét a hoston egy másik, jogosulatlan UID-tartományra képezik le. Így amikor az exploit sikeres a konténeren belül, és a setuid(0) sikerrel tér vissza, az így létrejövő "root" shell a hoston egy normál, jogosulatlan host felhasználónak felel meg - nem valódi rootnak. A shellcode lefut, a prompt #-re változik, de a hoston:

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

Ennyi. Nincs hozzáférés host fájlokhoz, nincs /etc/shadow, nincs host root. A konténer namespace-határa megakadályozza, hogy ez host-root kitöréssé váljon.

Platformszinten minden Appbox saját Docker daemont kap, amely user namespace remappinggel indul. Pszeudokódban ez valahogy így néz ki:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Ezt a leképezést a hoston egy dedikált subordinate UID/GID-tartomány támasztja alá:

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

Ezen felül az appdefiníciók továbbra is kifejezetten felülírhatják a UsernsMode értéket, ha egy app különleges kezelést igényel:

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

Ezért a pontos megfogalmazás: a user namespace remapping része a platform alapértelmezésének, az apponkénti kivételek pedig kifejezettek. Van néhány app, amelynek eltérő beállításokra van szüksége, mert olyan funkciókat tesz elérhetővé, amelyek további capability-ket igényelnek; ezeket az eseteket külön kezeljük.

Más szóval: a normál remappelt beállítással futó appoknál a Copy Fail nem tudott konténerkompromittálásból host root jogosultságot létrehozni.

Amit ettől még javítani akartunk

A user namespace-ek megállítják a hostból való kitörést, de magát a hibát nem tüntetik el a konténeren belül. Egy támadó továbbra is "container root" szintre emelhetné a jogosultságát az app határain belül, ami bár korlátozott, mégsem jó állapot. Maga a kernel sérülékeny volt, és ezt meg akartuk szüntetni.

Amint tudomást szereztünk a hibáról, azonnal elkezdtük felmérni a kitettségünket. Bár a user namespace remapping már eleve blokkolta a probléma host-escape oldalát a normál appbeállításainknál, az alapul szolgáló kernelhibát a lehető leggyorsabban el akartuk távolítani.

Mit tettünk tegnap

Vasárnap este sürgősségi karbantartást ütemeztünk 2026. május 4-re, hétfőre, ez volt a legkorábbi időablak, amikor flottaszintű kernelfrissítést tudtunk bevezetni.

Az időablak alatt:

• Minden hostot frissítettünk a hivatalos Debian kernelcsomagokkal, amelyek tartalmazzák a "Copy Fail" javítását.
• A cél egyszerű volt: teljesen eltávolítani a sérülékeny kernelútvonalat, nem csupán a meglévő namespace izolációnkra támaszkodni.

A karbantartás befejeződött. Minden Appbox host most már javított kernelt futtat.

Mit jelent ez számodra

• Nem kellett semmit tenned. Az appjaid tovább futottak, és a karbantartási időablak alatti rövid akadozások voltak az egyetlen ügyfelek számára látható hatások.
• Már a tegnapi javítás előtt is igaz volt, hogy a user namespace remapping miatt ez a hiba nem tudott egy normál appkompromittálásból host root jogosultságot létrehozni. Pontosan az ilyen forgatókönyvek miatt létezik ez az izolációs modell.
• A jövőben az irányelvünk változatlan: a user namespace-ek alapértelmezetten bekapcsolva maradnak, a nagyon kevés kivétel pedig extra biztonsági felülvizsgálaton megy keresztül.

A nagyobb kép

Ez azok közé a CVE-k közé tartozik, ahol a főcím ("helyi jogosultságkiterjesztés, nyilvános exploit, minden modern kernel érintett") katasztrofálisan hangzik, és sok megosztott bérlős környezetben valóban az is volt. Nálunk azért nem volt katasztrofális, mert évekkel ezelőtt olyan architekturális döntéseket hoztunk, amelyek néha egy kis kompatibilitásba kerülnek: az appokat a legkisebb jogosultság elvével futtatjuk már a konténerrétegben, nem utólag ragasztjuk rá ezt a védelmet.

A mélységi védelem tényleg működik. Hiba a kernelrétegben? A namespace-réteg megfogta. Hiba a namespace-rétegben? A capability-k eldobása és a seccomp a legtöbb esetet megfogja. Nem állítjuk, hogy bármelyik réteg tökéletes, csak gondoskodunk róla, hogy mindig legyen egy következő.

Ha kérdésed van ezzel kapcsolatban, vagy arról, hogyan vannak konfigurálva a konkrét appjaid, kérjük, keress minket.

Kérdésed van? Írj nekünk a support@appbox.co címen, vagy nyiss jegyet itt: billing.appbox.co.