Citrix NetScaler SAML PrefixList हीप ओवरफ्लो — पैच-स्थिति पहचान स्क्रिप्ट

CVE-2026-8452 के लिए एक सुरक्षित, गैर-विनाशकारी पैच-स्थिति जाँच, जो प्रमाणीकरण-पूर्व हीप ओवरफ्लो है Citrix NetScaler ADC / NetScaler Gateway SAML सिग्नेचर कैननिकलाइज़र में (CTX696604, CVSS 8.8). एक अत्यधिक बड़ा एक्सक्लूसिव-कैननिकलाइज़ेशन PrefixList निश्चित-आकार के बफर को ओवरफ्लो कर देता है कैननिकलाइज़ेशन के दौरान, जिसे NetScaler सिग्नेचर की पुष्टि करने से पहले करता है जो इसे ले जाता है — इसलिए पूरा पथ बिना क्रेडेंशियल, बिना सत्र, और बिना मान्य हस्ताक्षर के पहुँच योग्य है। रिपोर्ट माइकल टकर (JPMorgan Chase XOR टीम) द्वारा; मूल-कारण और शोषण विश्लेषण का श्रेय watchTowr Labs को जाता है।

यह स्क्रिप्ट बग का नहीं शोषण करती और मेमोरी को दूषित नहीं करती। यह प्रति लक्ष्य एक प्रश्न का उत्तर देती है: क्या यह उपकरण पैच किया गया है? — व्यवहारिक रूप से निर्धारित, पैच का अवलोकन करके बिल्ड का अनुमान लगाने के बजाय।

क्या इसे चलाना सुरक्षित है?

हाँ। इसे प्रोडक्शन और मूल्यांकन उपयोग के लिए डिज़ाइन किया गया है:

• प्रोब भ्रष्टाचार सीमा से नीचे रहता है। 575 बाइट्स इतने लंबे हैं कि पैच किए गए और बिना पैच वाले बिल्ड अलग-अलग उत्तर देते हैं, और यह उस लंबाई से काफी नीचे है जहाँ बिना पैच वाले उपकरण का मेमोरी भ्रष्टाचार शुरू होता है। दोनों समर्थित शाखाओं और दोनों पैच स्थितियों पर फैले उपकरणों पर मापन द्वारा सत्यापित किया गया, जिसमें दोनों फिक्स बिल्ड भी शामिल हैं।
• यह जिस सीमा को पार करता है वह एक निश्चित कोड स्थिरांक है, न कि किसी एक परिनियोजन की संपत्ति। फिक्स बिल्ड एक PrefixList को 512 बाइट्स के लिए स्वीकार करते हैं और 513 या अधिक को अस्वीकार करते हैं। यह सीमा बाइट-दर-बाइट स्थित थी, दोनों समर्थित शाखाओं पर समान है, और उपकरण के कॉन्फ़िगरेशन या आस-पास के SAML संदेश के आकार के साथ नहीं बदलती — दोनों रूटों की जाँच से पुष्टि हुई, जो मान को काफी भिन्न मात्रा में XML में लपेटते हैं, और यह पाते हैं कि वे समान बाइट पर व्यवहार बदलते हैं। 575 सीमा को 63 बाइट्स से पार करता है, इसलिए निर्णय इस पर निर्भर नहीं करता कि कोई लक्ष्य किस तरह कॉन्फ़िगर किया गया है।
• पैचिंग से उपकरण सामान्य रूप से लंबे SAML मानों को अस्वीकार नहीं करते। यह सीमा केवल PrefixList विशेषता पर लागू होती है। अन्य फ़ील्डों को इससे अधिक बढ़ाना — एसर्शन कंज्यूमर सर्विस URL, जारीकर्ता नाम, एल्गोरिदम पहचानकर्ता, डाइजेस्ट और सिग्नेचर मान — एक फिक्स बिल्ड पर कुछ भी नहीं बदलते, इसलिए फिक्स लागू करने से कार्यशील SAML कॉन्फ़िगरेशन विफल नहीं होना चाहिए।
• कोई मेमोरी दूषित नहीं होती और कोई प्रक्रिया पुनः प्रारंभ नहीं होती। पैच किए गए बिल्ड पर प्रोब को आकार जाँच पर अस्वीकार कर दिया जाता है; बिना पैच वाले बिल्ड पर यह पार्सर के भीतर हानिरहित रूप से विफल हो जाता है। कोई भी ओवरफ्लो तक नहीं पहुँचता।
• स्कैन आउटपुट में कुछ भी संवेदनशील नहीं जाता। प्रोब केवल सिंथेटिक नेमस्पेस-प्रीफिक्स टोकन ले जाता है, और उपकरण निर्णय की रिपोर्ट करता है, प्रतिक्रिया निकायों की नहीं।
• दो निश्चित लंबाई, कभी स्वीप नहीं। 575-बाइट प्रोब, साथ ही उस रूट पर 35-बाइट नियंत्रण जो उत्तर देता है। उपकरण कभी भी लंबाई की सीमा को स्वीप नहीं करता और कभी कोई अन्य लंबाई नहीं भेजता।

