CVE-2026-31431 (Copy Fail) - आम्ही ते कसे mitigated केले

गेल्या आठवड्यात गंभीर Linux kernel local privilege escalation disclosed झाला: CVE-2026-31431, ज्याला "Copy Fail" असे nickname आहे. तो आधुनिक Linux distributions मधील अनेक kernel versions वर परिणाम करतो, आणि disclosure नंतर लवकरच public exploit दिसला.

काय घडले, Appbox साठी त्याचा अर्थ काय, आणि आम्ही काय केले याबद्दल मला स्पष्ट बोलायचे आहे. थोडक्यात: आमचे containers ज्या पद्धतीने build केलेले आहेत त्यामुळे, patched kernels rollout होण्यापूर्वीही user namespace remapping सह चालणारे apps हे host root मध्ये बदलण्यापासून आधीच protected होते. काल (May 4, 2026) आम्ही प्रत्येक server patched kernel वर upgrade करण्यासाठी emergency maintenance देखील केले, त्यामुळे bug आता आमच्या fleet मधून पूर्णपणे गेला आहे.

"Copy Fail" म्हणजे काय?

CVE-2026-31431 हा kernel च्या AF_ALG cryptographic API मधील flaw आहे. विशिष्ट cipher (authencesn(hmac(sha256),cbc(aes))) ला bind करून आणि kernel pages scratch buffer मध्ये splice करण्याची पद्धत abuse करून, unprivileged local user स्वतःला modify करण्याची permission नसलेल्या files च्या page cache मध्ये arbitrary 4-byte chunks थेट लिहू शकतो - /usr/bin/su सारख्या SUID binaries सह.

su ची page cache copy छोट्या malicious ELF ने overwrite झाल्यावर, पुढील invocation attacker चा code UID 0 म्हणून run करते. Host साठी game over.

खऱ्या technical तपशीलांसाठी (shellcode disassembly, syscall traces, सगळे), Andrea Veri यांचे writeup उत्कृष्ट आहे: CVE-2026-31431: Copy Fail vs. rootless containers. त्यांनी eBPF आणि uid_map proofs सह दाखवण्याचे कामही केले आहे की आपण पुढे जे बोलणार आहोत ते अचूक आहे: user namespaces हा exploit neutralise करतात.

Appbox Apps आधीच mitigated का होते

Exploit setuid(0) खरोखर host root grant करतो यावर अवलंबून आहे. user namespaces enabled असलेल्या container मध्ये तसे होत नाही.

User namespaces container चा UID space host वरील वेगळ्या (unprivileged) UID range वर map करतात. त्यामुळे container च्या आत exploit succeed झाला आणि setuid(0) success return झाले तरी, मिळालेला "root" shell host वर regular unprivileged host user म्हणून map होतो - real root नाही. Shellcode चालते, prompt # होतो, पण host वर:

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

इतकेच. Host file access नाही, /etc/shadow नाही, host root नाही. Container ची namespace boundary हे host-root escape होण्यापासून थांबवते.

Platform level वर, प्रत्येक Appbox ला user namespace remapping enabled असलेला स्वतःचा Docker daemon मिळतो. Pseudocode मध्ये ते साधारण असे दिसते:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

तो mapping host वरील dedicated subordinate UID/GID range ने backed असतो:

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

त्यावरही, app definitions एखाद्या app ला special handling लागल्यास UsernsMode explicitly override करू शकतात:

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

म्हणून अचूक वर्णन असे आहे: user namespace remapping हा platform default चा भाग आहे, आणि per-app exceptions explicit आहेत. काही थोडी apps अतिरिक्त capabilities लागणारी functionality expose करतात म्हणून त्यांना वेगळ्या settings लागतात, आणि ती cases वेगळी हाताळली जातात.

दुसऱ्या शब्दांत: normal remapped setup सह चालणाऱ्या apps साठी, Copy Fail container compromise ला host root मध्ये बदलू शकत नव्हता.

आम्हाला तरीही काय fix करायचे होते

User namespaces host escape थांबवतात, पण container च्या आत bug नाहीसा करत नाहीत. Attacker app boundary च्या आत "container root" पर्यंत escalate करू शकतो, जे contained असले तरी चांगले hygiene नाही. Kernel स्वतः vulnerable होते, आणि आम्हाला ते दूर करायचे होते.

Bug बद्दल कळताच, आम्ही exposure assess करायला लगेच सुरुवात केली. User namespace remapping आमच्या normal app setup मध्ये issue चा host-escape भाग आधीच block करत होते, तरी underlying kernel bug शक्य तितक्या लवकर हटवायचा होता.

काल आम्ही काय केले

Sunday night आम्ही Monday, May 4, 2026 साठी emergency maintenance schedule केले, fleet-wide kernel upgrade rollout करण्यासाठी मिळालेली सर्वात लवकर window.

त्या window दरम्यान:

• "Copy Fail" fix असलेली official Debian kernel packages वापरून प्रत्येक host upgrade केला.
• Goal साधे होते: फक्त existing namespace isolation वर अवलंबून न राहता vulnerable kernel path पूर्णपणे काढून टाकणे.

Maintenance पूर्ण झाले आहे. प्रत्येक Appbox host आता patched kernel चालवत आहे.

याचा तुमच्यासाठी अर्थ

• तुम्हाला काहीही करण्याची गरज नव्हती. तुमचे apps चालूच राहिले आणि maintenance window दरम्यान झालेले थोडे brief blips हाच customer-visible effect होता.
• कालच्या patch आधीही, user namespace remapping मुळे हा bug normal app compromise ला host root मध्ये बदलू शकत नव्हता. हे isolation model अशाच scenario साठी आहे.
• पुढेही आमची policy बदलत नाही: user namespaces default म्हणून चालूच राहतील, आणि अगदी थोड्या exceptions अतिरिक्त security review मधून जातील.

मोठे चित्र

ही अशी CVE आहे जिथे headline ("local privilege escalation, public exploit, every modern kernel affected") catastrophic वाटते, आणि अनेक shared-tenant environments साठी ती खरोखर होती. आमच्यासाठी ती catastrophic नव्हती याचे कारण तेच आहे ज्यासाठी आम्ही वर्षांपूर्वी काही compatibility cost स्वीकारून architectural decisions घेतले: आम्ही apps least privilege च्या principle सह container layer मध्ये built-in चालवतो, नंतर bolt-on करत नाही.

Defence in depth खरोखर काम करते. Kernel layer वर bug? Namespace layer ने पकडला. Namespace layer वर bug? Capability drops आणि seccomp त्यातील बरेच पकडतात. आम्ही कोणताही एक layer perfect आहे असे गृहीत धरत नाही, फक्त नेहमी पुढचा layer आहे याची खात्री करतो.

याबद्दल किंवा तुमचे specific apps कसे configured आहेत याबद्दल प्रश्न असल्यास कृपया संपर्क करा.

प्रश्न आहेत? support@appbox.co वर संपर्क करा किंवा billing.appbox.co वर ticket उघडा.