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 प्राप्त):

डिस्ट्रिब्यूशन	कर्नेल
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

वेंडर कर्नेल में संस्करण स्ट्रिंग में पुराने संस्करण के साथ फिक्स का बैकपोर्ट हो सकता है - कर्नेल का संस्करण स्वयं भेद्यता का पर्याप्त संकेत नहीं है; वेंडर के 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 बनाता है
4. मॉड्यूल्स को अनलोड करता है - पहले sctp_diag के लिए rmmod निष्पादित करता है, फिर sctp (क्रम महत्वपूर्ण है: sctp_diag, sctp पर निर्भर है)। यदि सक्रिय SCTP-कनेक्शन पाए जाते हैं, तो अनलोडिंग छोड़ दी जाती है, जब तक कि FORCE_APPLY=true स्पष्ट रूप से सेट न हो
5. मिटिगेशन को सत्यापित करता है - जाँच करता है कि कॉन्फ़िगरेशन मौजूद है, modprobe sctp अस्वीकार होता है, और SCTP-सॉकेट बनाना (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) अब काम नहीं करता
6. स्थिति की निगरानी करता है - हर घंटे कॉन्फ़िगरेशन की उपस्थिति की जाँच करता है, गायब होने पर उसे पुनर्स्थापित करता है, और यदि मॉड्यूल फिर से लोड हो जाएँ तो उन्हें पुनः अनलोड करता है

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

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

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)"'