SCTPhantom Mitigation for Yandex Managed Kubernetes

Yandex Managed Kubernetes क्लस्टर की सभी worker-नोड्स पर Linux कर्नेल में CVE-2026-64564 (SCTPhantom) भेद्यता के लिए मिटिगेशन का स्वचालित अनुप्रयोग।

भेद्यता का विवरण

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 (Debian 13, कर्नेल 6.12.95 पर LPE): https://github.com/ethanolgolf/CVE-2026-64564
• Upstream-फिक्स (mainline): commit 9b2854f86f0b net/sctp/sm_make_chunk.c में

संक्षिप्त विवरण:

SCTPhantom Linux कर्नेल की SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) उपप्रणाली में एक use-after-free है, जो एक अन-विशेषाधिकार प्राप्त स्थानीय उपयोगकर्ता को सुपरयूज़र (root) अधिकार प्राप्त करने की अनुमति देता है।

मूल कारण ASCONF-चंक की प्रोसेसिंग में पहचानों का विचलन है: DEL-IP ऑपरेशन की जाँच IPv4-पैकेट के स्रोत पते (S) के विरुद्ध की जाती है, जबकि आगे की प्रोसेसिंग Address Parameter (L) के माध्यम से चुने गए transport का उपयोग करती है। इसके कारण क्रमबद्ध अनुक्रम

[ 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 पर dangling पॉइंटर्स बने रहते हैं, और बाद में getsockopt(SCTP_STATUS) कॉल उन्हें dereference करता है।

यह भेद्य लॉजिक Linux 2.6.25 (वर्ष 2007, commit 42e30bf3463c) में जोड़ा गया था, यानी यह लगभग 18 वर्षों से कर्नेल में मौजूद है।

हमला:

• दूरस्थ पहुँच की आवश्यकता नहीं - केवल एक अन-विशेषाधिकार प्राप्त स्थानीय खाता
• CAP_NET_ADMIN और CAP_SYS_ADMIN की आवश्यकता नहीं, सक्रिय default seccomp-प्रोफाइल के साथ काम करता है; ASCONF और AUTH per-socket SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED के माध्यम से सक्षम किए जाते हैं, इसलिए sysctl net.sctp.addip_enable बदलने की आवश्यकता नहीं है
• कंटेनर से होस्ट पर भागने का कार्यशील प्रिमिटिव है: लेखकों ने 8 में से 6 प्रयासों में host-root प्राप्त किया; अंतिम चरण - call_usermodehelper_exec() है, जो होस्ट के initial namespaces में एक प्रक्रिया चलाता है
• असफल शोषण पर kernel panic के बिना «स्वच्छ» रूप से समाप्त होता है, जिससे पहचान कठिन हो जाती है
• exploit-श्रृंखला मौजूदा कर्नेल कोड (data-oriented commit_creds()) का पुनः उपयोग करती है, बिना shellcode और क्लासिकल ROP के

प्रभावित तकनीकें:

• Linux कर्नेल, net/sctp उपप्रणाली (मॉड्यूल sctp), net/sctp/sm_make_chunk.c में ASCONF प्रोसेसिंग
• मॉड्यूल sctp_diag (sctp पर निर्भर करता है), SCTP-सॉकेट्स के निरीक्षण के लिए उपयोग किया जाता है

यह भेद्यता केवल SCTP उपलब्ध होने पर ही शोषणीय है: यदि मॉड्यूल sctp लोड नहीं है और उसकी ऑटो-लोडिंग अवरुद्ध है, तो वेक्टर उपलब्ध नहीं है।

लेखकों द्वारा पुष्टि किए गए लक्ष्य (root प्राप्त):

सुधारित कर्नेल संस्करण:

वेंडर कर्नेल में संस्करण स्ट्रिंग में पुराने संस्करण के साथ फिक्स का बैकपोर्ट हो सकता है - कर्नेल का संस्करण स्वयं भेद्यता का पर्याप्त संकेत नहीं है; वेंडर के 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 क्लस्टर के प्रत्येक worker नोड पर स्वचालित रूप से:

1. मॉड्यूल्स की स्थिति जाँचता है - देखता है कि sctp और sctp_diag लोड हैं या नहीं, और किस refcnt के साथ। यह जाँच जानबूझकर निष्क्रिय है: DaemonSet ब्लैकलिस्ट सेट करने से पहले SCTP-सॉकेट नहीं खोलता, ताकि जिस नोड पर मॉड्यूल अभी लोड नहीं है, वहाँ उसकी ऑटो-लोडिंग न भड़के
2. जाँचता है कि नोड पर SCTP उपयोग में है या नहीं - मॉड्यूल के refcnt और /proc/net/sctp/assocs तथा /proc/net/sctp/eps में सक्रिय प्रविष्टियों का विश्लेषण करता है। Kubernetes स्वयं SCTP का उपयोग नहीं करता, लेकिन उपयोगकर्ता वर्कलोड Service/Pod में protocol: SCTP घोषित कर सकता है
3. भेद्य मॉड्यूल्स को ब्लॉक करता है - sctp और sctp_diag के लिए install और blacklist नियमों के साथ /etc/modprobe.d/blacklist-sctp.conf बनाता है

महत्वपूर्ण: नोड पर दो संभावित परिणाम

मिटिगेशन में दो स्वतंत्र भाग होते हैं, और कुछ नोड्स पर उनमें से केवल एक ही लागू होता है।

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 पहले से ही खाली holders सूची और खाली /proc/net/sctp/{assocs,eps} के साथ refcnt=6 रखता है, और rmmod ERROR: Module sctp is in use लौटाता है। काउंटर समय के साथ घटता नहीं है।

इससे दो निष्कर्ष निकलते हैं:

• refcnt SCTP के उपयोग का संकेत नहीं है - DaemonSet इसे केवल सूचनात्मक रूप से प्रदर्शित करता है, और अनलोडिंग का निर्णय /proc/net/sctp/assocs और /proc/net/sctp/eps में सक्रिय प्रविष्टियों के आधार पर लेता है
• जिस नोड पर sctp पहले से resident है, वहाँ 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, protocol: SCTP वाला Service या NetworkPolicy), तो उसका ट्रैफ़िक काम करना बंद कर देगा।

