NGINX Rift

CVE-2026-42945 के लिए RCE प्रूफ ऑफ कॉन्सेप्ट, जो NGINX के ngx_http_rewrite_module में 2008 में पेश किया गया एक गंभीर हीप बफर ओवरफ्लो है। यह बग rewrite और set निर्देशों का उपयोग करने वाले सर्वरों के खिलाफ बिना प्रमाणीकरण के रिमोट कोड निष्पादन को सक्षम बनाता है।

यह फोर्क मूल PoC को एक ASLR-बाईपास श्रृंखला के साथ विस्तारित करता है जो NGINX ओवरफ्लो को एक सामान्य समान-होस्ट LFI/मनमाना-फ़ाइल-रीड प्रिमिटिव के साथ जोड़ता है। फ़ाइल-रीड प्रिमिटिव का उपयोग nginx वर्कर मैप्स, libc, और लाइव /proc/<worker>/mem को पुनर्प्राप्त करने, फिर system() पते और प्रयोग करने योग्य हीप लक्ष्यों को दूरस्थ रूप से प्राप्त करने के लिए किया जाता है।

इस लैब के पुराने संस्करणों ने जानबूझकर एक nginx वर्कर को क्रैश किया ताकि सेवा एक कोर डंप लिखे, फिर उस कोर डंप को फ़ाइल-रीड प्रिमिटिव के माध्यम से प्राप्त और पार्स किया ताकि ASLR-संवेदनशील प्रक्रिया स्थिति, जिसमें हीप लक्ष्य शामिल हैं, को पुनर्प्राप्त किया जा सके। इस रिपॉजिटरी में, कोरलेस केवल "पठनीय क्रैश कोर डंप के बिना" के लिए संक्षिप्त है: वर्तमान डिफ़ॉल्ट पथ उस क्रैश-कोर निर्भरता को लाइव procfs मेमोरी रीड के साथ बदल देता है, जबकि संरक्षित लीगेसी कोर-निर्देशित पथ अभी भी उत्पन्न वर्कर कोर डंप का उपयोग करता है।

यह भेद्यता — तीन अन्य मेमोरी भ्रष्टाचार मुद्दों (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) के साथ — depthfirst के सुरक्षा विश्लेषण प्रणाली द्वारा NGINX स्रोत के ऑनबोर्डिंग के एक क्लिक के बाद स्वायत्त रूप से खोजी गई थी।

अपने कोड में ऐसे मुद्दे खोजना चाहते हैं? उसी प्रणाली को https://depthfirst.com/open-defense पर आज़माएं।

बग (TL;DR)

NGINX की स्क्रिप्ट इंजन दो-पास प्रक्रिया का उपयोग करती है: पहले आवश्यक बफर आकार की गणना करें, फिर डेटा कॉपी करें। is_args फ़्लैग मुख्य इंजन पर सेट किया जाता है जब एक rewrite प्रतिस्थापन में ? होता है, लेकिन लंबाई-गणना पास ताज़ा शून्य किए गए उप-इंजन पर चलता है। इसलिए:

• लंबाई पास is_args = 0 देखता है → कच्ची कैप्चर लंबाई लौटाता है।
• कॉपी पास is_args = 1 देखता है → ngx_escape_uri को NGX_ESCAPE_ARGS के साथ कॉल करता है, प्रत्येक एस्केप करने योग्य बाइट को 3 बाइट्स में विस्तारित करता है।

कॉपी हमलावर-नियंत्रित URI डेटा के साथ छोटे हीप बफर को ओवरफ्लो करती है। शोषण क्रॉस-अनुरोध हीप फेंग शुई का उपयोग करके एक आसन्न ngx_pool_t के cleanup पॉइंटर को भ्रष्ट करता है (POST निकायों के माध्यम से स्प्रे किया जाता है, क्योंकि URI बाइट्स में नल बाइट्स नहीं हो सकते), इसे एक नकली ngx_pool_cleanup_s पर पुनर्निर्देशित करता है जो पूल विनाश पर system() को लागू करता है।

