تخفيف Copy Fail / Dirty Frag لـ Yandex Managed Kubernetes

تطبيق تلقائي للتخفيف من الثغرات CVE-2026-31431 و CVE-2026-43284 و CVE-2026-43500 في نواة Linux على جميع عقد العامل (worker-nodes) في كتلة Yandex Managed Kubernetes.

وصف الثغرة

معرف CVE (CVE ID): CVE-2026-43284، CVE-2026-43500

رابط CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-43284

التقرير الأصلي:

• Dirty Frag (PoC و write-up): https://github.com/V4bel/dirtyfrag
• Copy Fail 2: Electric Boogaloo (PoC xfrm-ESP): https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo
• القائمة البريدية oss-security: https://www.openwall.com/lists/oss-security/2026/05/07/8

وصف مختصر:

Dirty Frag هي فئة من الثغرات المنطقية في نواة Linux تسمح لمستخدم محلي غير مميز بالحصول على صلاحيات المستخدم الفائق (root). يجمع الاستغلال بين بدائي كتابة مستقلين في page-cache في النظامين الفرعيين xfrm-ESP و RxRPC، كل منهما مكتفٍ ذاتيًا لرفع الصلاحيات.

Copy Fail 2: Electric Boogaloo هو PoC مستقل يستغل بدائي xfrm-ESP (CVE-2026-43284). من حيث فئة الثغرة، فهو مشابه لـ Copy Fail الأصلي (CVE-2026-31431)، لذلك يحتفظ هذا DaemonSet بالتخفيف لكل من سيناريو AF_ALG الأصلي والأنواع الجديدة من Dirty Frag.

الهجوم:

• لا يتطلب وصولًا عن بُعد - فقط حساب محلي غير مميز
• هو خطأ منطقي حتمي بدون حالة سباق (race condition) - ينجح من المحاولة الأولى
• لا يؤدي إلى kernel panic عند فشل الاستغلال
• يمكن استخدامه كبدائي للهروب من الحاوية إلى المضيف، لأن page cache مشترك للعقدة بأكملها

السبب الجذري لكلا النوعين واحد: عند استخدام splice() / MSG_SPLICE_PAGES، تضع النواة صفحات page cache مباشرة في أجزاء مخازن المقابس (skb). يقوم النظامان الفرعيان xfrm-ESP و RxRPC بفك التشفير في المكان (in-place) على هذه الأجزاء دون التحقق مما إذا كانت خاصة. ونتيجة لذلك، يحصل المهاجم على كتابة مُتحكم بها في page cache لأي ملف قابل للقراءة.

التقنيات المتأثرة:

• نواة Linux، النظام الفرعي net/ipv4/esp4.c / net/ipv6/esp6.c (xfrm-ESP)
• نواة Linux، النظام الفرعي net/rxrpc/rxkad.c (RxRPC / RxKAD)
• استدعاءات النظام splice() / vmsplice() مع مقابس UDP (ESP-in-UDP) و AF_RXRPC
• يتم الاحتفاظ بشكل منفصل بتخفيف Copy Fail الأصلي (CVE-2026-31431) عبر حظر AF_ALG (algif_aead)

لا تؤثر الثغرة مباشرة على AF_ALG (algif_aead) كجزء من Dirty Frag - فهذه ثغرة منفصلة Copy Fail (CVE-2026-31431). كما لا تتأثر مباشرة dm-crypt / LUKS و kTLS و in-kernel TLS و IPsec في وضع tunnel بدون تغليف UDP.

ناقل الهجوم ومستوى الخطورة وفقًا لـ CVSS v.3.1:

التقييم الأساسي: لم يُخصص وقت النشر.

من حيث الطبيعة، الثغرة مشابهة لـ Copy Fail (CVE-2026-31431، 7.8 HIGH، CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) - وهي رفع صلاحيات محلي بدون حالة سباق.

ما يفعله هذا الإصلاح

يقوم DaemonSet تلقائيًا على كل عقدة عامل في الكتلة بما يلي:

1. التحقق من توفر AF_ALG - ينفذ اختبارًا سريعًا لسيناريو Copy Fail الأصلي
2. حظر الوحدات الضعيفة - ينشئ /etc/modprobe.d/blacklist-lpe.conf بقواعد لـ algif_aead و esp4 و esp6 و rxrpc
3. تفريغ الوحدات - ينفذ rmmod لـ algif_aead و esp4 و esp6 و rxrpc إذا كانت محملة
4. مسح page cache والتحقق من الإعداد - يمسح المخازن المؤقتة ويتحقق من وجود ملف الإعداد
5. مراقبة الحالة - يتحقق كل ساعة من وجود الإعداد ويعيد تفريغ الوحدات عند الحاجة