रोलआउट से पहले जाँचें कि क्या ऐसे ऑब्जेक्ट क्लस्टर में मौजूद हैं:

# 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

2. फिक्स लागू करें

kubectl apply -f sctphantom-mitigation-daemonset.yaml

3. फिक्स लागू होने की स्थिति जाँचें

# Проверить статус DaemonSet
kubectl get daemonset -n kube-system cve-2026-64564-fix

# Посмотреть на скольких нодах применен фикс
kubectl get pods -n kube-system -l app=cve-2026-64564-fix -o wide

4. फिक्स लागू करने के लॉग देखें

# Логи initContainer (применение фикса)
kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix

# Логи основного контейнера (мониторинг)
kubectl logs -n kube-system -l app=cve-2026-64564-fix -c monitor

5. ऐसे नोड्स ढूँढें जहाँ मिटिगेशन पूरी तरह लागू नहीं हुआ

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

सफल आवेदन का उदाहरण

=========================================
SCTPhantom (CVE-2026-64564) mitigation for Yandex Managed K8s
Node: demo-ru-central1-a-1
Date: Mon Aug 10 14:00:00 UTC 2026
FORCE_APPLY: false
=========================================

Step 1: Checking modules state before fix...
  [LOADED]   sctp (refcnt=0) - node is exposed
  [UNLOADED] sctp_diag

Step 2: Checking whether SCTP is in use on this node...
  ✓ No SCTP usage detected (expected: Kubernetes itself does not use SCTP)

Step 3: Applying the mitigation...
Created /etc/modprobe.d/blacklist-sctp.conf

Step 4: Unloading vulnerable modules...
  sctp_diag was not loaded (OK)
  sctp unloaded

Step 5: Validating the configuration...
Configuration file is in place:
install sctp /bin/false
install sctp_diag /bin/false
blacklist sctp
blacklist sctp_diag

