CVE-2026-31431 (Copy Fail) - আমরা কীভাবে এটি প্রশমিত করেছি

গত সপ্তাহে একটি গুরুতর Linux kernel local privilege escalation প্রকাশিত হয়েছে: CVE-2026-31431, যার ডাকনাম "Copy Fail"। এটি আধুনিক Linux distributions জুড়ে বিস্তৃত kernel version প্রভাবিত করে, এবং disclosure-এর অল্প সময়ের মধ্যেই একটি public exploit দেখা যায়।

কী ঘটেছে, Appbox-এর জন্য এর অর্থ কী, এবং আমরা এ বিষয়ে কী করেছি, তা পরিষ্কারভাবে জানাতে চাই। সংক্ষেপে: আমাদের containers যেভাবে তৈরি, তার কারণে user namespace remapping সহ চালানো apps patched kernels রোল আউট হওয়ার আগেই এটি host root-এ রূপ নেওয়া থেকে সুরক্ষিত ছিল। গতকাল (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 এমন files-এর page cache-এ সরাসরি arbitrary 4-byte chunks লিখতে পারে যেগুলো modify করার অনুমতি তার থাকার কথা নয় - /usr/bin/su-এর মতো SUID binaries সহ।

su-এর page cache copy একটি ছোট malicious ELF দিয়ে overwrite হয়ে গেলে, পরের invocation attacker-এর code UID 0 হিসেবে চালায়। Host-এর জন্য এখানেই খেলা শেষ।

গভীর technical details (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 আগে থেকেই প্রশমিত ছিল

Exploit-টি নির্ভর করে setuid(0) সত্যিই host root দিচ্ছে কি না তার ওপর। user namespaces enabled থাকা container-এ তা ঘটে না।

User namespaces container-এর UID space-কে host-এর একটি আলাদা (unprivileged) UID range-এ map করে। তাই container-এর ভিতরে exploit সফল হয়ে setuid(0) success return করলেও, ফলে তৈরি হওয়া "root" shell host-এ regular unprivileged host user হিসেবে mapped হয় - আসল 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 অবস্থায় শুরু হয়। 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-এর বিশেষ handling দরকার হলে app definitions এখনও স্পষ্টভাবে UsernsMode override করতে পারে:

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

সুতরাং সঠিকভাবে বললে: user namespace remapping platform default-এর অংশ, এবং per-app exceptions স্পষ্টভাবে নির্ধারিত। অল্প কিছু app আছে যেগুলোর আলাদা settings দরকার, কারণ তারা এমন functionality expose করে যার জন্য অতিরিক্ত capabilities দরকার হয়; সেই case-গুলো আলাদাভাবে handled হয়।

অন্যভাবে বললে: normal remapped setup-এ চলা apps-এর ক্ষেত্রে Copy Fail কোনো container compromise-কে host root-এ রূপ দিতে পারত না।

আমরা তবু কী ঠিক করতে চেয়েছিলাম

User namespaces host escape থামায়, কিন্তু container-এর ভিতরে bug-টি সরিয়ে দেয় না। একজন attacker app boundary-এর মধ্যে এখনও "container root"-এ escalate করতে পারত, যা contained হলেও ভালো operational hygiene নয়। Kernel নিজেই vulnerable ছিল, এবং আমরা সেটি সরাতে চেয়েছিলাম।

Bug সম্পর্কে জানার পরই আমরা সঙ্গে সঙ্গে আমাদের exposure assess করা শুরু করি। যদিও user namespace remapping আমাদের normal app setup-এ issue-টির host-escape দিকটি আগেই block করেছিল, তবুও underlying kernel bug যত দ্রুত সম্ভব দূর করতে চেয়েছি।

গতকাল আমরা কী করেছি

রবিবার রাতে আমরা Monday, May 4, 2026-এর জন্য emergency maintenance schedule করি, যা fleet-wide kernel upgrade রোল আউট করার earliest window ছিল।

Window চলাকালীন:

• প্রতিটি host official Debian kernel packages দিয়ে upgrade করা হয়েছে, যেখানে "Copy Fail" fix রয়েছে।
• লক্ষ্য ছিল সহজ: শুধু আমাদের existing namespace isolation-এর ওপর নির্ভর না করে vulnerable kernel path সম্পূর্ণ সরিয়ে দেওয়া।

Maintenance সম্পন্ন হয়েছে। প্রতিটি Appbox host এখন patched kernel চালাচ্ছে।

আপনার জন্য এর অর্থ কী

• আপনাকে কিছু করতে হয়নি। আপনার apps চলতে থেকেছে, এবং maintenance window-তে কোনো সংক্ষিপ্ত blip থাকলে সেটাই ছিল একমাত্র customer-visible effect।
• গতকালের patch-এর আগেও, user namespace remapping-এর অর্থ ছিল এই bug কোনো normal app compromise-কে host root-এ রূপ দিতে পারত না। এই isolation model ঠিক এমন scenario-এর জন্যই তৈরি।
• সামনে এগিয়ে আমাদের policy অপরিবর্তিত: user namespaces default-ভাবে on থাকবে, আর অতি অল্প exceptions অতিরিক্ত security review-এর মধ্য দিয়ে যাবে।

বড় ছবিটা

এটি এমন এক ধরনের CVE যেখানে headline ("local privilege escalation, public exploit, every modern kernel affected") খুব ভয়াবহ শোনায়, এবং অনেক shared-tenant environment-এর জন্য সত্যিই তা ছিল। আমাদের জন্য এটি ভয়াবহ না হওয়ার কারণ সেই একই কারণে, যার জন্য আমরা বহু বছর আগে এমন architectural decisions নিয়েছিলাম যা মাঝে মাঝে কিছু compatibility cost তৈরি করে: আমরা 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 নিখুঁত; আমরা শুধু নিশ্চিত করি সবসময় আরেকটি layer থাকে।

এ নিয়ে বা আপনার নির্দিষ্ট apps কীভাবে configured, সে বিষয়ে কোনো প্রশ্ন থাকলে যোগাযোগ করুন।

প্রশ্ন আছে? support@appbox.co-তে আমাদের সাথে যোগাযোগ করুন অথবা billing.appbox.co-তে ticket খুলুন।