इस बग के बारे में हमारे तकनीकी लेख में और पढ़ें।

प्रभावित और ठीक किए गए संस्करण

उत्पाद	प्रभावित	निम्न में ठीक किया गया
NGINX ओपन सोर्स	0.6.27 – 1.30.0	1.31.0, 1.30.1
NGINX प्लस	R32 – R36	R36 P4, R35 P2, R32 P6

पूर्ण विक्रेता सलाह: https://my.f5.com/manage/s/article/K000160932

निजी शोध फोर्क: ASLR-सक्षम रिमोट लैब श्रृंखला

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

क्या बग को ASLR सक्षम के साथ एक वास्तविक x86_64 लिनक्स VM के खिलाफ शोषित किया जा सकता है, बिना हार्डकोडेड डॉकर/लैब ऑफसेट पर निर्भर हुए?

इस शोध फोर्क में उत्तर हाँ, महत्वपूर्ण बाधाओं के साथ है। कार्यशील श्रृंखलाएं ASLR को अक्षम नहीं करती हैं और मूल हार्डकोडेड हीप/लिबक पतों का उपयोग नहीं करती हैं। इसके बजाय, वे समान-पोर्ट HTTP-सुलभ प्रिमिटिव के माध्यम से रनटाइम स्थिति प्राप्त करते हैं, फिर दूरस्थ रूप से प्राप्त प्रकटीकरण डेटा से अंतिम हीप लक्ष्य का चयन करते हैं।

अब दो ASLR-सक्षम एक्सप्लॉइट ट्रैक हैं, जिनमें कोरलेस पथ को वर्तमान सर्वश्रेष्ठ PoC माना जाता है:

• nginx_rifter.py: स्वच्छ, आत्म-निहित मूल्यांकन और एकीकृत एक्सप्लॉइट प्रवेश बिंदु। इसकी डिफ़ॉल्ट एक्सप्लॉइट विधि अब कोरलेस /proc/<nginx-worker>/mem श्रृंखला है।
• nginx_rifter_core_v2_1.py: nginx_rifter.py का संरक्षित लीगेसी कोर-निर्देशित संस्करण। यह पुराने VM-परीक्षित क्रैश-कोर शोध पथ को पुन: उत्पन्न करने के लिए उपयोगी है, लेकिन यह अब पसंदीदा PoC नहीं है।
• tools/proc_mem_coreless_exploit.py: पहले का स्टैंडअलोन कोरलेस शोध हार्नेस। इसका तर्क nginx_rifter.py में विलय कर दिया गया है; उपकरण कच्चे प्रयोग पुनरावृत्ति के लिए बना हुआ है।

लक्ष्य टोपोलॉजी जानबूझकर समान-पोर्ट है:

• कमजोर रूट: /api/...
• PHP लोकल-फ़ाइल-रीड रूट: /lfi.php?file=...
• phpinfo संकेत रूट: /phpinfo.php
• HTTP/2 पीड़ित कनेक्शन: समान nginx श्रोता और वर्कर
• सबूत सत्यापन: PHP LFI एंडपॉइंट के माध्यम से मार्कर फ़ाइल को वापस पढ़ना

वर्तमान कोरलेस proc-mem पथ निम्नलिखित उच्च-स्तरीय चरण करता है:

1. PHP LFI का उपयोग करके PHP पहचान, nginx पिड फ़ाइलें, nginx वर्कर /proc/<pid>/maps, और मैप की गई libc फ़ाइल पढ़ता है।
2. LFI पर लक्ष्य libc को पार्स करता है ताकि उस वर्कर के लिए निरपेक्ष system() पते की गणना की जा सके।
3. सामान्य NGINX Rift स्प्रे/प्रोब ट्रैफिक भेजता है जबकि वर्कर स्थिति को जीवित रखता है।
4. फ़ाइल-रीड प्रिमिटिव के माध्यम से /proc/<worker>/mem से मैप की गई श्रेणियां पढ़ता है।
5. लाइव मेमोरी में नॉन्स-चिह्नित नकली-क्लीनअप संरचनाओं और क्लीनअप-पूल उम्मीदवारों के लिए स्कैन करता है।
6. लाइव वर्कर मेमोरी से प्राप्त सीमित अंतिम उम्मीदवारों का उपयोग करता है, न कि हार्डकोडेड लैब ऑफसेट या पठनीय क्रैश कोर का।
7. फ़ाइल-रीड प्रिमिटिव के माध्यम से मार्कर आउटपुट को पढ़कर कमांड निष्पादन को सत्यापित करता है।

