scyrix-llc/cve-2026-88776تحليل تقني للثغرة CVE-2026-88776، وهي حالة underflow صحيح (integer underflow) قبل المصادقة في محلّل سجلات Oracle TNS التابع لـ nsppe في NetScaler، تؤدي إلى كتابة خارج الحدود (out-of-bounds write) وانهيار محرك الحزم (packet engine).
يستطيع NetScaler موازنة تحميل قواعد بيانات Oracle. وجّه vserver من نوع ORACLE إليه فيبدأ محرك الحزم بالتحدث بلغة بروتوكول Oracle TNS بنفسه، محلّلاً حركة المرور القادمة من العملاء عبر معالج مدمج. يحتفظ ذلك المعالج بآلة حالات صغيرة لكل اتصال حتى يتذكر موقعه داخل سجل TNS.
إحدى تلك الحالات تعني "أنا في منتصف سجل، والمزيد من البايتات قادمة." وعندما تصل الحزمة التالية، يقرأ المعالج طولها ويطرح منه 10، لأن 10 بايتات من كل حزمة هي ترويسة.
لم يسأل أحد قط عمّا يحدث إذا كانت الحزمة أقصر من 10 بايتات.
أرسل واحدة كهذه. تدخل حزمة قزمة بطول 1 إلى 9 بايتات تلك الحالة، فيصبح الطول سالباً، ولأن الطول يُخزَّن في سجل غير مُوقَّع بعرض 16 بت فإنه لا يصبح سالباً. بل يلتف إلى قيمة هائلة، تصل إلى نحو 64 كيلوبايت. عندها يقوم المعالج بكل سرور بعملية memcpy لهذا القدر من البيانات من حزمتك إلى مخزن مؤقت ثابت الحجم بسعة 0x748 بايت في .bss. المحرك ليس 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 والتفاوض المجاورة، ببايتاتك. والطول الملتفت نفسه يُحفظ في 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 بايتات متماسكة ولن يحدث شيء. يعالجه المحرك ويستمر. طول المقطع القصير هو المتغير الوحيد المهم.