CVE-2026-31431 (Copy Fail) - మేము దాన్ని ఎలా Mitigate చేశాము

గత వారం తీవ్రమైన Linux kernel local privilege escalation disclose అయింది: CVE-2026-31431, దీనికి "Copy Fail" అనే nickname ఉంది. ఇది modern Linux distributions అంతటా విస్తృతమైన kernel versions ను ప్రభావితం చేస్తుంది, disclosure తర్వాత public exploit త్వరగా బయటపడింది.

ఏం జరిగింది, Appbox కు దాని అర్థం ఏమిటి, మేము దాని గురించి ఏమి చేశామో సూటిగా చెప్పాలనుకుంటున్నాను. సంక్షిప్తంగా: మా containers ఎలా నిర్మించబడ్డాయో దాని వల్ల, user namespace remapping తో నడిచే apps patched kernels roll out కాకముందే ఇది 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 గా నడుపుతుంది. host కోసం game over.

ముదురు technical details (shellcode disassembly, syscall traces, అన్నీ) కోసం Andrea Veri writeup అద్భుతంగా ఉంది: CVE-2026-31431: Copy Fail vs. rootless containers. user namespaces ఈ exploit ను neutralise చేస్తాయని మేము తర్వాత మాట్లాడబోయే విషయాన్ని eBPF మరియు uid_map proofs తో demonstrate చేసిన పని కూడా ఆయనే చేశారు.

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 regular unprivileged host user గా map అవుతుంది - నిజమైన 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 కు 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 కు special handling అవసరమైతే app definitions ఇంకా UsernsMode ను explicit గా override చేయగలవు:

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

కాబట్టి ఖచ్చితంగా చెప్పాలంటే: user namespace remapping platform default లో భాగం, మరియు per-app exceptions explicit. additional capabilities అవసరమయ్యే functionality expose చేసే కొన్ని apps కు వేర్వేరు settings అవసరం, ఆ cases విడిగా handle చేయబడతాయి.

మరోలా చెప్పాలంటే: normal remapped setup తో నడిచే apps కోసం, Copy Fail container compromise ను host root గా మార్చలేకపోయింది.

ఇంకా మేము సరిచేయాలనుకున్నది

User namespaces host escape ను ఆపుతాయి, కానీ container లోపల bug ను మాయంచేయవు. attacker app boundary లోపల "container root" కు escalate కావచ్చు; అది contained అయినప్పటికీ, still bad housekeeping. kernel తానే vulnerable గా ఉంది, దాన్ని తొలగించాలని మేము కోరుకున్నాము.

bug గురించి తెలుసుకున్న వెంటనే, మా exposure ను వెంటనే assess చేయడం ప్రారంభించాము. user namespace remapping మా normal app setup కోసం issue యొక్క host-escape భాగాన్ని ఇప్పటికే block చేసినప్పటికీ, underlying kernel bug ను సాధ్యమైనంత త్వరగా తొలగించాలనుకున్నాము.

నిన్న మేము చేసినది

Sunday night న, fleet-wide kernel upgrade roll out చేయగల earliest window అయిన Monday, May 4, 2026 కోసం emergency maintenance schedule చేశాము.

ఆ window సమయంలో:

• "Copy Fail" fix కలిగిన official Debian kernel packages ఉపయోగించి ప్రతి host upgrade చేయబడింది.
• లక్ష్యం సులభం: మా existing namespace isolation పై మాత్రమే ఆధారపడకుండా, vulnerable kernel path ను పూర్తిగా remove చేయడం.

Maintenance complete అయింది. ప్రతి Appbox host ఇప్పుడు patched kernel నడుపుతోంది.

మీకు దీని అర్థం

• మీరు ఏమీ చేయాల్సిన అవసరం లేదు. మీ apps నడుస్తూనే ఉన్నాయి; maintenance window సమయంలో వచ్చిన ఏ చిన్న blips అయినా customer-visible effect అంతే.
• నిన్నటి patch కంటే ముందే, user namespace remapping వల్ల ఈ bug normal app compromise ను host root గా మార్చలేకపోయింది. ఈ isolation model ఉన్నదే ఇలాంటి scenario కోసం.
• ముందుకు కూడా మా policy మారదు: user namespaces default గా on ఉంటాయి, మరియు చాలా కొద్దిమంది exceptions అదనపు security review ద్వారా వెళ్తాయి.

పెద్ద దృశ్యం

ఇది headline ("local privilege escalation, public exploit, every modern kernel affected") వినగానే catastrophic గా అనిపించే CVEs లో ఒకటి, మరియు చాలామంది shared-tenant environments కు అది నిజంగానే అలా ఉంది. మా కోసం అది catastrophic కాకపోవడానికి కారణం, కొన్నిసార్లు compatibility కొంచెం cost అయినా మేము సంవత్సరాల క్రితం తీసుకున్న architectural decisions అదే: apps ను container layer లోనే principle of least privilege తో నడుపుతాము, తర్వాత bolted on చేసినట్టుగా కాదు.

Defence in depth నిజంగా పనిచేస్తుంది. kernel layer లో bug? namespace layer దాన్ని పట్టుకుంది. namespace layer లో bug? capability drops మరియు seccomp వాటిలో చాలావరకు పట్టుకుంటాయి. ఏ ఒక్క layer perfect అని మేము నటించము; ఎప్పుడూ తదుపరి layer ఉండేలా చూసుకుంటాము.

దీని గురించి, లేదా మీ specific apps ఎలా configure అయ్యాయో గురించి మీకు ఏవైనా ప్రశ్నలుంటే, దయచేసి సంప్రదించండి.

ప్రశ్నలున్నాయా? support@appbox.co వద్ద మమ్మల్ని సంప్రదించండి లేదా billing.appbox.co వద్ద ticket తెరవండి.