scyrix-llc/cve-2026-88776CVE-2026-88776 का तकनीकी लेख, NetScaler nsppe के Oracle TNS रिकॉर्ड पार्सर में एक प्री-ऑथ इंटीजर अंडरफ़्लो, जो आउट-ऑफ़-बाउंड्स राइट और पैकेट इंजन क्रैश का कारण बनता है।
NetScaler Oracle डेटाबेस को लोड-बैलेंस कर सकता है। इस पर ORACLE-प्रकार का vserver इंगित करें और पैकेट इंजन स्वयं Oracle TNS प्रोटोकॉल बोलना शुरू कर देता है, एक अंतर्निहित हैंडलर के साथ क्लाइंट ट्रैफ़िक को पार्स करता है। वह हैंडलर प्रति कनेक्शन एक छोटी स्टेट मशीन रखता है ताकि उसे याद रहे कि वह TNS रिकॉर्ड के भीतर कहाँ है।
उनमें से एक स्थिति का अर्थ है "मैं एक रिकॉर्ड के बीच में हूँ, और बाइट्स आ रहे हैं।" जब अगला सेगमेंट आता है, तो हैंडलर उसकी लंबाई पढ़ता है और 10 घटा देता है, क्योंकि प्रत्येक सेगमेंट के 10 बाइट्स हेडर होते हैं।
किसी ने कभी नहीं पूछा कि क्या होता है अगर सेगमेंट 10 बाइट्स से छोटा हो।
उसे एक भेजें। 1 से 9 बाइट का रंट सेगमेंट उस स्थिति में प्रवेश करता है, लंबाई ऋणात्मक हो जाती है, और चूँकि लंबाई एक unsigned 16-बिट रजिस्टर में रहती है, यह ऋणात्मक नहीं होती। यह किसी विशाल मान में रैप हो जाती है, लगभग 64 KB तक। हैंडलर फिर खुशी-खुशी आपके पैकेट से उतने डेटा को .bss में एक निश्चित 0x748-बाइट स्क्रैच बफ़र में memcpy कर देता है। इंजन PIE नहीं है, इसलिए जिस पते को रौंदा जा रहा है वह कभी नहीं हिलता।
आपको लॉग इन करने की ज़रूरत नहीं है। आपको vserver के पीछे डेटाबेस की भी ज़रूरत नहीं है, क्योंकि एप्लायंस स्वयं TNS हैंडशेक का उत्तर देता है। पूरा हमला एक TCP वार्तालाप है।
दोनों पक्षों को लाइव प्रदर्शित किया गया:
हैंडलर अपनी प्रति-कनेक्शन स्थिति को [pcb+0x15a] पर संग्रहीत करता है। अधिकांश स्थितियाँ उबाऊ हैं। यहाँ जो मायने रखती है वह 0x1F4 है, जिसका अर्थ है "रिकॉर्ड के बीच में, निरंतरता की प्रतीक्षा में," और आप सामान्य प्रोटोकॉल बाइट्स के अलावा कुछ भी उपयोग किए बिना एक कनेक्शन को उसमें निर्देशित करते हैं:
record type 6 -> deep-parser state 6 -> byte 0x03 (TTIFUN)
-> state 0x126 -> TTC function byte 0x5e (OALL8)
-> jump table 0x23589e0, index 0x59 -> writer at bfe27b:
[pcb+0x15a] = 0x1F4
उस कनेक्शन पर अगला पैकेट फिर 0x1F4 पर डिस्पैच होता है, bd49a7 से होकर bd5362 में जाता है, और यहाँ पहुँचता है:
bd5432: memset(0x30a7e60, 0, 0x748) ; scratch region (ends 0x30a85a8)
bd5445: mov rcx,[rbp-0x208] ; inbound packet buffer
bd544c: movzx eax,WORD [rcx+0xf2] ; u16 wire length of the segment
bd5453: add eax,0xfffffff6 ; len = len - 10 <== THE UNDERFLOW
bd5456: mov WORD [0x30a8476],ax ; wrapped length PERSISTED to .bss
bd545d: movzx edx,ax ; memcpy length (1..9 -> 0xfff7..0xffff)
bd5460: mov rsi,[rcx+0xe8]
bd5467: add rsi,0xa ; src = payload + 10
bd546b: mov edi,0x30a8075 ; dst = FIXED .bss global
bd5470: call 1b075e0 ; memcpy: up to ~64 KB OOB write
bd5475: mov BYTE [0x30a8478],1
इसे एक वाक्य की तरह पढ़ें। सेगमेंट की लंबाई लें। 10 घटाएँ। परिणाम संग्रहीत करें, इसे memcpy को सौंपें, हो गया। कहीं भी यह नहीं पूछा जाता कि क्या "लंबाई घटा 10" अभी भी एक ऐसी संख्या है जिसका कोई अर्थ है।
हमने इस फ़ंक्शन में उस लंबाई फ़ील्ड के हर संदर्भ को गिना। तीस। इनमें से ठीक एक जाँच है, bd4083 पर, और वह केवल शून्य से तुलना करती है। शून्य-लंबाई वाला सेगमेंट अस्वीकार कर दिया जाता है। बाकी हर लंबाई, 1 से 9 सहित, सीधे घटाव में चली जाती है।
कोड स्पष्ट रूप से मानता है कि जब तक स्टेट 0x1F4 चलेगा, तब तक स्टेट मशीन एक पर्याप्त-पूर्ण रिकॉर्ड दे चुकी होगी। स्टेट मशीन ने ऐसी कोई बात कभी वादा नहीं की। अपने ही पैकेट के रूप में आने वाला एक छोटा सेगमेंट हर डिस्पैच शर्त को पूरा करता है और पाँच बाइट कम के साथ आ जाता है।
सबसे चिढ़ाने वाली बात यह है कि विक्रेता इस बग वर्ग को जानता है। उसी बाइनरी में कहीं और, sub_119c940 बिल्कुल वही लंबाई-घटा-स्थिरांक अंकगणित करता है और इसे cmp eax,0x3f9 / ja से गेट करता है। सुरक्षित पैटर्न वहीं मौजूद था। इस जगह ने बस इसका उपयोग नहीं किया।
गंतव्य, 0x30a8075, एक 0x748-बाइट स्क्रैच क्षेत्र के अंदर स्थित है जिसके सामने केवल 0x533 बाइट वैध स्थान है। रैप हुई कॉपी उससे आगे बढ़कर बगल के DataStream और negotiation ग्लोबल्स में आपके बाइट्स के साथ घुस जाती है। और रैप हुई लंबाई स्वयं 0x30a8476 में सहेजी जाती है, जहाँ बाद का कोड इसे वापस पढ़ता है और उस पर भरोसा करता है। यह एक दूसरा करप्शन लेन है, memcpy से एक कदम हटकर।
सेटअप एक पंक्ति का कॉन्फ़िगरेशन है, एक मानक DataStream परिनियोजन:
add lb vserver v ORACLE <ip> 1521
कोई बैकएंड आवश्यक नहीं। उपकरण स्वयं TNS को टर्मिनेट करता है और अपना स्वयं का Accept पैकेट बनाता है, जिसमें "Netscaler" वेंडर स्ट्रिंग और सब कुछ शामिल है।
बातचीत चार चरणों में चलती है:
1. TNS Connect (version 0x13A)
<- the appliance answers Resend(11), then Accept(2), 32 bytes, v0x139
2. one complete, benign TTC round-trip
(some builds like to glue your runt onto the previous segment;
this resets the segmentation so the runt lands alone)
3. the arming segment: a TNS Data packet whose declared length is
actual + 32, carrying TTC bytes {03 5E} (TTIFUN / OALL8)
-> the state machine latches [pcb+0x15a] = 0x1F4, mid-record
4. the runt: 1-9 bytes, sent as its own TCP segment
-> passes the zero check, dispatches on 0x1F4
-> length - 10 wraps
-> memcpy(0x30a8075, payload+10, ~0xFFF6)
-> the packet engine dies
चरण 1 से 3 तक शुद्ध बातचीत है। चरण 4 पाँच बाइट्स है।
यह 14.1-73.30 उपकरण पर दो बार चलाया जा चुका है, वही बॉक्स, वही बिल्ड, दो स्वतंत्र रन। दोनों बार पैकेट इंजन ने SIGSEGV लिया और उससे मेल खाता कोर डंप हुआ, ns.log ने विंडो के भीतर सिग्नल 11 दर्ज किया, और डेटाप्लेन लगभग 60 सेकंड के वार्म रीस्टार्ट तक बंद रहा।
नेगेटिव कंट्रोल दोनों रन में पास हुआ। वही बातचीत चलाएँ लेकिन अंतिम सेगमेंट को सुसंगत 10 बाइट्स बना दें और कुछ नहीं होता। इंजन इसे प्रोसेस करता है और आगे बढ़ जाता है। केवल रंट लंबाई ही एकमात्र चर है जो मायने रखती है।