लीगेसी कोर-निर्देशित पथ समान आधार-पता व्युत्पत्ति करता है, फिर जानबूझकर एक वर्कर को क्रैश करता है, LFI पर उत्पन्न कोर फ़ाइल को पढ़ता है, और उस कोर को स्प्रे किए गए नकली-क्लीनअप स्लॉट के लिए खनन करता है। यह एक उपयोगी शोध पुल था, लेकिन यह कोर-डंप नीति और फ़ाइलसिस्टम अनुमतियों पर निर्भर करता है जो डिफ़ॉल्ट तैनाती में कम सामान्य हैं।

यह मूल नियतात्मक डॉकर डेमो के समान नहीं है। x86_64 VM पथ सामान्य लिनक्स ASLR को सक्षम छोड़ता है और प्रत्येक रन पर प्रक्रिया-विशिष्ट पतों की पुनर्गणना करता है। डॉकर कोरलेस पथ भी ASLR को सक्षम छोड़ता है और असामान्य पठनीय-कोर आवश्यकता को हटा देता है, लेकिन यह procfs अनुमति व्यवहार पर निर्भर करता है जिसे लक्ष्य वर्ग के लिए सत्यापित किया जाना चाहिए।

दायरा और चेतावनियां

यह फोर्क एक नियंत्रित शोध लैब है। ASLR-सक्षम श्रृंखलाएं मजबूत शर्तों पर निर्भर करती हैं जो सार्वभौमिक उत्पादन धारणाएं नहीं हैं:

• PHP को एक उपयोगी लोकल-फ़ाइल-रीड प्रिमिटिव को उजागर करना चाहिए।
• डिफ़ॉल्ट कोरलेस proc-mem पथ के लिए, PHP को समान-UID nginx वर्कर /proc/<pid>/maps, मैप की गई libc, और बड़े मैप किए गए ऑफसेट पर /proc/<pid>/mem को पढ़ने में सक्षम होना चाहिए।
• लीगेसी कोर-निर्देशित पथ के लिए, PHP को समान-UID nginx वर्कर /proc/<pid>/maps, मैप की गई libc, और उत्पन्न वर्कर कोर को पढ़ने में सक्षम होना चाहिए।
• HTTP/2 उसी nginx श्रोता पर सक्षम है ताकि अंतिम श्रृंखला द्वारा उपयोग किए जाने वाले कनेक्शन-पूल क्लीनअप लक्ष्य प्रदान किया जा सके।

phpinfo() और /proc/<pid>/maps PIE/libc आधार पतों को पुनर्प्राप्त करने के लिए पर्याप्त हैं, लेकिन वे अपने आप में इस एक्सप्लॉइट के लिए आवश्यक सटीक हीप ऑब्जेक्ट/विंडो को पुनर्प्राप्त करने के लिए पर्याप्त नहीं हैं। पुरानी श्रृंखला ने उस अंतिम प्रकटीकरण के लिए एक पठनीय क्रैश कोर का उपयोग किया। वर्तमान डिफ़ॉल्ट श्रृंखला इसके बजाय /proc/<worker>/mem का उपयोग करती है, जो समान-UID तैनाती में वास्तविक मनमाना-फ़ाइल-रीड परिणाम के करीब है क्योंकि यह कोर-डंप नीति को बदले बिना लाइव वर्कर मेमोरी को उजागर करती है।

महत्वपूर्ण शेष सीमाएं: