ثغرات core في Linux - Ubuntu وRedHat: حماية!!

إيه الحكاية دي؟ ثغرتين في Linux بتخلي الهاكر يطلع معلومات حساسة من الذاكرة ​

اتكشف عن ثغرتين أثروا على توزيعات لينكس؛ الأولى متعلقة بـ Apport في Ubuntu، والتانية متعلقة بـ systemd-coredump (المستخدم في RHEL/Fedora وغيرها). الثغرتين دول ممكن يخَلّوا حد عنده حساب محلي يستغل حاجة اسمها core dumps علشان يطلع معلومات كانت موجودة في ذاكرة برنامج صاحبه صلاحيات عالية - زي تجزئة الباسورد اللي جوه /etc/shadow.

---

قبل ما نغوص: يعني إيه PID وcore dump؟ ​

• PID (Process ID) هو رقم مميز بيتدي لكل عملية شغالة في النظام. كل برنامج ليه PID.
• Core dump هو ملف بيتعمل لما برنامج يقع (crash)، وبيحتوي على snapshot للذاكرة في وقت الوقوع - يعني ممكن يبقى فيه سِرّيات، كلمات مرور، مفاتيح تشفير، إلخ.

اللي حصل في الثغرتين إن في حالة سباق (race condition) ممكن الهاكر يخلّي برنامج بصلاحيات عالية ينهار، وبعدها يخلق برنامج تاني بنفس الـ PID أو يخدع الـ core-dump handler بحيث يوصل لملف التفريغ بتاع البرنامج الأول ويقراه.

---

الثغرة الأولى: CVE-2025-5054 (Apport على Ubuntu) ​

باختصار: في Apport (أداة Ubuntu المسؤولة عن التعامل مع crash reports) في إصدار لحد 2.32.0، اتشاف race condition بيخلي معالجات الـ namespace أو الكونتينر تتعامل غلط مع بيانات الـ PID، وده يسمح بتسريب بيانات من core dumps لو اتظبط الهاكر الحالة دي. التأثير متخصِّص بس في confidentiality (قراءة بيانات حساسة من الذاكرة).

---

الثغرة التانية: CVE-2025-4598 (systemd-coredump في RHEL/Fedora) ​

دي شبه الأولى لكن أخطر لأنها بتأثر على systemd-coredump في أنظمة زي RHEL/Fedora. السيناريو: بتخلي عملية SUID (برنامج يشتغل بصلاحية أعلى) تقع، والهاكر يسرع ويشغّل عملية تانية بنفس PID قبل ما systemd-coredump يكمل شغله - لو نجح في السباق ده يقدر يقرأ ملف التفريغ بتاع العملية الأولى اللي كان فيها بيانات حساسة زي /etc/shadow. Red Hat وموارد تانية وضحوا إن الاستغلال معقد شوية لكن ممكن يحصل في ظروف معينة.

---

مثال عملي: ليه الهاكر مهتم بـ /etc/shadow؟ ​

ملف /etc/shadow بيحتفظ بـ password hashes للمستخدمين. لو حد قدر يطلع الهاشات دي ممكن يحاول يكسرها offline ويطلع كلمات السر الحقيقية - وده خطر كبير لأي نظام عنده حسابات محلية. الثغرة بتسمح بقراءة ذاكرة عملية كانت بتتعامل مع هذي البيانات لو اتخيلت الظروف المناسبة.

---

إزاي تحمي نفسك فورًا (خطوات سريعة ومجربة) ​

مبدئيًا: لو تقدر تحدث النظام فورًا للباكِت اللي بيسد الثغرات، ده أفضل حل. لكن لحد ما التحديث يوصل أو تتأكد، نفّذ الخطوات دي:

1) إيقاف تفريغ الذاكرة لبرامج SUID (أبسط حل مؤقت)​

كده بنمنع السِّيستم إنه يولّد core dump من برامج SUID، وده يقطع الطريق قدام الاستغلال.

# كسطر root
echo 0 > /proc/sys/fs/suid_dumpable
# أو عشان يبقى ثابت بعد ريستارت حط في /etc/sysctl.conf
fs.suid_dumpable=0
sudo sysctl -p

