DirtyFrag CVE-2026-43284 PoC Validation و auditd Detection

النطاق: التحقق من تصعيد الامتيازات المحلية (LPE) في لينكس مع التركيز على مسار XFRM/ESP المرتبط بـ CVE-2026-43284.

يحتوي هذا المستودع على تقرير باللغة الإنجليزية وأدلة من اختبار معملي خاضع للرقابة على PoC العام لـ DirtyFrag. التركيز ليس على تقديم دليل استغلال، بل على توثيق ما كان مرئيًا في سجلات تدقيق لينكس وكيف يمكن تحويل هذه الأحداث إلى منطق كشف قابل للاستخدام في SOC.

تقرير PDF كامل:

EN: reports/DirtyFrag_CVE-2026-43284_EN.pdf

PL: reports/DirtyFrag_CVE-2026-43284_PL.pdf

الغرض والنطاق

تم إجراء الاختبار للتحقق مما إذا كان بإمكان مستخدم محلي عادي الحصول على شل جذر في آلة افتراضية معرضة للخطر، وتحديد الأحداث التي يمكن التقاطها باستخدام auditd.

يتعلق CVE-2026-43284 بمعالجة غير صحيحة لأجزاء الصفحات المشتركة أثناء عمليات ESP/IPsec. في ظل ظروف معينة، يمكن لمهاجم محلي التأثير على البيانات في ذاكرة التخزين المؤقت للصفحات وتصعيد الامتيازات. تقيّم أمان أوبونتو هذه الثغرة بـ CVSS 3.1: 7.8 عالية.

مراجع تقنية:

• مستودع PoC العام لـ DirtyFrag: https://github.com/V4bel/dirtyfrag
• أمان أوبونتو - CVE-2026-43284: https://ubuntu.com/security/CVE-2026-43284
• مدونة أوبونتو - إصلاحات ثغرة Dirty Frag في لينكس متاحة: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available

بيئة الاختبار

خط الأساس الكامل للنظام: evidence/logs/system-info-table.md

النتيجة

قبل تنفيذ PoC، كان سياق الاختبار حساب مستخدم عادي. بعد تشغيل ./exp، تم الحصول على شل جذر وتأكيده باستخدام whoami و id.

جمع الأدلة

بعد الاختبار، تم تصدير سجلات auditd ومخرجات الملخص إلى دليل أدلة محلي ونسخها إلى هذا المستودع.

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

منطق الكشف في auditd

الكشف الأكثر فائدة ليس حدثًا واحدًا. أقوى إشارة هي السلسلة الكاملة التي تُلاحظ في نافذة زمنية قصيرة:

مساحة اسم المستخدم -> vmsplice/splice -> ESP/XFRM -> su -> شل جذر مع AUID لمستخدم عادي

مفاتيح auditd ذات الصلة

سلسلة الأحداث المعاد بناؤها

مثال على ارتباط SIEM

IF
  dirty_frag_unshare بواسطة auid>=1000
  AND عدد (dirty_frag_vmsplice + dirty_frag_splice بواسطة نفس exe أو pid) >= 3 خلال 600 ثانية
  AND نشاط MAC_IPSEC_EVENT / XFRM خلال 1200 ثانية
  AND (dirty_frag_su_exec OR execve مع euid=0 و auid>=1000) خلال 1200 ثانية
THEN
  تنبيه = "احتمال وجود LPE في لينكس عبر DirtyFrag CVE-2026-43284"
  الخطورة = عالية / حرجة

توصيات SOC

• قم بتحديث النواة وفرض إعادة التشغيل إلى النواة المحدثة بعد التحديثات.
• اجمع تتبع استدعاءات النظام باستخدام auditd أو Falco أو أدوات تعتمد على eBPF أو EDR.
• لا تطلق تنبيهًا على حدث euid=0 واحد فقط؛ فهذا يلتقط أيضًا استخدام sudo المشروع.
• اربط بين unshare و vmsplice و splice ونشاط XFRM/ESP و su وإنشاء عملية جذر من جلسة مستخدم عادية.
• فكر في تقييد kernel.unprivileged_userns_clone حيثما يسمح توافق التطبيق بذلك.
• راجع ما إذا كانت وحدات ESP/IPsec مطلوبة على نوع المضيف المحدد، وقيد تحميل الوحدات غير الضرورية حيثما كان ذلك مناسبًا.
• أعد توجيه السجلات إلى مجمع بعيد أو SIEM؛ بعد LPE، يمكن للمهاجم تعديل السجلات المحلية.
• راقب جودة auditd: يجب أن يظل lost يساوي 0 أثناء الاختبار والمراقبة الإنتاجية.
• احتفظ بدليل استجابة لحوادث LPE في لينكس يغطي عزل المضيف وجمع سجلات التدقيق والتحقق من النواة قيد التشغيل والتقاط الوحدات المحملة.

ملاحظات

أظهرت حالة auditd المجمعة lost=2555، مما يعني أن بعض أحداث التدقيق قد تكون فُقدت. لا تزال السلسلة الرئيسية مرئية، ولكن يجب أن تزيد الاختبارات المستقبلية من backlog auditd وتؤكد lost=0 قبل تشغيل PoC.

يركز التقرير عمدًا على CVE-2026-43284 / XFRM/ESP لتجنب خلط نطاق كشف SOC مع مسارات أخرى متعلقة بـ DirtyFrag.