بدء سريع

1. تنزيل DaemonSet

wget https://raw.githubusercontent.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation/main/copy-fail-mitigation-daemonset.yaml

أو استنساخ المستودع:

git clone https://github.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation.git
cd yc-mk8s-copy-fail-mitigation

2. تطبيق الإصلاح

kubectl apply -f copy-fail-mitigation-daemonset.yaml

3. التحقق من حالة التطبيق

# التحقق من حالة DaemonSet
kubectl get daemonset -n kube-system cve-2026-31431-fix

# معرفة على عدد العقد تم تطبيق الإصلاح
kubectl get pods -n kube-system -l app=cve-2026-31431-fix -o wide

4. عرض سجلات تطبيق الإصلاح

# سجلات initContainer (تطبيق الإصلاح)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c apply-fix

# سجلات الحاوية الرئيسية (المراقبة)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c monitor

مثال على تطبيق ناجح

=========================================
Copy Fail / Dirty Frag mitigation for Yandex Managed K8s
Node: demo-ru-central1-a-1
Date: Thu May 08 14:00:00 UTC 2026
=========================================

Step 1: Checking vulnerability before fix...
❌ System is VULNERABLE - AF_ALG AEAD interface is accessible

Step 2: Creating modprobe configuration...
✓ Created /etc/modprobe.d/blacklist-lpe.conf

Step 3: Unloading vulnerable modules...
  ✓ algif_aead unloaded
  ✓ esp4 not loaded
  ✓ esp6 not loaded
  ✓ rxrpc not loaded

Step 3.5: Dropping system caches...
✓ System caches cleared

Step 4: Verifying the fix...
✓ Configuration file exists:
install algif_aead /bin/false
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Step 5: Testing if vulnerability is fixed...
✓ AF_ALG AEAD interface is properly blocked

=========================================
✓ Mitigation applied successfully
=========================================

التحقق من الثغرة يدويًا

يمكنك التحقق من وجود الثغرة على العقدة يدويًا. اتصل بالعقدة عبر SSH ونفذ:

# التحقق من توفر سيناريو Copy Fail الأصلي عبر AF_ALG
python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("AF_ALG AEAD available - VULNERABLE")'

# إذا أظهر "AF_ALG AEAD available - VULNERABLE" - النظام ضعيف
# إذا أظهر خطأ - النظام محمي

التحقق من الإعداد:

# التحقق من وجود إعداد الحظر
cat /etc/modprobe.d/blacklist-lpe.conf

# الإخراج المتوقع:
# install algif_aead /bin/false
# install esp4 /bin/false
# install esp6 /bin/false
# install rxrpc /bin/false

التحقق من عدم تحميل الوحدات الضعيفة:

lsmod | egrep 'algif_aead|esp4|esp6|rxrpc'

إزالة الإصلاح

إذا كان من الضروري حذف DaemonSet:

kubectl delete -f copy-fail-mitigation-daemonset.yaml

مهم: حذف DaemonSet لن يحذف ملفات الإعداد من العقد. سيبقى الملف /etc/modprobe.d/blacklist-lpe.conf في مكانه وسيستمر في حماية النظام.

لإزالة الإصلاح بالكامل من العقد، يجب الاتصال بكل عقدة عبر SSH وحذف الملف يدويًا:

rm /etc/modprobe.d/blacklist-lpe.conf

تفاصيل تقنية

الصلاحيات المستخدمة:

• hostPID: true - للوصول إلى عمليات المضيف عبر nsenter
• privileged: true - للكتابة في /etc وتفريغ وحدات النواة
• Volume mount / - للوصول إلى نظام ملفات المضيف

الصورة: ubuntu:22.04

الموارد:

• حاوية init: 10m CPU / 64Mi RAM (requests)، 200m CPU / 128Mi RAM (limits)
• حاوية المراقبة: 5m CPU / 32Mi RAM (requests)، 50m CPU / 64Mi RAM (limits)

Namespace: kube-system

التوافق

• ✓ Yandex Managed Kubernetes
• ✓ Ubuntu 20.04
• ✓ Ubuntu 22.04
• ✓ Kubernetes 1.20+

الترخيص

Apache License 2.0

انظر LICENSE للتفاصيل.

الدعم

في حالة وجود مشاكل، أنشئ issue في المستودع.