Step 6: Validating that the modules can no longer be loaded...
  modprobe sctp_diag is blocked ✓
  modprobe sctp is blocked ✓
  SCTP socket creation is blocked ✓

Step 7: Validating modules state after fix...
  [UNLOADED] sctp_diag ✓
  [UNLOADED] sctp ✓

=========================================
✓ CVE-2026-64564 mitigation applied successfully
=========================================

आंशिक आवेदन का उदाहरण (मॉड्यूल पहले से लोड था)

Step 1: Checking modules state before fix...
  [UNLOADED] sctp_diag
  [LOADED]   sctp (refcnt=6) - node is exposed

Step 2: Checking whether SCTP is in use on this node...
  sctp is loaded, refcnt=6 (informational only)
  ✓ No SCTP usage detected (expected: Kubernetes itself does not use SCTP)

Step 4: Unloading vulnerable modules...
  sctp_diag was not loaded (OK)
  ⚠ could not unload sctp (see the note about refcnt below)

Step 6: Validating that the modules can no longer be loaded...
  modprobe sctp_diag is blocked ✓
  sctp is still resident, skipping the modprobe test
  ⚠ SCTP socket still available: the sctp module is still resident and could not be unloaded

Step 7: Validating modules state after fix...
  [UNLOADED] sctp_diag ✓
  [STILL LOADED] sctp (refcnt=6) - WARNING: module could not be unloaded

=========================================
⚠ CVE-2026-64564 mitigation applied PARTIALLY
  ...
  In that case reboot the node or recreate the node group to close the vector.
=========================================

ऐसे नोड को रीबूट करने की आवश्यकता है: ब्लैकलिस्ट अब मॉड्यूल को दोबारा लोड नहीं होने देगी।

पॉड से मिटिगेशन की प्रभावशीलता की जाँच

सबसे अधिक प्रदर्शक जाँच - हमलावर की स्थिति को पुनः उत्पन्न करना: कैपेबिलिटीज़ रीसेट किए हुए अन-विशेषाधिकार प्राप्त पॉड, जैसा कि container escape श्रृंखला में होता है।

NODE=<имя ноды>
kubectl run sctp-check --rm -i --restart=Never --image=python:3-slim \
  --overrides="{\"spec\":{\"nodeName\":\"$NODE\",\"containers\":[{\"name\":\"c\",\"image\":\"python:3-slim\",\"securityContext\":{\"allowPrivilegeEscalation\":false,\"capabilities\":{\"drop\":[\"ALL\"]}},\"command\":[\"python3\",\"-c\",\"import socket\ntry:\n    socket.socket(socket.AF_INET, socket.SOCK_STREAM, 132).close()\n    print('SCTP REACHABLE -> EXPLOITABLE')\nexcept OSError as e:\n    print('SCTP BLOCKED:', e)\"]}]}}"

सुरक्षित नोड पर अपेक्षित आउटपुट:

SCTP BLOCKED: [Errno 93] Protocol not supported

असुरक्षित नोड पर आउटपुट SCTP REACHABLE -> EXPLOITABLE होगा, और यह जाँच स्वयं उस नोड पर मॉड्यूल sctp की ऑटो-लोडिंग का कारण बनेगी (जिसके बाद उसे अनलोड करना संभवतः संभव नहीं होगा - ऊपर अनुभाग देखें)। इसे बिना आवश्यकता के असुरक्षित नोड्स पर न चलाएँ।

भेद्यता की मैन्युअल जाँच

आप नोड की स्थिति मैन्युअल रूप से जाँच सकते हैं। SSH के माध्यम से नोड से जुड़ें और निम्नलिखित निष्पादित करें:

# Загружены ли уязвимые модули
lsmod | grep -E '^sctp'
# sctp  447488  0     <- refcount 0, можно выгружать

# Доступен ли SCTP-сокет (основной вектор автозагрузки модуля)
python3 -c 'import socket; socket.socket(socket.AF_INET, socket.SOCK_STREAM, 132); print("SCTP available - VULNERABLE")'

