CVE-2026-31431 (Copy Fail) - како смо га ублажили

Прошле недеље је објављена озбиљна локална ескалација привилегија у Linux kernel-у: CVE-2026-31431, надимка "Copy Fail". Погађа широк распон верзија kernel-а у модерним Linux дистрибуцијама, а јавни exploit се појавио убрзо након објаве.

Желим да будем отворен о томе шта се догодило, шта то значи за Appbox и шта смо урадили поводом тога. Кратка верзија: захваљујући начину на који су наши контејнери изграђени, апликације које раде са remapping-ом user namespace-а већ су биле заштићене од тога да се ово претвори у host root, чак и пре него што су исправљени kernel-и били уведени. Јуче (4. маја 2026) такође смо обавили хитно одржавање како бисмо сваки сервер надоградили на исправљени kernel, тако да је грешка сада у потпуности уклоњена из наше флоте.

Шта је "Copy Fail"?

CVE-2026-31431 је пропуст у AF_ALG криптографском API-ју kernel-а. Везивањем за одређени cipher (authencesn(hmac(sha256),cbc(aes))) и злоупотребом начина на који kernel спаја странице у привремени бафер, непривилеговани локални корисник може да уписује произвољне 4-бајтне делове директно у page cache датотека које не би смео да мења, укључујући SUID бинарне датотеке као што је /usr/bin/su.

Када се page cache копија su препише малим злонамерним ELF-ом, следеће покретање извршава нападачев код као UID 0. То је крај игре за host.

За грубе техничке детаље (дисасемблирање shellcode-а, syscall traces и све остало), одличан је текст Andrea Veri-ја: CVE-2026-31431: Copy Fail vs. rootless containers. Он је такође урадио посао демонстрирања, уз eBPF и uid_map доказе, тачно онога о чему ћемо говорити у наставку: да user namespaces неутралишу овај exploit.

Зашто су Appbox апликације већ биле ублажене

Exploit се ослања на то да setuid(0) заиста додели host root. У контејнеру који ради са омогућеним user namespaces, то се не дешава.

User namespaces мапирају UID простор контејнера на другачији (непривилеговани) UID опсег на host-у. Дакле, када exploit успе унутар контејнера и setuid(0) врати успех, добијена "root" shell сесија мапира се на обичног непривилегованог host корисника, а не на прави root. Shellcode се изврши, prompt се промени у #, али на host-у:

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

То је све. Нема приступа host датотекама, нема /etc/shadow, нема host root-а. Граница namespace-а контејнера спречава да ово постане host-root escape.

На нивоу платформе, сваки Appbox добија сопствени Docker daemon покренут са омогућеним remapping-ом user namespace-а. У псеудокоду, то више личи на ово:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

То мапирање је подржано наменским subordinate UID/GID опсегом на host-у:

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

Поврх тога, дефиниције апликација и даље могу изричито да преиначе UsernsMode када је апликацији потребно посебно руковање:

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

Зато је тачан начин да се то опише: remapping user namespace-а је део подразумеване поставке платформе, а изузеци по апликацији су изричити. Постоји мали број апликација којима су потребна другачија подешавања зато што излажу функционалност која захтева додатне capabilities, и ти случајеви се обрађују одвојено.

Другим речима: за апликације које раде са нормалном remapped поставком, Copy Fail није могао да претвори компромитовање контејнера у host root.

Шта смо ипак желели да поправимо

User namespaces спречавају host escape, али не уклањају грешку унутар контејнера. Нападач би и даље могао да ескалира на "container root" унутар границе апликације, што је, иако ограничено, и даље лоша хигијена. Сам kernel је био рањив и желели смо да то нестане.

Чим смо сазнали за грешку, одмах смо почели да процењујемо нашу изложеност. Иако је remapping user namespace-а већ блокирао host-escape страну проблема за нашу нормалну поставку апликација, и даље смо желели да основна kernel грешка буде уклоњена што је брже могуће.

Шта смо урадили јуче

У недељу увече заказали смо хитно одржавање за понедељак, 4. мај 2026, најранији термин у којем смо могли да спроведемо надоградњу kernel-а на целој флоти.

Током тог периода:

• Сваки host је надограђен званичним Debian kernel пакетима који садрже исправку за "Copy Fail".
• Циљ је био једноставан: у потпуности уклонити рањиву kernel путању, а не само ослонити се на нашу постојећу namespace изолацију.

Одржавање је завршено. Сваки Appbox host сада ради на исправљеном kernel-у.

Шта ово значи за вас

• Нисте морали ништа да урадите. Ваше апликације су наставиле да раде, а сви кратки прекиди током периода одржавања били су једини ефекат видљив корисницима.
• Чак и пре јучерашње исправке, remapping user namespace-а је значио да ова грешка не може да претвори компромитовање нормалне апликације у host root. То је управо она врста сценарија због које овај модел изолације постоји.
• Убудуће, наша политика остаје непромењена: user namespaces остају укључени подразумевано, а врло мали број изузетака пролази додатну безбедносну проверу.

Шира слика

Ово је један од оних CVE случајева у којима наслов ("локална ескалација привилегија, јавни exploit, сваки модерни kernel погођен") звучи катастрофално, а за многа окружења са више корисника заиста је и био. Разлог због којег није био катастрофалан за нас исти је разлог због којег смо пре више година донели архитектонске одлуке које нас повремено коштају мало компатибилности: покрећемо апликације са принципом најмањих привилегија уграђеним у слој контејнера, а не накнадно додатим.

Одбрана у дубину заиста функционише. Грешка у kernel слоју? Namespace слој ју је ухватио. Грешка у namespace слоју? Уклањање capabilities и seccomp хватају већину тога. Не претварамо се да је било који појединачни слој савршен, само се побринемо да увек постоји следећи.

Ако имате било каква питања о овоме или о томе како су ваше конкретне апликације конфигурисане, обратите нам се.

Имате питања? Контактирајте нас на support@appbox.co или отворите тикет на billing.appbox.co.