copyfail

अवलोकन

Copy Fail (CVE-2026-31431) — Linux कर्नेल में एक तार्किक भेद्यता है, जो स्थानीय अन-विशेषाधिकार प्राप्त उपयोगकर्ता को सुपरयूज़र (root) स्तर तक विशेषाधिकार बढ़ाने की अनुमति देती है। यह भेद्यता Local Privilege Escalation (LPE) वर्ग से संबंधित है, जिसके लिए जटिल शोषण स्थितियों (जैसे race condition या मेमोरी में एड्रेस खोजना) की आवश्यकता नहीं होती है, और यह 2017 के बाद जारी अधिकांश Linux वितरणों पर "आउट-ऑफ-द-बॉक्स" काम करती है।

इस रिपॉजिटरी में मूल Python एक्सप्लॉइट का C भाषा में पोर्ट विस्तृत टिप्पणियों के साथ शामिल है, जो स्टैटिक कंपाइलेशन और न्यूनतम वातावरण में उपयोग के लिए उपयुक्त है।

सामग्री

• भेद्यता
  • भेद्यता का सार
  • शोषण तंत्र
  • प्रभावित सिस्टम
• एक्सप्लॉइट
  • C पोर्ट की विशेषताएं
  • कंपाइलेशन
  • उपयोग
• यह कैसे काम करता है
  • चरण-दर-चरण विश्लेषण
  • पेज कैश क्यों बदलता है
• भेद्यता का समाधान

भेद्यता

भेद्यता का सार

यह भेद्यता Linux कर्नेल की क्रिप्टोग्राफिक उपप्रणाली में एक तार्किक त्रुटि के कारण उत्पन्न होती है, जो AF_ALG (कर्नेल के क्रिप्टोग्राफिक API का इंटरफ़ेस) और पेज कैश (page cache) तंत्र के प्रसंस्करण से संबंधित है।

यह त्रुटि 2017 में एक अनुकूलन जोड़ते समय पेश की गई थी, जिसने AEAD (Authenticated Encryption with Associated Data) ब्लॉक सिफर संचालन को इन-प्लेस (in-place) निष्पादित करके अतिरिक्त बफरिंग को हटा दिया। authencesn एल्गोरिथम (AEAD क्रिप्टोग्राफिक टेम्पलेट का हिस्सा) में बफर सीमाओं के गलत प्रसंस्करण के कारण, आवंटित बफर से 4 बाइट्स आगे लिखा जाता है, जिससे पेज कैश के नियंत्रण संरचनाओं को नुकसान पहुंचता है।

परिणामस्वरूप, कर्नेल फ़ाइल के पेज कैश में डेटा वापस लिख सकता है, भले ही वह केवल पढ़ने के लिए खोला गया हो (O_RDONLY)।

शोषण तंत्र

1. अन-विशेषाधिकार प्राप्त उपयोगकर्ता AF_ALG सॉकेट खोलता है और AEAD एल्गोरिथम authencesn(hmac(sha256),cbc(aes)) को आरंभ करता है।
2. setsockopt() के माध्यम से असामान्य पैरामीटर सेट किए जाते हैं:
   • विशेष प्रारूप की कुंजी (कर्नेल बफर में हेरफेर)।
   • प्रमाणीकरण टैग का आकार = 4 बाइट्स (HMAC-SHA256 के लिए सामान्य 16–32 बाइट्स के बजाय)।
3. sendmsg() के माध्यम से control messages के साथ डिक्रिप्शन ऑपरेशन आरंभ किया जाता है।
4. splice() सिस्टम कॉल लक्ष्य फ़ाइल (जो O_RDONLY से खोली गई है) से डेटा को क्रिप्टो-सॉकेट में स्थानांतरित करता है।
5. authencesn में त्रुटि के कारण फ़ाइल का पेज कैश क्षतिग्रस्त हो जाता है, और "डिक्रिप्टेड" डेटा वापस कैश में लिखा जाता है।
6. कर्नेल पेज कैश से संशोधित setuid-फ़ाइल निष्पादित करता है, जिससे root अधिकारों के साथ कोड निष्पादन होता है।

