Copy Fail – CVE-2026-31431

 (copy.fail)
2 पॉइंट द्वारा GN⁺ 1 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • बिना विशेषाधिकार वाला लोकल यूज़र authencesn, AF_ALG, splice() को जोड़कर पढ़ी जा सकने वाली फ़ाइलों के page cache में 4-byte write कर सकता है, और इसके ज़रिए root privileges तक बढ़ सकता है
  • kernel-specific offset या race condition के बिना सिर्फ 732-byte Python script से कई Linux distributions पर यह ज्यों का त्यों काम करता है, और उसी exploit से root shell हासिल की जा सकती है
  • patch आने से पहले तक अधिकांश प्रमुख Linux distributions प्रभावित हैं, और default configuration में सक्रिय AF_ALG के कारण 2017 से patch होने तक व्यापक रूप से exposed रहे हैं
  • multi-tenant host, Kubernetes / container cluster, CI runner, और user-code execution वाले Cloud SaaS में एक सामान्य account या एक pod भी host root तक पहुँच सकता है, इसलिए प्राथमिकता के साथ patch ज़रूरी है
  • mitigation के लिए mainline commit a664bf3d603d वाला kernel patch सबसे पहले ज़रूरी है; patch से पहले algif_aead को disable करना और untrusted workloads के लिए AF_ALG block करना महत्वपूर्ण है

भेद्यता का अवलोकन

  • एक ही सीधी लॉजिक त्रुटि को authencesn, AF_ALG, splice() से जोड़कर page cache में 4-byte write तक पहुँचने वाला local privilege escalation संभव है
  • kernel-specific offset या race window के बिना सिर्फ 732-byte Python script से 2017 के बाद जारी Linux distributions में एक जैसा काम करता है
  • वही exploit binary बिना किसी बदलाव के कई distributions पर root shell हासिल कर लेता है
  • सिर्फ बिना विशेषाधिकार वाला लोकल account होना काफ़ी है; network access, kernel debugging feature, या पहले से मौजूद किसी दूसरे primitive की ज़रूरत नहीं है

प्रभाव का दायरा

  • patch से पहले वाले kernel इस्तेमाल करने वाली अधिकांश प्रमुख Linux distributions इसकी चपेट में हैं
  • default configuration में kernel crypto API का AF_ALG लगभग सभी mainstream distributions में सक्रिय है, इसलिए 2017 से patch तक सीधे exposed रहा
  • जिन distributions पर सीधे सत्यापन किया गया: Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3, SUSE 16
  • Debian, Arch, Fedora, Rocky, Alma, Oracle, और embedded परिवार भी अगर प्रभावित kernel चला रहे हैं तो उसी तरह प्रभावित हैं

वे environment जिन्हें प्राथमिकता से patch चाहिए

  • multi-tenant Linux host में कई यूज़र एक ही kernel साझा करते हैं, इसलिए कोई भी सामान्य user account सीधे root बन सकता है
  • Kubernetes / container cluster में page cache पूरे host पर साझा होता है, इसलिए एक pod node पर नियंत्रण पा सकता है और tenant boundary पार कर सकता है
  • CI runners और build farms में सामान्य user privileges के साथ चलने वाला untrusted PR code runner पर root बन सकता है
  • user-code execution वाले Cloud SaaS में tenant द्वारा अपलोड किया गया container या script host root तक पहुँच सकता है
  • single-tenant server में यह आंतरिक LPE की प्रकृति रखता है और web RCE या चुराए गए credentials के साथ जुड़ सकता है
  • single-user laptop और workstation में urgency कम है, लेकिन local code execution सीधे root escalation तक जा सकता है

सार्वजनिक PoC और उपयोग का तरीका

  • PoC सार्वजनिक है ताकि defenders इसका उपयोग system validation और vendor patch verification के लिए कर सकें
  • copy_fail_exp.py सिर्फ Python 3.10+ standard library os, socket, zlib का उपयोग करता है
  • default target /usr/bin/su है, और argv[1] से कोई दूसरा setuid binary दिया जा सकता है
  • यह page cache में मौजूद setuid binary को संशोधित करता है; बदलाव reboot के बाद नहीं रहते, लेकिन हासिल की गई root shell वास्तव में काम करती है
  • Issue tracker

mitigation के तरीके

  • सबसे पहले kernel patch ज़रूरी है, और distribution kernel को ऐसे संस्करण पर अपडेट करना चाहिए जिसमें mainline commit a664bf3d603d शामिल हो
  • यह patch 2017 में जोड़े गए algif_aead के in-place optimization को revert करता है ताकि page cache page writable destination scatterlist में न जाए
  • patch से पहले algif_aead module disable करने की सिफारिश की जाती है
    • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
    • rmmod algif_aead 2>/dev/null || true
  • untrusted workload चलाने वाले container, sandbox, और CI में patch की स्थिति से अलग seccomp से AF_ALG socket creation block करना ज़रूरी है

disable करने पर प्रभाव

  • अधिकांश सिस्टम में मापने योग्य प्रभाव लगभग नहीं होता
  • dm-crypt / LUKS, kTLS, IPsec/XFRM, in-kernel TLS, OpenSSL/GnuTLS/NSS default build, SSH, kernel keyring crypto प्रभावित नहीं होते
    • ये kernel crypto API का सीधे उपयोग करते हैं और AF_ALG path से नहीं गुजरते
  • अगर OpenSSL में afalg engine को explicit रूप से enable किया गया है, कुछ embedded crypto offloading path, या aead/skcipher/hash socket को सीधे bind करने वाले applications प्रभावित हो सकते हैं
    • lsof | grep AF_ALG या ss -xa से जाँच की जा सकती है
  • AF_ALG बंद करने पर वे target धीमे नहीं होते जो पहले से इसका उपयोग नहीं कर रहे थे; जो करते थे वे सामान्य userspace crypto library पर वापस चले जाते हैं

