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

Prošlog je tjedna objavljen ozbiljan lokalni propust za eskalaciju privilegija u Linux kernelu: CVE-2026-31431, nadimka "Copy Fail". Pogađa širok raspon verzija kernela u modernim Linux distribucijama, a javni exploit pojavio se ubrzo nakon objave.

Želim otvoreno objasniti što se dogodilo, što to znači za Appbox i što smo učinili. Kratka verzija: zahvaljujući načinu na koji su naši kontejneri izgrađeni, aplikacije pokrenute s user namespace remappingom već su bile zaštićene od pretvaranja ovog propusta u root pristup na hostu, čak i prije uvođenja zakrpanih kernela. Jučer (May 4, 2026) proveli smo i hitno održavanje kako bismo svaki server nadogradili na zakrpani kernel, pa je propust sada u potpunosti uklonjen iz naše flote.

Što je "Copy Fail"?

CVE-2026-31431 je propust u kernelovom AF_ALG kriptografskom API-ju. Vezivanjem na određenu šifru (authencesn(hmac(sha256),cbc(aes))) i zloupotrebom načina na koji kernel spaja stranice u privremeni međuspremnik, neprivilegirani lokalni korisnik može zapisivati proizvoljne 4-bajtne dijelove izravno u page cache datoteka za koje ne bi smio imati dozvolu izmjene - uključujući SUID binarne datoteke poput /usr/bin/su.

Nakon što se kopija su u page cacheu prepiše malicioznim malenim ELF-om, sljedeće pokretanje izvršava napadačev kod kao UID 0. Kraj igre za host.

Za detaljne tehničke pojedinosti (disasembliranje shellcodea, syscall tragove i sve ostalo), izvrstan je tekst Andree Verija: CVE-2026-31431: Copy Fail vs. rootless containers. Također je pokazao - uz eBPF i uid_map dokaze - upravo ono o čemu govorimo u nastavku: user namespaces neutraliziraju ovaj exploit.

Zašto su Appbox aplikacije već bile zaštićene

Exploit se oslanja na to da setuid(0) zaista dodijeli root na hostu. U kontejneru pokrenutom s omogućenim user namespaces, to se ne događa.

User namespaces mapiraju UID prostor kontejnera na drugi, neprivilegirani raspon UID-ova na hostu. Dakle, kada exploit uspije unutar kontejnera i setuid(0) vrati uspjeh, rezultirajući "root" shell mapiran je na običnog neprivilegiranog korisnika na hostu - ne na stvarnog root korisnika. Shellcode se izvrši, prompt se promijeni u #, ali na hostu:

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

I to je to. Nema pristupa datotekama hosta, nema /etc/shadow, nema root pristupa na hostu. Granica namespacea kontejnera sprječava da ovo postane bijeg do host-root pristupa.

Na razini platforme svaki Appbox dobiva vlastiti Docker daemon pokrenut s omogućenim user namespace remappingom. U pseudokodu to izgleda otprilike ovako:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

To mapiranje podupire namjenski subordinate UID/GID raspon na hostu:

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

Povrh toga, definicije aplikacija i dalje mogu izričito nadjačati UsernsMode kada aplikacija zahtijeva posebno rukovanje:

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

Dakle, precizan opis glasi: user namespace remapping dio je zadane konfiguracije platforme, a iznimke po aplikaciji su izričite. Postoji mali broj aplikacija kojima trebaju drukčije postavke jer izlažu funkcionalnost koja zahtijeva dodatne capabilities, i ti se slučajevi obrađuju zasebno.

Drugim riječima: za aplikacije koje rade s uobičajenom remapiranom konfiguracijom, Copy Fail nije mogao pretvoriti kompromitiranje kontejnera u root pristup na hostu.

Što smo ipak htjeli popraviti

User namespaces zaustavljaju bijeg na host, ali ne uklanjaju propust unutar kontejnera. Napadač bi i dalje mogao eskalirati do "roota u kontejneru" unutar granica aplikacije, što je, iako ograničeno, i dalje loša higijena. Sam kernel bio je ranjiv i htjeli smo to ukloniti.

Čim smo saznali za propust, odmah smo počeli procjenjivati izloženost. Iako je user namespace remapping već blokirao stranu problema koja se odnosi na bijeg na host za našu uobičajenu konfiguraciju aplikacija, i dalje smo željeli ukloniti temeljni kernel propust što je brže moguće.

Što smo učinili jučer

U Sunday night zakazali smo hitno održavanje za Monday, May 4, 2026, najraniji termin u kojem smo mogli provesti nadogradnju kernela na cijeloj floti.

Tijekom tog prozora:

• Svaki host nadograđen je službenim Debian kernel paketima koji sadrže ispravak za "Copy Fail".
• Cilj je bio jednostavan: potpuno ukloniti ranjivu kernel putanju, a ne oslanjati se samo na postojeću namespace izolaciju.

Održavanje je završeno. Svaki Appbox host sada koristi zakrpani kernel.

Što to znači za vas

• Niste morali učiniti ništa. Vaše su aplikacije nastavile raditi, a jedini vidljivi učinak za korisnike bili su mogući kratki prekidi tijekom prozora održavanja.
• Čak i prije jučerašnje zakrpe, user namespace remapping značio je da ovaj propust ne može pretvoriti kompromitiranje normalne aplikacije u root pristup na hostu. Upravo za takav scenarij postoji ovaj model izolacije.
• Naša se politika ne mijenja: user namespaces ostaju uključeni prema zadanim postavkama, a vrlo rijetke iznimke prolaze dodatnu sigurnosnu provjeru.

Šira slika

Ovo je jedan od onih CVE-ova kod kojih naslov ("lokalna eskalacija privilegija, javni exploit, pogođen svaki moderni kernel") zvuči katastrofalno, a za mnoga okruženja s više korisnika na istoj infrastrukturi to je doista i bilo tako. Razlog zbog kojeg za nas nije bilo katastrofalno isti je razlog zbog kojeg smo prije više godina donijeli arhitektonske odluke koje nas ponekad koštaju malo kompatibilnosti: aplikacije pokrećemo s načelom najmanjih privilegija ugrađenim u sloj kontejnera, a ne naknadno dodanim.

Obrana u dubinu zaista funkcionira. Propust na kernel sloju? Namespace sloj ga je uhvatio. Propust na namespace sloju? Capability drops i seccomp uhvate većinu toga. Ne pretvaramo se da je ijedan sloj savršen; samo se brinemo da uvijek postoji sljedeći.

Ako imate pitanja o ovome ili o tome kako su vaše konkretne aplikacije konfigurirane, javite nam se.

Imate pitanja? Kontaktirajte nas na support@appbox.co ili otvorite ticket na billing.appbox.co.