प्रभावित सिस्टम

संवेदनशील वितरण (जब कर्नेल में algif_aead मॉड्यूल लोड हो):

• Ubuntu (सभी संस्करण)
• Debian (सभी संस्करण)
• RHEL / CentOS / Rocky / Alma Linux
• SUSE / openSUSE
• Fedora
• Arch Linux
• संवेदनशील कर्नेल पर आधारित अन्य वितरण

विशेष महत्व: कंटेनर वातावरण (Docker, LXC, Kubernetes) में, कंटेनर के अंदर की प्रक्रियाओं के लिए AF_ALG उपप्रणाली डिफ़ॉल्ट रूप से उपलब्ध होती है, यदि मॉड्यूल algif_aead होस्ट कर्नेल में लोड हो। यह कंटेनर अलगाव के उल्लंघन और होस्ट मशीन पर नियंत्रण प्राप्त करने का जोखिम पैदा करता है।

भेद्यता की जांच:

# जांचें कि क्या algif_aead मॉड्यूल लोड है
lsmod | grep algif

# कर्नेल में AF_ALG की उपस्थिति जांचें
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

एक्सप्लॉइट

C पोर्ट की विशेषताएं

मूल एक्सप्लॉइट Python में लिखा गया था (≈732 बाइट्स)। इस C पोर्ट में निम्नलिखित विशेषताएं हैं:

• स्टैटिक कंपाइलेशन — Python के बिना न्यूनतम वातावरण में काम करता है।
• पूर्ण स्वायत्तता — केवल मानक C लाइब्रेरी और libz की आवश्यकता होती है।
• रूसी में विस्तृत टिप्पणियां — शोषण का प्रत्येक चरण प्रलेखित है।
• समान व्यवहार — सिस्टम कॉल Python संस्करण से बिल्कुल मेल खाते हैं (strace के माध्यम से सत्यापित)।
• गैर-अवरोधक recv() — Python के try/except व्यवहार को दोहराते हुए हैंग होने से रोकता है।

पोर्टिंग के दौरान पहचाने गए Python संस्करण से मुख्य अंतर:

कंपाइलेशन

# libz आवश्यक है (zlib1g-dev या zlib-devel)
gcc -o copyfail copyfail.c -lz -static -Wall -O2

उपयोग

./copyfail

सफल शोषण पर, /usr/bin/su का एक पैच किया हुआ संस्करण लॉन्च किया जाएगा, जो पासवर्ड के बिना root-एक्सेस प्रदान करता है।

अपेक्षित आउटपुट:

================================================================
  CVE-2026-31431 'Copy Fail' Exploit
================================================================

[+] /usr/bin/su खोला गया
[+] 40 चंक्स
[*] 40/40 ठीक

# id
uid=0(root) gid=0(root) groups=0(root)

यह कैसे काम करता है

चरण-दर-चरण विश्लेषण

नीचे एक्सप्लॉइट के प्रत्येक चरण का विस्तृत विश्लेषण संबंधित सिस्टम कॉल के साथ दिया गया है:

चरण 1: AF_ALG सॉकेट का निर्माण

socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(sock, {sa_family=AF_ALG, salg_type="aead", 
     salg_name="authencesn(hmac(sha256),cbc(aes))"}, 88);

कर्नेल के क्रिप्टोग्राफिक API तक पहुंच के लिए एक सॉकेट बनाया जाता है। authencesn (Authenticated Encryption with Sequence Numbers) एल्गोरिथम एक समग्र AEAD एल्गोरिथम है, जो एन्क्रिप्शन के लिए AES-CBC और प्रमाणीकरण के लिए HMAC-SHA256 का उपयोग करता है।

चरण 2: संवेदनशील पैरामीटर सेट करना

