copyfail-deconstructed

CVE-2026-31431 का आसानी से समझ में आने वाला संस्करण, एक विशेषाधिकार वृद्धि तकनीक जो किसी को भी रूट बनने की अनुमति देती है। मूल प्रूफ-ऑफ-कॉन्सेप्ट यहाँ पाया जाता है: https://github.com/theori-io/copy-fail-CVE-2026-31431, लेकिन इसे काफी संकुचित और छोटा किया गया है ताकि इसका पदचिह्न जितना संभव हो उतना छोटा हो। यह रिपॉजिटरी उस कोड को अधिक पठनीय तरीके से तोड़ने का प्रयास करती है, जिसमें कोड क्या करता है, पेलोड कैसे लोड किया जाता है, और विभिन्न आर्किटेक्चर को कैसे लक्षित किया जाए। अधिक तकनीकी लेख यहाँ देखें: https://xint.io/blog/copy-fail-linux-distributions.

उपयोग

डिफ़ॉल्ट रूप से, python3 copyfail.py चलाने पर /usr/bin/su का शोषण करने वाला x64 शेलकोड चलेगा। आप python3 copyfail.py [path/to/custom/payload.elf] चलाकर अपना स्वयं का पेलोड प्रदान कर सकते हैं। एक उदाहरण के रूप में, payloads/ के अंदर एक ARM64 शेलकोड असेंबली है। इसलिए ARM64 उपकरणों पर परीक्षण करने के लिए, आपको पहले हमारी कस्टम लिंकर स्क्रिप्ट के साथ एक न्यूनतम पेलोड बनाना चाहिए:

as -o shellcode_aarch64.o payloads/shellcode_aarch64.S
ld -nostdlib -static -o shellcode_aarch64.elf shellcode_aarch64.o
strip -s shellcode_aarch64.elf

फिर आप python3 copyfail.py shellcode_aarch64.elf का उपयोग करके मुख्य शोषण चला सकते हैं।

C पर चलाने के लिए:

1. बिल्ड करें (नीचे देखें)
2. ./c_copyfail जो ऊपर जैसा ही डिफ़ॉल्ट शेलकोड चलाता है।

• आप ./c_copyfail [path/to/custom/payload.elf] चलाकर फिर से अपना स्वयं का पेलोड प्रदान कर सकते हैं।

C संस्करण बनाने के लिए:

cd c_port
make

विशेष रूप से, यह लक्ष्य .S फ़ाइल को एक कच्चे बाइनरी में संकलित करता है जिसे C unsigned char array के रूप में आउटपुट किया जाता है:

gcc -c payloads/[shellcode].S
objcopy -O binary [shellcode].o [payload].raw
xxd -i [payload].raw > payload.txt

या, 32-बिट x86 के लिए,

gcc -c -m32 payloads/[shellcode].S
objcopy -O binary [shellcode].o [payload].raw
xxd -i [payload].raw > payload.txt

फिर आप इस फ़ाइल की सामग्री को अपने स्रोत कोड में कॉपी कर सकते हैं, या आप सीधे ./c_copyfail.exe [path/to/payload.elf] चला सकते हैं जहां payload.elf as + ld से उत्पन्न होता है, gcc + objcopy से नहीं।

सुधार

शोषण से बचने के लिए, चलाएँ:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

यदि पहले ही शोषण हो चुका है, तो आप मशीन को पुनरारंभ कर सकते हैं, या चलाएँ: echo 3 | sudo tee /proc/sys/vm/drop_caches

स्पष्टीकरण

1. कर्नेल उपयोगकर्ता को सॉकेट प्रकार AF_ALG के माध्यम से क्रिप्टो API से बात करने की अनुमति देता है

• 2017 में, क्रिप्टो API के algif_aead भाग में "इन-प्लेस ऑप्टिमाइज़ेशन" जोड़ा गया था
• जब splice() सिस्टम कॉल का उपयोग करके सॉकेट के माध्यम से डेटा भेजा जाता है, तो कर्नेल उस फ़ाइल के वास्तविक पेज-कैश पेजों को क्रिप्टो कार्य क्षेत्र में रखता है जिसे आपने स्प्लिस किया था
• क्रिप्टो एल्गोरिदम ऑथेंसन अपने आउटपुट बफर को स्क्रैच स्पेस के रूप में मानता है और जहाँ उसे लिखना चाहिए उससे 4 बाइट आगे लिखता है

2. काल्पनिक पक्ष क्या कर सकता है

• किसी भी पढ़ने योग्य फ़ाइल का चयन करें (जैसे, इस मामले में /usr/bin/su)
• उस फ़ाइल के अंदर ऑफसेट चुनें जहाँ 4-बाइट लेखन होगा
• लिखने के लिए 4-बाइट मान चुनें (AEAD ऑपरेशन में संबद्ध डेटा का भाग)
• फ़ाइल को मेमोरी में ओवरराइट करने के लिए शेल कोड लिखें

3. पेज-कैश को रूट में ओवरराइट करना

• कर्नेल कभी भी दूषित पेज को गंदा के रूप में चिह्नित नहीं करता, फ़ाइल अपरिवर्तित दिखती है
• जब /usr/bin/su निष्पादित होता है, तो कर्नेल इसे पेज कैश से पढ़ता है और संशोधित बाइट्स प्राप्त करता है
• 4-बाइट लेखन (लगभग 40 बार) दोहराकर, वे /usr/bin/su के अंदर UID जांच को ओवरराइट कर सकते हैं ताकि UID 0 (रूट) हो जाए
• किसी भी उपयोगकर्ता के लिए रूट शेल प्राप्त होता है

4. उपचार

• मेमोरी में संशोधित फ़ाइलों को हटाने के लिए पेज कैश फ्लश करें, ताकि अगली बार डिस्क से पढ़े
• कर्नेल मॉड्यूल अनलोड करें
• लोड होने से ब्लैकलिस्ट करें
• यदि यह बिल्ट-इन मॉड्यूल है, तो आपको seccomp या eBPF का उपयोग करके सिस्टम कॉल को ब्लॉक करना होगा। या इसे आरंभिकरण से हटाएँ और मशीन को रीबूट करें।

su बाइनरी मेमोरी में दूषित हो जाती है, इसलिए फ़ाइल संशोधन का पता नहीं चलेगा। डिस्क से पुनर्स्थापित करने के लिए, आप पेज-कैश फ्लश कर सकते हैं।