सामान्य Linux LPE से अलग क्या है

  • सामान्य Linux LPE के विपरीत इसमें race condition नहीं है, और distribution-specific offset की भी ज़रूरत नहीं है
  • इसकी reliability single-shot 100% बताई गई है, और यह किसी संकीर्ण kernel version range के बजाय 2017 से 2026 तक की लंबी अवधि को कवर करती है
  • सिर्फ Python standard library का उपयोग करने वाली 732-byte payload होने के कारण compiled payload या अलग dependency की ज़रूरत नहीं है
  • write path VFS को bypass करता है और corrupted page को dirty के रूप में mark नहीं किया जाता, इसलिए disk पर कुछ भी नहीं लिखा जाता
  • page cache पूरे host में साझा होने के कारण यह साधारण LPE से आगे बढ़कर container escape primitive की तरह भी काम करता है

काम करने का तरीका और detection की विशेषताएँ

  • बिना विशेषाधिकार वाला लोकल यूज़र Linux सिस्टम के पढ़ी जा सकने वाली फ़ाइल के page cache में नियंत्रित 4 bytes लिख सकता है, और इसका उपयोग root हासिल करने के लिए कर सकता है
  • target disk पर मौजूद वास्तविक file नहीं बल्कि memory के अंदर का page cache है; /usr/bin/su की cached copy बदलने पर execve के नज़रिए से ऐसा है मानो binary खुद बदल गई हो
  • disk पर कोई बदलाव नहीं होता, इसलिए inotify trigger नहीं होता, और reboot या cache eviction के बाद मूल file फिर से लोड हो जाती है
  • sha256sum, AIDE, Tripwire जैसे सामान्य hash tool read() के ज़रिए page cache पढ़ते हैं, इसलिए जब तक cache में corruption मौजूद है तब तक baseline hash से अलग मान दिख सकता है
  • cache evict हो जाने या reboot के बाद hash फिर मूल से मेल खाने लगता है, और disk forensic image में भी सिर्फ़ unmodified file ही रहती है
  • IMA appraisal enforcing mode में अगर every-read measurement enabled हो, तो corrupted binary को execute होने से पहले execve के समय पकड़ा जा सकता है

अन्य भेद्यताओं से अंतर

  • यह Dirty Pipe जैसी श्रेणी का है, क्योंकि बिना विशेषाधिकार वाले userspace से page cache को corrupt करके disk बदले बिना setuid binary में लिखकर root पाया जा सकता है
  • mechanism अलग है: Dirty Pipe ने pipe buffer flags का दुरुपयोग किया था, जबकि Copy Fail chained scatterlist boundary के पार होने वाले AEAD scratch write का दुरुपयोग करता है
  • Dirty Pipe के लिए किसी विशेष patch वाले kernel 5.8+ की आवश्यकता थी, लेकिन Copy Fail 2017 से 2026 तक की window को कवर करता है
  • Dirty Cow के विपरीत इसमें TOCTOU-आधारित COW race जीतने की ज़रूरत नहीं होती, न ही कई बार कोशिश करनी पड़ती है या सिस्टम अस्थिर बनता है

अतिरिक्त विवरण

  • /usr/bin/su अनिवार्य नहीं है; कोई भी setuid-root binary जिसे यूज़र पढ़ सकता है, जैसे passwd, chsh, chfn, mount, sudo, pkexec, उपयोग किया जा सकता है
  • यह remote vulnerability नहीं है; पहले सामान्य user privileges के साथ local code execution चाहिए
  • अगर web RCE बिना विशेषाधिकार वाले service account तक गिरती है, SSH foothold, या CI runner में malicious PR जैसे रास्तों के साथ मिलकर यह root तक ले जा सकती है
  • patch algif_aead के in-place optimization को revert करके req->src और req->dst को फिर से अलग scatterlist में बदल देता है
  • page cache page सिर्फ read-only source में रहता है, और crypto द्वारा writable destination के रूप में सिर्फ user buffer बचता है

सार्वजनिक समयरेखा और आगे की सामग्री

  • 2026-03-23 को Linux kernel security team को रिपोर्ट किया गया
  • 2026-03-24 को प्रारंभिक पुष्टि हुई
  • 2026-03-25 को patch प्रस्तावित और review किया गया
  • 2026-04-01 को patch mainline में commit किया गया
  • 2026-04-22 को CVE-2026-31431 आवंटित किया गया
  • 2026-04-29 को https://copy.fail/ पर सार्वजनिक किया गया
  • Xint blog तकनीकी विश्लेषण
    • इसमें root cause, scatterlist diagram, 2011→2015→2017 timeline, और exploit walkthrough शामिल हैं
    • Kubernetes container escape पर Part 2 बाद में प्रकाशित होने वाला है

Xint Code से संबंधित जानकारी

  • इसे AI-assisted तरीके से खोजा गया; शुरुआती बिंदु यह मानव शोध था कि splice() page cache page को crypto subsystem तक पहुँचाता है और scatterlist में page origin कम खोजा गया bug class हो सकता है
  • इसके बाद Xint Code ने Linux crypto/ subsystem के पूरे audit को लगभग 1 घंटे के पैमाने तक बढ़ाया, और उसके परिणामों में सबसे गंभीर item Copy Fail था
  • Xint Code
    • Xint blog write-up
    • उसी scan में अन्य high-risk bug भी मिले, और वे अभी coordinated disclosure में हैं

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.