setsockopt(sock, SOL_ALG, ALG_SET_KEY, key, 40);
setsockopt(sock, SOL_ALG, ALG_SET_AEAD_AUTHSIZE, NULL, 4);

• कुंजी: 40 बाइट्स विशेष प्रारूप की, जो कर्नेल के आंतरिक बफर में हेरफेर करती है।
• प्रमाणीकरण टैग का आकार: 4 बाइट्स। HMAC-SHA256 के लिए सामान्य मान 16–32 बाइट्स है। असामान्य रूप से छोटा मान कर्नेल में बफर ओवरफ्लो की ओर ले जाता है।

चरण 3: डिक्रिप्शन ऑपरेशन की आरंभिका

accept(sock, NULL, NULL);  // conn_sock
sendmsg(conn_sock, {payload="AAAA"+data, 
        cmsg=[(SOL_ALG, 3, 4 शून्य),        // ALG_SET_OP = DECRYPT
              (SOL_ALG, 2, 0x10+19 शून्य),  // ALG_SET_IV
              (SOL_ALG, 4, 0x08+3 शून्य)]},  // ALG_SET_AEAD_ASSOCLEN
        MSG_MORE);

ऑपरेशन के लिए एक कनेक्शन बनाया जाता है। sendmsg() के माध्यम से control messages (CMSG) के साथ पैरामीटर सेट किए जाते हैं:

• ऑपरेशन: डिक्रिप्शन (ALG_OP_DECRYPT = 0)।
• IV: 20 बाइट्स (AES के लिए सामान्य 16 के बजाय)।
• संबद्ध डेटा: 8 बाइट्स (वास्तविक डेटा ट्रांसमिशन के बिना)।

ये सभी विसंगतियां कर्नेल की मेमोरी प्रबंधन में असंगतताएं पैदा करती हैं।

चरण 4: splice() के माध्यम से डेटा स्थानांतरण

pipe2(pipe_fds, O_CLOEXEC);
splice(target_fd, &src_off, pipe_fds[1], NULL, o, 0);
splice(pipe_fds[0], NULL, conn_sock, NULL, o, 0);

splice() — फ़ाइल डिस्क्रिप्टर के बीच userspace के माध्यम से कॉपी किए बिना डेटा स्थानांतरित करने के लिए सिस्टम कॉल है। डेटा pipe तंत्र के माध्यम से कर्नेल स्तर पर स्थानांतरित होता है।

1. splice(target_fd -> pipe): लक्ष्य फ़ाइल (/usr/bin/su) से डेटा pipe में जाता है।
2. splice(pipe -> conn_sock): pipe से डेटा क्रिप्टो-सॉकेट में "सिफरटेक्स्ट" के रूप में प्रवेश करता है।

मुख्य बिंदु: Python (और इस पोर्ट) में, pipe के लिए ऑफसेट NULL के रूप में पास किया जाता है, जो कर्नेल को स्थिति को स्वचालित रूप से प्रबंधित करने की अनुमति देता है।

चरण 5: फाइनलाइज़ेशन और त्रुटि की अनदेखी

fcntl(conn_sock, F_SETFL, O_NONBLOCK);
recv(conn_sock, buf, 8 + t, 0);

recv() कॉल कर्नेल को क्रिप्टोग्राफिक ऑपरेशन पूरा करने के लिए मजबूर करता है। सामान्य मोड में, डिक्रिप्टेड डेटा यहां वापस आएगा, लेकिन असामान्य पैरामीटर के कारण EBADMSG (Python) या EAGAIN (O_NONBLOCK के साथ C) त्रुटि लौटती है। त्रुटि को अनदेखा किया जाता है — पेज कैश को नुकसान पहले ही splice() चरण में हो चुका होता है।

पेज कैश क्यों बदलता है

