CVE-2026-31431 (Copy Fail) - Näin lievensimme sen vaikutukset

Viime viikolla julkaistiin vakava Linux-ytimen paikallinen käyttöoikeuksien korotushaavoittuvuus: CVE-2026-31431, lempinimeltään "Copy Fail". Se vaikuttaa laajaan joukkoon ytimen versioita nykyaikaisissa Linux-jakeluissa, ja julkinen hyödyntämiskoodi ilmestyi nopeasti julkaisun jälkeen.

Haluan kertoa avoimesti, mitä tapahtui, mitä se tarkoittaa Appboxille ja mitä olemme tehneet asialle. Lyhyt versio: konttiemme toteutustavan ansiosta käyttäjänimiavaruuksien uudelleenkartoituksella ajettavat sovellukset olivat jo valmiiksi suojassa siltä, että tästä tulisi host root -tason murto, jo ennen kuin korjatut ytimet otettiin käyttöön. Eilen (4. toukokuuta 2026) teimme myös hätähuollon, jossa päivitimme jokaisen palvelimen korjattuun ytimeen, joten virhe on nyt kokonaan poistettu ympäristöstämme.

Mikä "Copy Fail" on?

CVE-2026-31431 on virhe ytimen AF_ALG-kryptografia-API:ssa. Sitoutumalla tiettyyn salaukseen (authencesn(hmac(sha256),cbc(aes))) ja väärinkäyttämällä tapaa, jolla ydin liittää sivuja väliaikaiseen puskuriin, oikeuksiltaan rajoitettu paikallinen käyttäjä voi kirjoittaa mielivaltaisia 4 tavun paloja suoraan sivuvälimuistiin tiedostoissa, joihin hänellä ei pitäisi olla muokkausoikeutta - mukaan lukien SUID-binäärit kuten /usr/bin/su.

Kun su-komennon sivuvälimuistissa oleva kopio on ylikirjoitettu pienellä haitallisella ELF-tiedostolla, seuraava suoritus ajaa hyökkääjän koodin UID 0 -käyttäjänä. Hostin kannalta peli on silloin menetetty.

Tarkkoja teknisiä yksityiskohtia varten (shellcode-purku, syscall-jäljitykset ja kaikki muu) Andrea Verin kirjoitus on erinomainen: CVE-2026-31431: Copy Fail vs. rootless containers. Hän myös osoitti eBPF:n ja uid_map-todisteiden avulla juuri sen, mistä puhumme seuraavaksi: käyttäjänimiavaruudet neutraloivat tämän hyökkäyksen.

Miksi Appbox-sovellukset oli jo suojattu

Hyökkäys perustuu siihen, että setuid(0) antaa oikeasti hostin root-oikeudet. Kontissa, jossa käyttäjänimiavaruudet ovat käytössä, näin ei tapahdu.

Käyttäjänimiavaruudet kartoittavat kontin UID-avaruuden eri (oikeuksiltaan rajoitettuun) UID-alueeseen hostilla. Kun hyökkäys siis onnistuu kontin sisällä ja setuid(0) palauttaa onnistumisen, syntyvä "root"-shell kartoittuu tavalliseksi oikeuksiltaan rajoitetuksi host-käyttäjäksi - ei oikeaksi rootiksi. Shellcode suoritetaan, kehote vaihtuu merkiksi #, mutta hostilla:

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

Siinä kaikki. Ei pääsyä hostin tiedostoihin, ei /etc/shadow-tiedostoa, ei hostin root-oikeuksia. Kontin nimiavaruusraja estää tämän muuttumisen host-root-paoksi.

Alustatasolla jokainen Appbox saa oman Docker-daemoninsa, joka käynnistetään käyttäjänimiavaruuksien uudelleenkartoitus käytössä. Pseudokoodina se näyttää suunnilleen tältä:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Tätä kartoitusta tukee hostilla erillinen alisteinen UID/GID-alue:

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

Lisäksi sovellusmääritykset voivat edelleen nimenomaisesti ohittaa UsernsMode-asetuksen, kun sovellus tarvitsee erityiskäsittelyä:

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