التعليمات دي مجرّبة ومذكورة كحل مؤقت من عدة مصادر أمنية ورسمية.

ملاحظة: الإجراء ده يمنع تسجيل core dumps للـ SUID binaries، يعني هتخسر إمكانية تحليل الأعطال بتاعة برامج SUID لو حصلت مشاكل - لكن للتخفيف من خطر تسريب الهاشات ده trade-off مقبول مؤقتًا.

2) لو بتستخدم systemd-coredump: تعطيله لو مش محتاجه​

لو انت على RHEL/Fedora أو على أي نظام مثبت عليه systemd-coredump ومش محتاج تسجّل core dumps:

# كـ root
sudo systemctl disable --now systemd-coredump.service

أو تقدر تمنع إنشاء ملفات التفريغ في المكان الافتراضي بتاعها عبر إعدادات systemd-coredump (راجع الـ docs أو advisories للتوزيعة بتاعتك).

3) اتأكد مين مثبت عنده Apport أو systemd-coredump​

بعض التوزيعات الافتراضية ممكن تبقى مش مثبتة systemd-coredump، وApport افتراضي في Ubuntu فقط. لو مش متأكد، دور كالتالي:

# افحص وجود paket apport
dpkg -l | grep apport

# افحص وجود systemd-coredump
rpm -qa | grep systemd-coredump

لو لقيت الحزمة ومش محتاجها - فكّر تشيلها أو عطلها لحد ما تعمل update آمن.

4) راجع صلاحيات المستخدمين والعزل (namespaces / containers)​

الثغرات بتستغل في بعض السيناريوهات قدرات الـ user namespaces داخل كونتينرات أو حالات يكون فيها إعادة استخدام PID ممكن تحصل. قلل صلاحيات المشتركين، وماتديش unprivileged users قدرات namespace كاملة إلا لو ضروري.

5) حدث النظام فورًا وراجع advisories الرسمية​

تابع التحديثات الرسمية من Ubuntu وRed Hat، وقم بتطبيق الـ security updates أول ما تتوفر. المصادر الرسمية فيها تفاصيل الباكِت والنسخ المتأثرة وطريقة الإصلاح.

---

رأيي العملي كـ مهندس / مُعلِّم شبكات - خطوات للـ sysadmins ​

1. طبق fs.suid_dumpable=0 فورًا على الأنظمة المنتشرة عندك كإجراء احترازي.
2. اعمل فحص لأي حاويات أو أنظمة بتدي صلاحيات namespaces للمستخدمين العاديين.
3. راجع المراقبة والـ logs لأي محاولات crash مش مبررة أو عمليات خلق/إعادة PID مريبة.
4. خلي خطة تراجع (rollback) جاهزة لو عطلت systemd-coredump ولاحظت مشاكل في الـ debugging.
5. لو عندك سيستمات مهمة جرب وضع سياسات صارمة لتخزين الـ core dumps (إلى مكان مؤمن فقط، مع تشفير وصلاحيات محدودة) بدل السماح بالتخزين العام.

---

هل المخاطرة كبيرة؟ وهل في استغلال جاهز؟ ​

الـ CVSS للبعض من النصوص وصفته بأنها "Moderate" لأن الاستغلال فعليًا محتاج ظروف معقدة (حساب محلي، سباق ناجح، إلخ)، لكن مع ذلك الأثر على السرية (confidentiality) كبير جدًا لو نجح الهجوم - خصوصًا على خوادم عندها حسابات محلية أو بيانات حساسة. شركة Qualys عرضت proof-of-concepts في تقاريرها، ده معناه إن الباحثين قدروا يظهروا الفكرة عمليًا - فالإجراء الوقائي مطلوب.

---

خلاصة سريعة (لو بتدور على خطوات عملية دلوقتي) ​

1. نفّذ: echo 0 > /proc/sys/fs/suid_dumpable فورًا على الخوادم المهمة.
2. لو مش محتاج

   systemd-coredump: sudo systemctl disable --now systemd-coredump.service

   .
3. راجع صلاحيات namespaces والـ containers.
4. طبق التحديثات الرسمية لما تصدر من Ubuntu/Red Hat. (Ubuntu)