पेज कैश (page cache) — रैम में फ़ाइलों की सामग्री का कैश है। जब कोई प्रक्रिया O_RDONLY के माध्यम से फ़ाइल खोलती है, तो कर्नेल इस कैश से केवल पढ़ने की अनुमति देता है। हालांकि, यह भेद्यता इस सीमा को दरकिनार करने की अनुमति देती है:

1. बफर आकारों की असंगति: authsize=4, 16–32 के बजाय, गलत आकार के बफर बनाता है।
2. बफर ओवरफ्लो: "डिक्रिप्शन" के दौरान डेटा आवंटित बफर की सीमा से बाहर लिखा जाता है।
3. संदर्भ काउंटर का नुकसान: ओवरफ्लो पेज नियंत्रण संरचनाओं (page reference count) को प्रभावित करता है।
4. कैश में लेखन: कर्नेल, यह सोचकर कि पेज मुक्त है, वहां "डिक्रिप्टेड" डेटा लिखता है।
5. O_RDONLY की अनदेखी: एक्सेस अधिकारों की जांच write() कॉल के समय VFS स्तर पर होती है, लेकिन splice() सीधे पेज कैश स्तर पर काम करता है, इन जांचों को दरकिनार करते हुए।

परिवर्तन केवल रैम में होते हैं, डिस्क पर नहीं। यह हमले को मानक अखंडता नियंत्रण उपकरणों द्वारा पता लगाना कठिन बनाता है। रीबूट या पेज कैश साफ़ करने के बाद, हमले के निशान गायब हो जाते हैं।

भेद्यता का समाधान

मुख्य तरीका

Linux कर्नेल को उस संस्करण में अपडेट करें जिसमें सुधार शामिल हो।

अस्थायी उपाय

मॉड्यूल algif_aead को अक्षम करें:

# मॉड्यूल लोडिंग को प्रतिबंधित करें
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/algif_aead.conf

# मॉड्यूल अनलोड करें (यदि लोड हो)
sudo rmmod algif_aead

अतिरिक्त सिफारिशें:

• उपयोगकर्ताओं के लिए स्थानीय एक्सेस सीमित करें।
• कर्नेल और सिस्टम अखंडता की निगरानी का उपयोग करें।
• न्यूनतम विशेषाधिकार सिद्धांत लागू करें।
• कंटेनर वातावरण में, seccomp-प्रोफाइल के माध्यम से AF_ALG तक पहुंच प्रतिबंधित करें।

क्या फ़ाइल /usr/bin/su डिस्क पर बदलती है?

नहीं। परिवर्तन केवल पेज कैश (रैम) में होते हैं। डिस्क पर फ़ाइल की सामग्री अपरिवर्तित रहती है। सिस्टम रीबूट के बाद, पेज कैश साफ़ हो जाता है, और फ़ाइल अपनी मूल स्थिति में लौट आती है।

क्या शोषण का पता लगाया जा सकता है?

पता लगाना संभव है:

• सिस्टम कॉल की निगरानी (auditd, strace)।
• AF_ALG सॉकेट के उपयोग में विसंगतियों का विश्लेषण।
• मेमोरी में फ़ाइल अखंडता का नियंत्रण (डिस्क पर नहीं)।

मानक अखंडता नियंत्रण उपकरण (AIDE, Tripwire) परिवर्तनों का पता नहीं लगाएंगे, क्योंकि डिस्क पर फ़ाइल अपरिवर्तित रहती है।

अस्वीकरण

यह कोड केवल शैक्षिक और शोध उद्देश्यों के लिए प्रदान किया गया है। लेखक इस कोड के किसी भी गैरकानूनी उपयोग के लिए जिम्मेदार नहीं है। सिस्टम मालिक की स्पष्ट अनुमति के बिना एक्सप्लॉइट का उपयोग अवैध है और आपराधिक दायित्व का कारण बन सकता है।

केवल उन सिस्टम पर उपयोग करें जो आपके हैं, या उन सिस्टम पर जहां आपके पास सुरक्षा परीक्षण के लिए स्पष्ट लिखित अनुमति है।