CVE-2026-31431 (Copy Fail) - ہم نے اس کا اثر کیسے کم کیا

پچھلے ہفتے Linux kernel میں ایک سنگین local privilege escalation disclosed ہوا: CVE-2026-31431، جسے "Copy Fail" کا nickname دیا گیا ہے۔ یہ modern Linux distributions میں kernel versions کی وسیع range کو متاثر کرتا ہے، اور disclosure کے فوراً بعد public exploit بھی سامنے آ گیا۔

میں واضح طور پر بتانا چاہتا ہوں کہ کیا ہوا، Appbox کے لیے اس کا کیا مطلب تھا، اور ہم نے اس کے بارے میں کیا کیا۔ مختصر جواب یہ ہے: ہمارے containers جس طرح بنائے گئے ہیں، user namespace remapping کے ساتھ چلنے والی apps patched kernels roll out ہونے سے پہلے ہی اس flaw کے ذریعے 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 files کے page cache میں arbitrary 4-byte chunks directly write کر سکتا ہے جنہیں modify کرنے کی permission نہیں ہونی چاہیے، including SUID binaries like /usr/bin/su۔

جب su کی page cache copy ایک چھوٹے malicious ELF سے overwrite ہو جاتی ہے، تو اگلی invocation attacker کا code UID 0 کے طور پر run کرتی ہے۔ host کے لیے یہ مکمل compromise ہے۔

Gritty technical details، shellcode disassembly، syscall traces، اور باقی سب کے لیے Andrea Veri کی writeup بہترین ہے: CVE-2026-31431: Copy Fail vs. rootless containers۔ انہوں نے eBPF اور uid_map proofs کے ساتھ وہی بات demonstrate کی جس پر ہم آگے بات کریں گے: user namespaces اس exploit کو neutralise کر دیتی ہیں۔

Appbox Apps پہلے ہی کیوں محفوظ تھیں

Exploit اس بات پر rely کرتا ہے کہ setuid(0) واقعی host root grant کرے۔ user namespaces enabled container میں ایسا نہیں ہوتا۔

User namespaces container کی UID space کو host پر ایک different، unprivileged UID range سے map کرتی ہیں۔ اس لیے جب exploit container کے اندر succeed ہوتا ہے اور setuid(0) success return کرتا ہے، resulting "root" shell host پر regular unprivileged host user سے mapped ہوتی ہے، real root نہیں۔ shellcode run ہوتا ہے، 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 اب بھی UsernsMode کو explicitly override کر سکتی ہیں جب کسی app کو special handling چاہیے:

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

اس لیے accurate description یہ ہے: user namespace remapping platform default کا حصہ ہے، اور per-app exceptions explicit ہیں۔ چند apps ایسی ہیں جنہیں different settings چاہیے کیونکہ وہ ایسی functionality expose کرتی ہیں جس کے لیے additional capabilities required ہیں، اور ان cases کو separately 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 کو already block کر رہی تھی، ہم underlying kernel bug کو جتنی جلدی possible ہو ختم کرنا چاہتے تھے۔

ہم نے کل کیا کیا

Sunday night کو ہم نے Monday, May 4, 2026 کے لیے emergency maintenance schedule کی، جو fleet-wide kernel upgrade roll out کرنے کی earliest window تھی۔

Window کے دوران:

• ہر host کو official Debian kernel packages استعمال کرتے ہوئے upgrade کیا گیا جن میں "Copy Fail" fix شامل تھا۔
• goal simple تھا: vulnerable kernel path کو entirely remove کرنا، صرف existing namespace isolation پر rely نہ کرنا۔

Maintenance complete ہے۔ ہر Appbox host اب patched kernel چلا رہا ہے۔

آپ کے لیے اس کا کیا مطلب ہے

• آپ کو کچھ کرنے کی ضرورت نہیں تھی۔ آپ کی apps running رہیں اور maintenance window کے دوران brief blips ہی customer-visible effect تھے۔
• کل کے patch سے پہلے بھی، user namespace remapping کا مطلب تھا کہ یہ bug normal app compromise کو host root میں نہیں بدل سکتا تھا۔ یہی وہ scenario ہے جس کے لیے یہ isolation model exist کرتا ہے۔
• آگے چل کر ہماری policy unchanged ہے: user namespaces default طور پر on رہیں گی، اور بہت few exceptions extra security review سے گزریں گی۔

بڑی تصویر

یہ ان CVEs میں سے ہے جہاں headline، یعنی local privilege escalation، public exploit، اور ہر modern kernel affected، catastrophic لگتی ہے، اور بہت سے shared-tenant environments کے لیے یہ واقعی catastrophic تھی۔ ہمارے لیے catastrophic نہ ہونے کی وجہ وہی ہے جس کی بنیاد پر ہم نے years ago architectural decisions کیے، اگرچہ کبھی کبھار compatibility کی قیمت چکانی پڑتی ہے: ہم apps کو principle of least privilege container layer میں baked in کے ساتھ run کرتے ہیں، after-the-fact bolt-on کے طور پر نہیں۔

Defence in depth واقعی کام کرتی ہے۔ kernel layer پر bug؟ namespace layer نے catch کیا۔ namespace layer پر bug؟ capability drops اور seccomp اس کا زیادہ تر حصہ catch کرتے ہیں۔ ہم pretend نہیں کرتے کہ کوئی single layer perfect ہے، ہم بس ensure کرتے ہیں کہ ہمیشہ next one موجود ہو۔

اگر اس بارے میں، یا آپ کی specific apps کیسے configured ہیں، کوئی questions ہوں تو please reach out کریں۔

سوالات ہیں؟ support@appbox.co پر contact کریں یا billing.appbox.co پر ticket open کریں۔