تخفيف SCTPhantom لـ Yandex Managed Kubernetes

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

وصف الثغرة

معرّف CVE (CVE ID): CVE-2026-64564

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

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

كتابة تقنية (write-up) (Tencent Zhuque Lab / Corvus AI): https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564
PoC عام (LPE على Debian 13، النواة 6.12.95): https://github.com/ethanolgolf/CVE-2026-64564
إصلاح Upstream (mainline): commit 9b2854f86f0b في net/sctp/sm_make_chunk.c

وصف مختصر:

SCTPhantom هي ثغرة use-after-free في نظام SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) في نواة Linux، تتيح لمستخدم محلي غير مميز الحصول على صلاحيات المستخدم الخارق (root).

السبب الجذري هو تباين الهويات عند معالجة chunk من نوع ASCONF: يتم التحقق من عملية DEL-IP مقابل عنوان مصدر حزمة IPv4 (S)، بينما تستخدم المعالجة اللاحقة transport المحدد عبر Address Parameter (L). ونتيجة لذلك، فإن التسلسل المرتب

[ Address Parameter L ] [ DEL-IP L ] [ DEL-IP 0.0.0.0 ]

يجتاز التحقق ويحذف transport(L)، وبعد ذلك تعيد عملية wildcard DEL-IP 0.0.0.0 استخدام المؤشر المحرر بالفعل كـ«مسار محفوظ». ونتيجة لذلك، يظل asoc->peer.primary_path وasoc->peer.active_path مؤشرين معلّقين إلى struct sctp_transport المحرر، ويقوم استدعاء getsockopt(SCTP_STATUS) اللاحق بإلغاء الإشارة إليهما.

أُدخل المنطق القابل للاستغلال في Linux 2.6.25 (عام 2007، commit 42e30bf3463c)، أي أنه موجود في النواة منذ حوالي 18 عامًا.

الهجوم:

لا يتطلب وصولًا عن بُعد - فقط حساب محلي غير مميز
لا يتطلب CAP_NET_ADMIN أو CAP_SYS_ADMIN، ويعمل مع تفعيل ملف seccomp الافتراضي؛ يتم تمكين ASCONF وAUTH لكل socket عبر SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED، لذلك لا حاجة لتغيير sysctl net.sctp.addip_enable
يُعد بدائية هروب عملية من الحاوية إلى المضيف: حصل المؤلفون على صلاحيات root على المضيف في 6 من 8 محاولات، والخطوة الأخيرة هي call_usermodehelper_exec() التي تشغّل عملية في مساحات الأسماء الأولية للمضيف
عند فشل الاستغلال، ينتهي «بنظافة» دون kernel panic، مما يصعّب الاكتشاف
سلسلة الاستغلال تعيد استخدام كود النواة الموجود (data-oriented commit_creds())، دون shellcode أو ROP تقليدي

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

نواة Linux، النظام الفرعي net/sctp (الوحدة sctp)، معالجة ASCONF في net/sctp/sm_make_chunk.c
الوحدة sctp_diag (تعتمد على sctp)، تُستخدم لفحص SCTP sockets

يمكن استغلال الثغرة فقط عند توفر SCTP: إذا لم تكن الوحدة sctp محمّلة وتم حظر تحميلها التلقائي، يكون المتجه غير متاح.

الأهداف المؤكدة من قبل المؤلفين (تم الحصول على root):

التوزيعة	النواة
Research kernel	Linux 7.2-rc2
OpenCloudOS-family	6.6.119
Debian 13	6.12.95+deb13-amd64
Rocky Linux 9 / RHEL 9	5.14 vendor kernel (عند تحميل الوحدة `sctp`)
Ubuntu 24.04	6.8.0-134-generic

إصدارات النواة المصححة:

الفرع	أول إصدار مصحح	إصلاح Stable
6.6.y	6.6.148	`fedeb4468987`
6.12.y	6.12.101	`74e8f3e7114f`
6.18.y	6.18.42	`85aca407c560`
7.1.y	7.1.6	`d136b29bf91d`
mainline	7.2-rc5	`9b2854f86f0b`

قد تحتوي نواة البائعين على backport للإصلاح مع إصدار أقدم في سطر الإصدار - إصدار النواة بحد ذاته ليس مؤشرًا كافيًا على الثغرة، اعتمد على advisory أو على مصادر البائع.

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

التقييم الأساسي: 8.5 (HIGH)

المتجه: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

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

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