यदि आप प्रोब को संशोधित करते हैं, तो PROBE_PREFIXES न बदलें और लंबाई स्वीप न करें। 575 बाइट्स भार-वहन करने वाले हैं। अन्य PrefixList लंबाई उपकरण को अस्थिर कर सकती हैं, कम से कम एक मामले में ऐसे बिल्ड पर जो इस फिक्स को रखता है, इसलिए लंबाई स्वीप इस बग का पता लगाने का सुरक्षित तरीका नहीं है और छोटा होना सुरक्षित नहीं है।

यह कैसे काम करता है

पैच किए गए बिल्ड एक बड़े PrefixList को स्पष्ट रूप से, एक विशिष्ट संदेश के साथ अस्वीकार करते हैं। बिना पैच वाले बिल्ड पार्सर से गुजरते हैं और एक सामान्य आंतरिक त्रुटि लौटाते हैं। एक समान अनुरोध, दो अलग-अलग उत्तर:

575-बाइट PrefixList	प्रतिक्रिया
बिना पैच	500 Internal Server Error 43549
पैच किया हुआ	200 Malformed Assertion sent to Netscaler

दो रूट आज़माए जाते हैं, पहले IdP, जैसे ही एक उत्तर देता है, रोक दिया जाता है। कोई भी अकेले पर्याप्त है, और साथ में वे दोनों SAML भूमिकाओं को कवर करते हैं:

रूट	अनुरोध	आवश्यकता
1 (पहला)	POST /saml/login — हस्ताक्षरित AuthnRequest, PrefixList में ds:SignedInfo	लक्षित vserver से बंधी एक SAML IdP नीति
2 (फॉलबैक)	POST /cgi/samlauth — SAMLResponse, एसर्शन सिग्नेचर में PrefixList	लक्षित vserver पर एक SAML SP एसर्शन कंज्यूमर सर्विस

IdP रूट पहले आता है क्योंकि यह दोनों में से अधिक मजबूत है। यह Issuer मान, AssertionConsumerServiceURL, और घड़ी विचलन के प्रति असंवेदनशील है — एक IssueInstant जो उपकरण की विचलन सहनशीलता से काफी बाहर है, फिर भी सही ढंग से अंतर करता है, क्योंकि कैननिकलाइज़ेशन समय जाँच से पहले होता है और सिग्नेचर जाँच से भी पहले।

रूट-1 का AuthnRequest हस्ताक्षरित होना चाहिए। एक अहस्ताक्षरित अनुरोध पैच किए गए और बिना पैच वाले बिल्ड पर 200 Malformed Assertion sent to Netscaler लौटाता है, जो पैच किए गए सिग्नल से बाइट-समान है, इसलिए एक प्रोब जो सिग्नेचर ब्लॉक को छोड़ देता है, हर उपकरण को पैच किए हुए के रूप में रिपोर्ट करता है। सिग्नेचर को मान्य होने की आवश्यकता नहीं है, और इस उपकरण का सिग्नेचर मान्य नहीं है; इसे केवल मौजूद होना है, क्योंकि इसका SignedInfo ही PrefixList को कैननिकलाइज़र में ले जाता है।

फिक्स सीमा पर व्यवहार