# Если выводит "SCTP available - VULNERABLE" - система уязвима
# Если выдает ошибку - система защищена

ध्यान दें: जिस नोड पर मॉड्यूल अभी तक लोड नहीं है, वहाँ इस जाँच को चलाना स्वयं उसकी ऑटो-लोडिंग का कारण बनेगा। इसे केवल मिटिगेशन लागू करने के बाद या जानबूझकर ही निष्पादित करें।

कॉन्फ़िगरेशन जाँचें:

# Проверить наличие конфигурации блокировки
cat /etc/modprobe.d/blacklist-sctp.conf

# Ожидаемый вывод:
# install sctp /bin/false
# install sctp_diag /bin/false
# blacklist sctp
# blacklist sctp_diag

जाँचें कि भेद्य मॉड्यूल लोड नहीं हैं:

lsmod | grep -cE '^sctp'
# Ожидаемый вывод: 0

Kubernetes के बाहर आवेदन

यदि सामान्य होस्ट्स पर मिटिगेशन लागू करने की आवश्यकता हो, तो वन-लाइनर:

sudo sh -c 'printf "install sctp /bin/false\ninstall sctp_diag /bin/false\nblacklist sctp\nblacklist sctp_diag\n" > /etc/modprobe.d/blacklist-sctp.conf; rmmod sctp_diag 2>/dev/null; rmmod sctp 2>/dev/null; if lsmod | grep -qE "^sctp "; then echo "STILL-LOADED refcnt=$(cat /sys/module/sctp/refcnt)"; else echo "UNLOADED-OK"; fi'

फिक्स हटाना

यदि DaemonSet हटाना आवश्यक हो:

kubectl delete -f sctphantom-mitigation-daemonset.yaml

महत्वपूर्ण: DaemonSet को हटाने से नोड्स से कॉन्फ़िगरेशन फ़ाइलें नहीं हटेंगी। फ़ाइल /etc/modprobe.d/blacklist-sctp.conf अपने स्थान पर बनी रहेगी और सिस्टम की सुरक्षा जारी रखेगी।

नोड्स से फिक्स को पूरी तरह हटाने के लिए प्रत्येक नोड से SSH द्वारा जुड़कर फ़ाइल को मैन्युअल रूप से हटाना होगा:

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

तकनीकी विवरण

प्रयुक्त अनुमतियाँ:

• hostPID: true - nsenter के माध्यम से होस्ट प्रक्रियाओं तक पहुँच के लिए
• privileged: true - /etc में लिखने और कर्नेल मॉड्यूल्स को अनलोड करने के लिए
• Volume mount / - होस्ट फ़ाइल सिस्टम तक पहुँच के लिए

इमेज: ubuntu:22.04

संसाधन:

• Init container: 10m CPU / 64Mi RAM (requests), 200m CPU / 128Mi RAM (limits)
• Monitor container: 5m CPU / 32Mi RAM (requests), 50m CPU / 64Mi RAM (limits)

Namespace: kube-system

कॉन्फ़िग में install और blacklist दोनों क्यों: blacklist alias के आधार पर लोडिंग को ब्लॉक करता है (जिसमें socket(..., IPPROTO_SCTP) पर ऑटो-लोडिंग भी शामिल है), लेकिन स्पष्ट modprobe sctp को नहीं रोकता। पंक्ति install sctp /bin/false उस मार्ग को भी बंद कर देती है।

मिटिगेशन कर्नेल अपडेट का विकल्प क्यों नहीं है: मॉड्यूल को ब्लॉक करने से वेक्टर समाप्त हो जाता है, लेकिन बग स्वयं कर्नेल में रहता है। स्थायी समाधान - कर्नेल को सुधारित संस्करण में अपडेट करना (ऊपर दी गई तालिका देखें) या नोड इमेज को अपडेट करके node group को पुनः बनाना है।

संगतता

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

लाइसेंस

Apache License 2.0

विवरण के लिए LICENSE देखें।

सहायता

समस्याओं के मामले में रिपॉजिटरी में issue बनाएँ।