Tarkka tapa kuvata asia on siis tämä: käyttäjänimiavaruuksien uudelleenkartoitus on osa alustan oletusta, ja sovelluskohtaiset poikkeukset ovat nimenomaisia. Pieni määrä sovelluksia tarvitsee eri asetuksia, koska ne tarjoavat toimintoja, jotka edellyttävät lisäkyvykkyyksiä, ja nämä tapaukset käsitellään erikseen.

Toisin sanoen: normaalilla uudelleenkartoitetulla asetuksella ajettavissa sovelluksissa Copy Fail ei voinut muuttaa kontin murtamista hostin root-oikeuksiksi.

Mitä halusimme silti korjata

Käyttäjänimiavaruudet pysäyttävät host-paon, mutta ne eivät poista virhettä kontin sisältä. Hyökkääjä voisi silti korottaa oikeuksiaan "kontin rootiksi" sovelluksen rajojen sisällä, mikä on eristyksestä huolimatta huonoa ylläpitohygieniaa. Ydin itsessään oli haavoittuva, ja halusimme poistaa sen.

Kun saimme tietää virheestä, aloitimme välittömästi altistuksemme arvioinnin. Vaikka käyttäjänimiavaruuksien uudelleenkartoitus esti jo ongelman host-pakopuolen normaalissa sovellusasetuksessamme, halusimme silti saada taustalla olevan ydinvirheen poistettua mahdollisimman nopeasti.

Mitä teimme eilen

Sunnuntai-iltana ajoitimme hätähuollon ajalle maanantai 4. toukokuuta 2026, joka oli aikaisin mahdollinen ikkuna koko ympäristön kattavalle ytimen päivitykselle.

Huoltoikkunan aikana:

• Jokainen host päivitettiin virallisilla Debianin ydinpaketeilla, jotka sisältävät "Copy Fail" -korjauksen.
• Tavoite oli yksinkertainen: poistaa haavoittuva ytimen polku kokonaan, ei vain luottaa olemassa olevaan nimiavaruuseristykseemme.

Huolto on valmis. Jokaisella Appbox-hostilla on nyt käytössä korjattu ydin.

Mitä tämä tarkoittaa sinulle

• Sinun ei tarvinnut tehdä mitään. Sovelluksesi jatkoivat toimintaa, ja mahdolliset lyhyet häiriöt huoltoikkunan aikana olivat ainoa asiakkaalle näkyvä vaikutus.
• Jo ennen eilistä korjausta käyttäjänimiavaruuksien uudelleenkartoitus tarkoitti, ettei tämä virhe voinut muuttaa tavallisen sovelluksen murtamista hostin root-oikeuksiksi. Juuri tällaisia tilanteita varten tämä eristysmalli on olemassa.
• Jatkossa käytäntömme ei muutu: käyttäjänimiavaruudet pysyvät oletuksena käytössä, ja hyvin harvat poikkeukset käyvät läpi ylimääräisen turvallisuusarvioinnin.

Isompi kuva

Tämä on yksi niistä CVE:istä, joissa otsikko ("paikallinen käyttöoikeuksien korotus, julkinen exploit, jokainen moderni ydin vaikuttunut") kuulostaa katastrofaaliselta, ja monissa jaetuissa monivuokralaisympäristöissä se todella oli sitä. Syy siihen, miksi se ei ollut meille katastrofi, on sama syy, jonka vuoksi teimme jo vuosia sitten arkkitehtuuripäätöksiä, jotka toisinaan maksavat hieman yhteensopivuudessa: ajamme sovelluksia vähimpien oikeuksien periaate sisäänrakennettuna konttikerrokseen, emme jälkikäteen päälle liimattuna.

Puolustus syvyyssuunnassa toimii oikeasti. Virhe ydinkerroksessa? Nimiavaruuskerros otti sen kiinni. Virhe nimiavaruuskerroksessa? Kyvykkyyksien pudotus ja seccomp pysäyttävät suurimman osan. Emme väitä, että mikään yksittäinen kerros olisi täydellinen; varmistamme vain, että seuraava kerros on aina olemassa.

Jos sinulla on kysyttävää tästä tai siitä, miten omat sovelluksesi on määritetty, ota yhteyttä.

Onko kysyttävää? Ota yhteyttä osoitteessa support@appbox.co tai avaa tukipyyntö osoitteessa billing.appbox.co.