CVE-2026-31431 (Copy Fail) - Kako smo ga ublažili

Prejšnji teden je bila razkrita resna lokalna eskalacija privilegijev v jedru Linux: CVE-2026-31431, z vzdevkom "Copy Fail". Vpliva na širok nabor različic jedra v sodobnih distribucijah Linux, javno izkoriščanje pa se je pojavilo kmalu po razkritju.

Želim biti neposreden glede tega, kaj se je zgodilo, kaj to pomeni za Appbox in kaj smo glede tega naredili. Kratka različica: zaradi načina, kako so zgrajeni naši kontejnerji, so bile aplikacije, ki tečejo s preslikavo uporabniških imenskih prostorov, že zaščitene pred tem, da bi se napaka spremenila v root na gostitelju, še preden so bila uvedena popravljena jedra. Včeraj (May 4, 2026) smo izvedli tudi nujno vzdrževanje in vse strežnike nadgradili na popravljeno jedro, zato je napaka zdaj v celoti odstranjena iz naše flote.

Kaj je "Copy Fail"?

CVE-2026-31431 je napaka v kriptografskem API-ju jedra AF_ALG. Z vezavo na določen šifrirni algoritem (authencesn(hmac(sha256),cbc(aes))) in zlorabo načina, kako jedro spaja strani v začasni medpomnilnik, lahko neprivilegiran lokalni uporabnik poljubne 4-bajtne koščke zapiše neposredno v predpomnilnik strani datotek, za katere ne bi smel imeti dovoljenja za spreminjanje - vključno z binarnimi datotekami SUID, kot je /usr/bin/su.

Ko je kopija su v predpomnilniku strani prepisana z majhnim zlonamernim ELF-om, naslednji zagon izvede napadalčevo kodo kot UID 0. Za gostitelja je s tem igre konec.

Za natančne tehnične podrobnosti (razstavljanje shellcode, sledi sistemskih klicev in vse ostalo) je odličen zapis Andree Verija: CVE-2026-31431: Copy Fail vs. rootless containers. Opravil je tudi delo z dokazovanjem - z eBPF in dokazi uid_map - točno tistega, o čemer bomo govorili v nadaljevanju: da uporabniški imenski prostori nevtralizirajo to izkoriščanje.

Zakaj so bile aplikacije Appbox že zaščitene

Izkoriščanje se zanaša na to, da setuid(0) dejansko podeli root pravice na gostitelju. V kontejnerju, ki teče z omogočenimi uporabniškimi imenskimi prostori, se to ne zgodi.

Uporabniški imenski prostori preslikajo prostor UID kontejnerja v drug (neprivilegiran) razpon UID na gostitelju. Ko izkoriščanje uspe znotraj kontejnerja in setuid(0) vrne uspeh, je nastala lupina "root" preslikana na običajnega neprivilegiranega uporabnika gostitelja - ne na pravega root uporabnika. Shellcode se izvede, poziv se spremeni v #, vendar na gostitelju:

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

To je vse. Brez dostopa do datotek gostitelja, brez /etc/shadow, brez root pravic na gostitelju. Meja imenskega prostora kontejnerja prepreči, da bi to postalo pobeg do root pravic na gostitelju.

Na ravni platforme vsak Appbox dobi svoj Docker daemon, zagnan z omogočeno preslikavo uporabniških imenskih prostorov. V psevdokodi je to bolj podobno temu:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Ta preslikava je podprta z namenskim podrejenim razponom UID/GID na gostitelju:

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

Poleg tega lahko definicije aplikacij še vedno izrecno prepišejo UsernsMode, kadar aplikacija potrebuje posebno obravnavo:

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

Zato je natančen opis takšen: preslikava uporabniških imenskih prostorov je del privzete nastavitve platforme, izjeme za posamezne aplikacije pa so izrecne. Majhno število aplikacij potrebuje drugačne nastavitve, ker izpostavljajo funkcionalnost, ki zahteva dodatne zmožnosti, in ti primeri se obravnavajo ločeno.

Z drugimi besedami: pri aplikacijah, ki tečejo z običajno preslikano nastavitvijo, Copy Fail ni mogel spremeniti kompromitacije kontejnerja v root pravice na gostitelju.

Kaj smo vseeno želeli popraviti

Uporabniški imenski prostori ustavijo pobeg na gostitelja, vendar napake znotraj kontejnerja ne odpravijo. Napadalec bi še vedno lahko eskaliral v "root v kontejnerju" znotraj meje aplikacije, kar je sicer omejeno, vendar še vedno slaba higiena. Samo jedro je bilo ranljivo in želeli smo, da ta ranljivost izgine.

Ko smo izvedeli za napako, smo takoj začeli ocenjevati svojo izpostavljenost. Čeprav je preslikava uporabniških imenskih prostorov pri naši običajni nastavitvi aplikacij že blokirala del težave, povezan s pobegom na gostitelja, smo vseeno želeli čim hitreje odstraniti osnovno napako v jedru.

Kaj smo naredili včeraj

V nedeljo zvečer smo načrtovali nujno vzdrževanje za Monday, May 4, 2026, najzgodnejše okno, v katerem smo lahko uvedli nadgradnjo jedra po celotni floti.

Med oknom:

• Vsak gostitelj je bil nadgrajen z uradnimi paketi jedra Debian, ki vsebujejo popravek za "Copy Fail".
• Cilj je bil preprost: ranljivo pot v jedru v celoti odstraniti, ne pa se zanašati samo na našo obstoječo izolacijo z imenskimi prostori.

Vzdrževanje je končano. Vsak gostitelj Appbox zdaj uporablja popravljeno jedro.

Kaj to pomeni za vas

• Ni vam bilo treba narediti ničesar. Vaše aplikacije so še naprej delovale, edini vidni učinek za stranke pa so bili morebitni kratki izpadi med vzdrževalnim oknom.
• Še pred včerajšnjim popravkom je preslikava uporabniških imenskih prostorov pomenila, da ta napaka običajne kompromitacije aplikacije ni mogla spremeniti v root pravice na gostitelju. Prav za takšne scenarije obstaja ta model izolacije.
• V prihodnje se naša politika ne spreminja: uporabniški imenski prostori ostajajo privzeto vklopljeni, zelo redke izjeme pa gredo skozi dodaten varnostni pregled.

Širša slika

To je eden tistih CVE-jev, pri katerih se naslov ("lokalna eskalacija privilegijev, javno izkoriščanje, prizadeto vsako sodobno jedro") sliši katastrofalno, in za veliko okolij z več najemniki je res bil. Razlog, da za nas ni bil katastrofalen, je isti razlog, zaradi katerega smo pred leti sprejeli arhitekturne odločitve, ki nas občasno stanejo nekaj združljivosti: aplikacije poganjamo po načelu najmanjših privilegijev, vgrajenem v plast kontejnerjev, ne pa naknadno privijačenem nanjo.

Obramba v globino resnično deluje. Napaka v plasti jedra? Ujela jo je plast imenskih prostorov. Napaka v plasti imenskih prostorov? Odstranjene zmožnosti in seccomp ujamejo večino tega. Ne pretvarjamo se, da je katera koli posamezna plast popolna; poskrbimo le, da vedno obstaja naslednja.

Če imate kakršna koli vprašanja o tem ali o tem, kako so konfigurirane vaše specifične aplikacije, se obrnite na nas.

Imate vprašanja? Pišite nam na support@appbox.co ali odprite zahtevek na billing.appbox.co.