يفحص حالة الوحدات - يتحقق مما إذا كانت sctp وsctp_diag محمّلتين، وما هو refcnt الخاص بهما. الفحص سلبي عمدًا: لا يفتح DaemonSet أي SCTP socket قبل تطبيق القائمة السوداء، حتى لا يستدعي التحميل التلقائي للوحدة على عقدة لم تُحمَّل فيها الوحدة بعد
يتحقق مما إذا كان SCTP مستخدمًا على العقدة - يحلل refcnt للوحدة والسجلات النشطة في /proc/net/sctp/assocs و/proc/net/sctp/eps. لا يستخدم Kubernetes نفسه SCTP، لكن يمكن أن تُعلن الأحمال التشغيلية للمستخدم protocol: SCTP في Service/Pod
يحظر الوحدات القابلة للاستغلال - ينشئ /etc/modprobe.d/blacklist-sctp.conf بقواعد install وblacklist لكل من sctp وsctp_diag
يفرغ الوحدات - ينفذ rmmod لـ sctp_diag ثم sctp (الترتيب مهم: sctp_diag تعتمد على sctp). إذا تم اكتشاف اتصالات SCTP نشطة، يتم تخطي التفريغ ما لم يتم تعيين FORCE_APPLY=true صراحةً
يتحقق من التخفيف - يتحقق من وجود الإعداد، وأن modprobe sctp مرفوض، وأن إنشاء SCTP socket (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) لم يعد ينجح
يراقب الحالة - يتحقق كل ساعة من وجود الإعداد، ويعيد إنشاءه إذا اختفى، ويعيد تفريغ الوحدات إذا تبيّن أنها حُمّلت مرة أخرى

مهم: نتيجتان محتملتان على العقدة

يتكون التخفيف من جزأين مستقلين، وعلى بعض العقد يُطبَّق جزء واحد فقط.

1. القائمة السوداء (تُطبَّق دائمًا وبشكل موثوق). بعد إنشاء /etc/modprobe.d/blacklist-sctp.conf، لا يمكن تحميل الوحدة sctp بعد الآن - لا تلقائيًا عند socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP) ولا عبر modprobe صريح. هذا يغلق المتجه على العقد التي لم تكن الوحدة محمّلة عليها (الحالة النموذجية: SCTP غير مستخدم من قبل Kubernetes ويُحمَّل فقط عند الطلب).

2. تفريغ الوحدة من الذاكرة (ليس ممكنًا دائمًا). إذا كانت sctp محمّلة بالفعل، فغالبًا لن تنجح محاولة تفريغها. على عقد Yandex Managed Kubernetes المختبرة (Ubuntu 22.04، النواة 5.15.0-181-generic)، فإن الوحدة sctp المحمّلة حديثًا وغير المستخدمة من قبل أي أحد لديها بالفعل refcnt=6 مع قائمة holders فارغة وملفّي /proc/net/sctp/{assocs,eps} فارغين، ويعيد rmmod الخطأ ERROR: Module sctp is in use. لا ينخفض العداد بمرور الوقت.

من هنا نتيجتان:

refcnt ليس مؤشرًا على استخدام SCTP - يعرضه DaemonSet لأغراض إعلامية فقط، ويتخذ قرار التفريغ بناءً على السجلات النشطة في /proc/net/sctp/assocs و/proc/net/sctp/eps
على العقدة التي تكون فيها sctp مقيمة بالفعل، يبلغ DaemonSet بصدق ⚠ mitigation applied PARTIALLY. القائمة السوداء موجودة هناك بالفعل (بعد إعادة التشغيل لن تعود الوحدة)، لكن العقدة تظل عرضة للخطر حتى إعادة التشغيل. لإغلاق المتجه تمامًا، يجب إعادة تشغيل هذه العقد أو إعادة إنشاء node group

للعثور على هذه العقد بعد التوزيع:

kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix --prefix | grep -E 'PARTIALLY|STILL LOADED'

التوافق مع الأحمال التشغيلية

مهم: يوقف التخفيف SCTP تمامًا على العقدة.

لا يستخدم Kubernetes والمكونات الإضافية للشبكات (Cilium, Calico) SCTP في عملها الخاص، لذلك فإن التخفيف آمن بالنسبة للغالبية العظمى من المجموعات. لكن إذا كانت هناك أحمال تشغيلية في المجموعة تستخدم SCTP (مثل تطبيقات الاتصالات، VoIP / إشارات SS7/Diameter، Service أو NetworkPolicy مع protocol: SCTP)، فسيتوقف مرور البيانات الخاص بها عن العمل.

للتحقق من وجود مثل هذه الكائنات في المجموعة قبل التوزيع:

# Service / Pod с protocol: SCTP
kubectl get svc -A -o json | jq -r '.items[] | select(.spec.ports[]?.protocol=="SCTP") | "\(.metadata.namespace)/\(.metadata.name)"'
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[].ports[]?.protocol=="SCTP") | "\(.metadata.namespace)/\(.metadata.name)"'

# NetworkPolicy с protocol: SCTP
kubectl get netpol -A -o json | jq -r '.items[] | select((.spec.ingress[]?.ports[]?.protocol=="SCTP") or (.spec.egress[]?.ports[]?.protocol=="SCTP")) | "\(.metadata.namespace)/\(.metadata.name)"'

إذا كان SCTP مستخدمًا على العقدة، فإن DaemonSet افتراضيًا لا يفرغ الوحدة من الذاكرة، بل يضع القائمة السوداء فقط (لن تعود الوحدة بعد إعادة تشغيل العقدة) ويكتب تحذيرًا في السجلات. لفرض التفريغ وقطع اتصالات SCTP الموجودة، عيّن في المانيفست:

        env:
        - name: FORCE_APPLY
          value: "true"

بدء سريع

1. تنزيل DaemonSet

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

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

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

yc-mk8s-sctphantom-mitigation

الأكثر شعبية