दोनों समर्थित शाखाएँ अपने फिक्स बिल्ड पर, दोनों रूटों पर, ठीक उसी समय व्यवहार बदलती हैं:

बिल्ड		निर्णय
13.1-63.16	अंतिम संवेदनशील 13.1	VULNERABLE
13.1-63.18	पहला फिक्स 13.1	PATCHED
14.1-66.59	संवेदनशील 14.1	VULNERABLE
14.1-72.61	पहला फिक्स 14.1	PATCHED

13.1-63.16 और 63.18 क्रमागत रिलीज़ हैं, इसलिए यह परिवर्तन पैच के कारण है, न कि बीच के बिल्डों में हुए बदलाव के कारण।

वे बिल्ड हैं जहाँ यह फिक्स पहली बार प्रकट हुआ, और प्रोब ठीक उसी संक्रमण का पता लगाता है। वे अब अपग्रेड करने के लिए बिल्ड नहीं हैं: बाद के बुलेटिनों ने उनकी जगह ले ली है, इसलिए 13.1-63.18 और 14.1-72.61 दोनों यहाँ PATCHED उत्तर देते हैं, जबकि नई समस्याओं के प्रति संवेदनशील रहते हैं। देखें Remediation वर्तमान फिक्स बिल्ड के लिए।

बिल्ड को फिंगरप्रिंट क्यों नहीं करते?

क्योंकि यह इस बग पर सैद्धांतिक रूप से भी काम नहीं कर सकता। 13.1-63.16 और 13.1-63.18, वे बिल्ड जो फिक्स के तुरंत दोनों ओर होते हैं, बाइट-समान tmindex.html, base.css और resources.js प्रदान करते हैं — फिक्स किसी भी वेब एसेट को स्पर्श नहीं करता। स्थिर एसेट हैश भी शाखाओं में टकराते हैं, इसलिए एक हैश-आधारित दृष्टिकोण एक संवेदनशील उपकरण को पैच किए गए बिल्ड के रूप में पहचान सकता है और उसे स्वच्छ रिपोर्ट कर सकता है, जो एक पहचान उपकरण की सबसे खराब विफलता स्थिति है। इसलिए बिल्ड फिंगरप्रिंटिंग को जानबूझकर नहीं लागू किया गया है। पैच स्थिति प्रोब से आती है, या show ns version से, जहाँ आपके पास क्रेडेंशियल होते हैं।

आवश्यकताएँ

• Python 3.8+, केवल मानक पुस्तकालय — कोई तृतीय-पक्ष पैकेज नहीं।

उपयोग```bash

single target

./cve_2026_8452_check.py https://gateway.example.com

a specific AAA / Gateway virtual server

./cve_2026_8452_check.py https://gateway.example.com:9443

scan a list, one target per line ('#' comments allowed), compact output

./cve_2026_8452_check.py -f targets.txt --brief

machine-readable output for pipelines

./cve_2026_8452_check.py -f targets.txt --json > results.json

टूल को **गेटवे या AAA वर्चुअल सर्वर** पर इंगित करें, प्रबंधन इंटरफ़ेस पर नहीं।
पूर्वशर्त प्रति वर्चुअल सर्वर है, इसलिए कई VIP वाले उपकरण का प्रत्येक VIP पर परीक्षण आवश्यक है।

### Options

| Flag | Description |
| --- | --- |
| `URL` | एक या अधिक `https://HOST[:PORT]` लक्ष्य |
| `-f, --targets-file FILE` | लक्ष्यों को फ़ाइल से पढ़ें (प्रति पंक्ति एक; `#` टिप्पणियाँ) |
| `-b, --brief` | प्रति लक्ष्य एक संरेखित पंक्ति — निर्णय, लक्ष्य, कारण टैग — कई होस्ट स्कैन करने के लिए |
| `--json` | संरचित JSON परिणाम आउटपुट करें |
| `--no-color` | रंगीन आउटपुट अक्षम करें (`NO_COLOR` और गैर-TTY का भी सम्मान करता है) |
| `--timeout SECS` | प्रति-अनुरोध टाइमआउट (डिफ़ॉल्ट: 15) |

### Examples