CVE-2026-31431 (Copy Fail) - हमने इसे कैसे mitigate किया

पिछले हफ्ते एक गंभीर Linux kernel local privilege escalation disclose हुआ: CVE-2026-31431, जिसे "Copy Fail" nickname दिया गया। यह modern Linux distributions में kernel versions की बड़ी range को affect करता है, और disclosure के तुरंत बाद public exploit भी सामने आ गया।

मैं साफ-साफ बताना चाहता हूं कि क्या हुआ, Appbox के लिए इसका क्या मतलब है, और हमने इसके बारे में क्या किया। Short version: हमारे containers जिस तरह built हैं, उसके कारण user namespace remapping के साथ चल रहे apps patched kernels rollout होने से पहले ही इसे host root बनने से रोक रहे थे। कल (May 4, 2026), हमने हर server को patched kernel पर upgrade करने के लिए emergency maintenance भी किया, इसलिए bug अब हमारे fleet से पूरी तरह हट चुका है।

"Copy Fail" क्या है?

CVE-2026-31431 kernel की AF_ALG cryptographic API में flaw है। किसी specific cipher (authencesn(hmac(sha256),cbc(aes))) से bind करके और kernel जिस तरह pages को scratch buffer में splice करता है उसका abuse करके, एक unprivileged local user arbitrary 4-byte chunks को उन files के page cache में सीधे लिख सकता है जिन्हें modify करने की permission उसके पास नहीं होनी चाहिए - जैसे /usr/bin/su जैसे SUID binaries।

जब su की page cache copy एक छोटे malicious ELF से overwrite हो जाती है, तो अगली invocation attacker का code UID 0 के रूप में चलाती है। Host के लिए game over।

Gritty technical details (shellcode disassembly, syscall traces, सब कुछ) के लिए Andrea Veri का writeup शानदार है: CVE-2026-31431: Copy Fail vs. rootless containers. उन्होंने eBPF और uid_map proofs के साथ exactly वही demonstrate किया है जिसके बारे में हम आगे बात करेंगे: user namespaces इस exploit को neutralise करते हैं।

Appbox Apps पहले से mitigated क्यों थे

यह exploit इस बात पर निर्भर करता है कि setuid(0) सच में host root दे। User namespaces enabled वाले container में ऐसा नहीं होता।

User namespaces container के UID space को host पर एक अलग (unprivileged) UID range से map करते हैं। इसलिए जब exploit container के अंदर succeed करता है और setuid(0) success return करता है, तो resulting "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 को अपना Docker daemon मिलता है जो user namespace remapping enabled के साथ start होता है। 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 तब भी explicitly UsernsMode override कर सकती हैं जब किसी app को special handling चाहिए:

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

इसलिए सही description यह है: user namespace remapping platform default का हिस्सा है, और per-app exceptions explicit हैं। कुछ ही apps को different settings चाहिए क्योंकि वे ऐसी functionality expose करते हैं जिसके लिए additional capabilities चाहिए, और उन cases को अलग से handle किया जाता है।

दूसरे शब्दों में: normal remapped setup के साथ चल रहे apps के लिए Copy Fail container compromise को host root में नहीं बदल सकता था।

हम फिर भी क्या fix करना चाहते थे

User namespaces host escape रोकते हैं, लेकिन वे container के अंदर bug को गायब नहीं करते। Attacker app boundary के अंदर "container root" तक escalate कर सकता था, जो contained होने के बावजूद अच्छी स्थिति नहीं है। Kernel खुद vulnerable था, और हम चाहते थे कि यह खत्म हो।

Bug के बारे में पता चलते ही हमने अपनी exposure assess करना शुरू कर दिया। भले ही user namespace remapping हमारे normal app setup के लिए issue के host-escape side को पहले से block कर रहा था, हम underlying kernel bug को जल्द से जल्द हटाना चाहते थे।

कल हमने क्या किया

Sunday night को हमने Monday, May 4, 2026 के लिए emergency maintenance schedule किया, जो fleet-wide kernel upgrade rollout करने की earliest window थी।

Window के दौरान:

• हर host को official Debian kernel packages से upgrade किया गया जिनमें "Copy Fail" fix शामिल था।
• Goal simple था: vulnerable kernel path को पूरी तरह remove करना, सिर्फ existing namespace isolation पर निर्भर नहीं रहना।

Maintenance complete है। हर Appbox host अब patched kernel चला रहा है।

इसका आपके लिए क्या मतलब है

• आपको कुछ करने की जरूरत नहीं थी। आपके apps चलते रहे और maintenance window के दौरान कोई brief blips ही customer-visible effect थे।
• कल के patch से पहले भी, user namespace remapping का मतलब था कि यह bug normal app compromise को host root में नहीं बदल सकता था। यह exactly वही scenario है जिसके लिए यह isolation model मौजूद है।
• आगे भी हमारी policy unchanged है: user namespaces default रूप से on रहेंगे, और बहुत कम exceptions extra security review से गुजरेंगे।

बड़ी तस्वीर

यह उन CVEs में से है जहां headline ("local privilege escalation, public exploit, every modern kernel affected") catastrophic लगती है, और बहुत से shared-tenant environments के लिए सच में वैसी थी। हमारे लिए यह catastrophic नहीं थी, इसका कारण वही है जिसके चलते हमने सालों पहले architectural decisions लिए थे जो कभी-कभी compatibility की थोड़ी कीमत लेते हैं: हम apps को container layer में built-in least privilege principle के साथ चलाते हैं, बाद में bolt-on security की तरह नहीं।

Defence in depth सच में काम करता है। Kernel layer में bug? Namespace layer ने पकड़ लिया। Namespace layer में bug? Capability drops और seccomp उसका बहुत हिस्सा पकड़ लेते हैं। हम यह pretend नहीं करते कि कोई single layer perfect है, हम बस यह सुनिश्चित करते हैं कि हमेशा अगली layer मौजूद हो।

अगर आपके पास इस बारे में, या आपके specific apps कैसे configured हैं, इसे लेकर कोई सवाल है, तो कृपया संपर्क करें।

Questions हैं? support@appbox.co पर contact करें या billing.appbox.co पर ticket खोलें।