
إرشادات البحث والكشف عن CVE-2026-31431، وهو تجاوز قائم على io_uring لمراقبة استدعاءات النظام. يوفر قواعد كشف لـ Tetragon وFalco وWazuh، بالإضافة إلى استراتيجيات التحصين.
بالنسبة لـ CVE-2026-31431 ("Copy Fail")، أظهرنا نقاط ضعف منهجية في منتجات الأمان السائدة من خلال الجمع بين ثلاث استراتيجيات تجاوز: مسار الإدخال/الإخراج غير المتزامن io_uring، تقسيم العمليات (fork + SCM_RIGHTS)، وإعادة استخدام المقابس. من خلال الاختبار التجريبي، أثبتنا أن هذه التقنيات يمكنها تفادي جميع أدوات الكشف القائمة على استدعاءات النظام تقريبًا.
يُرسل io_uring الطلبات عبر مخازن حلقية للذاكرة المشتركة، متجاوزًا نقاط دخول استدعاءات النظام التقليدية. هذا يعني:
iou-wrk-XXXXX) تنفذ العمليات داخل النواة دون تفعيل audit_syscall_entry()socket(AF_ALG) عبر IORING_OP_SOCKET — يتحقق seccomp فقط عند دخول استدعاء النظام، وعمليات io_uring لا تمر عبر نقطة الدخول تلكباستخدام fork + SCM_RIGHTS (تمرير واصفات الملفات عبر مقابس نطاق يونكس)، يمكن وضع عمليات إنشاء المقبس وعمليات splice في عمليات مختلفة:
same_field(audit.pid) في Wazuh ينكسر — PID المقبس ≠ PID عملية splice، قاعدة CRITICAL لا تُفعَّلينشئ الـ PoC الأصلي مقبسًا جديدًا لكل تكرار (مما ينتج 40+ استدعاء socket(AF_ALG)). إعادة استخدام المقبس تنشئ مقبس استماع واحد فقط؛ الحلقة تستدعي accept() الذي لا ينتج أحداث مقابس جديدة. القواعد القائمة على count >= N تُهزم تمامًا.
مسار io_uring + splice + /etc/passwd + خوارزمية authenc + تقسيم SCM_RIGHTS + إعادة استخدام المقبس
تحت هذه المجموعة: أدوات الكشف القائمة على استدعاءات النظام عمياء تمامًا، الارتباط على مستوى العملية منكسر، عتبات العد تفشل. فقط اكتشاف نقطة التقارب عبر kprobe يمكنه التقاط هذه المجموعة.
__sock_create(family=38) هي نقطة تقارب لا يمكن تجاوزها لجميع المسارات (استدعاءات النظام و io_uring) — AF_ALG هي واجهة برمجة التشفير الوحيدة في مساحة المستخدم في نواة لينكس. بغض النظر عن كيفية تنويع المهاجمين لنهجهم، يجب عليهم إنشاء مقبس AF_ALG. مراقبة هذه الدالة على مستوى LSM توفر استدعاءً بنسبة 100% ولا تتأثر بأي متغير.
مشغل modern_ebpf الأصلي في Falco يلتقط مسار استدعاء النظام فقط. إضافة krsi مطلوبة — تستخدم تتبع fexit على مخارج دالتي النواة io_socket() و __sys_socket() لتغطية مسار io_uring لإنشاء مقبس AF_ALG. القاعدة الاحتياطية الموصى بها:
- rule: AF_ALG Socket Created
condition: >
(evt.type = socket and evt.args contains AF_ALG) or
(evt.type = krsi_socket and krsi.domain = 38)
output: >
AF_ALG socket created (source=%evt.type domain=%evt.arg.domain
krsi_domain=%krsi.domain proc=%proc.name pid=%proc.pid)
priority: WARNING
tags: [cve-2026-31431, crypto, container_escape]
نهج الاكتشاف في القاعدة الموصى بها: يغطي في نفس الوقت أحداث socket (مسار استدعاء النظام، باستخدام مطابقة السلسلة evt.args contains AF_ALG لتجاوز قيود نوع ENUMFLAGS32) وأحداث krsi_socket (مسار io_uring، باستخدام مقارنة الأعداد الصحيحة krsi.domain = 38). لا عتبات عد (تُهزم بإعادة استخدام المقبس)، ولا اعتماد على ارتباط PID (يُهزم بالتقسيم متعدد العمليات).
ملاحظة: طبقات الدفاع الثلاث في قاعدة ThreatBear المجتمعية كلها قابلة للتجاوز — عدم تطابق نوع ENUMFLAGS32 (evt.arg[0]=38 دائمًا خاطئ)، إعادة استخدام المقبس تهزم عتبة العد (count=1 < 40)، التقسيم متعدد العمليات يكسر ارتباط PID. انظر تحليل تجاوز القاعدة.
يعتمد Wazuh بالكامل على أحداث تدقيق استدعاءات النظام في auditd. عمليات io_uring لا تمر عبر دخول استدعاء النظام، لذا ينتج auditd صفر أحداث وتفشل جميع قواعد Wazuh السبع. الأمر نفسه ينطبق على Elastic Security Agent — المنتجات المعتمدة على دخول استدعاء النظام عمياء هيكليًا تجاه مسار io_uring. انظر تحليل قيود Wazuh.
يحتوي دليل bypass_demo/ على أوصاف مفاهيمية لنهج تجاوز الاكتشاف. كود الـ PoC الفعلي للاستخدام الداخلي فقط ولا يتم توزيعه علنًا.
| المستند | المحتوى |
|---|---|
| VULNERABILITY.md |
| المستند | المحتوى |
|---|---|
| defense/HARDENING.md | نموذج دفاع من 3 طبقات: إعداد النواة → seccomp → مساحات أسماء المستخدمين؛ تحليل أمان Docker 29.4.2 |
| المنتج | طبقة الاكتشاف | استدعاء النظام التقليدي | مسار io_uring | التقسيم متعدد العمليات | إعادة استخدام المقبس | التقييم |
|---|
| Tetragon (kprobe) | دالة النواة | ✅ | ✅ | ✅ | ✅ | التغطية الكاملة الوحيدة للسلسلة |
| Falco + إضافة krsi | fexit/fentry | ✅ | ✅ | ✅ | ✅ | يتطلب krsi لـ io_uring؛ دخول فقط |
| Falco (modern_ebpf) | tracepoint استدعاء النظام | ✅ | ❌ | ✅ | ✅ | io_uring غير مرئي تمامًا |
| auditd / Wazuh | تدقيق استدعاء النظام | ✅ | ❌ | ❌ PID منكسر | ⚠️ | عمى io_uring + ارتباط PID منكسر |
| Elastic Security Agent | استدعاء النظام | ✅ | ❌ | ⚠️ | ⚠️ | نفس Wazuh؛ الاعتماد على استدعاء النظام = عمى |
| السبب الجذري — تراكب ثلاثة تغييرات في النواة، سلسلة هجوم من 9 خطوات، خصائص كتابة ذاكرة التخزين المؤقت للصفحات |
| EXPLOIT_VARIANTS.md | 6 أبعاد لمتغيرات الاستغلال — مسار الإدخال/الإخراج × إرسال البيانات × الملف المستهدف × خوارزمية AEAD × تقسيم العمليات × إعادة استخدام المقبس |
| DETECTION_THEORY.md | نظرية الاكتشاف — نقاط التقارب مقابل نقاط الاختلاف، بنية اكتشاف من 4 طبقات، ارتباط زمني متعدد الإشارات |
| المستند | المحتوى |
|---|
| detection/tetragon.md | موصى به — Tetragon kprobe، 5 مجسات تغطي التقليدي + io_uring، الاكتشاف الكامل الوحيد للسلسلة |
| detection/falco.md | دليل إعداد Falco 0.40.0 + krsi 0.1.0، تفاصيل krsi الداخلية، استكشاف الأخطاء وإصلاحها |
| detection/wazuh.md | Wazuh + auditd ثلاثة قيود رئيسية: عمى io_uring، انهيار ارتباط PID، عدم رؤية ذاكرة التخزين المؤقت للصفحات |
| detection/rule_bypass.md | مبادئ تجاوز قاعدة ThreatBear، التحقق التجريبي المضاد للتجاوز للقاعدة الموصى بها |