CVE-2026-42945 - NGINX Rift भेद्यता विश्लेषण और पुनरुत्पादन

अवलोकन

CVE-2026-42945 (कोडनेम "NGINX Rift") NGINX ngx_http_rewrite_module में एक हीप बफर ओवरफ़्लो भेद्यता है, CVSS v4 स्कोर 9.2 (क्रिटिकल)।

यह भेद्यता depthfirst सुरक्षा अनुसंधान टीम द्वारा अप्रैल 2026 में खोजी गई थी, और 2008 में NGINX 0.6.27 संस्करण में शामिल होने के बाद से 18 वर्षों तक छिपी रही।

प्रभावित क्षेत्र

• NGINX Open Source 0.6.27 ~ 1.30.0
• NGINX Plus R32 ~ R36
• NGINX Instance Manager 2.16.0 ~ 2.21.1
• F5 WAF for NGINX 5.9.0 ~ 5.12.1
• NGINX App Protect WAF 4.9.0 ~ 4.16.0 और 5.1.0 ~ 5.8.0
• NGINX Gateway Fabric 1.3.0 ~ 1.6.2 और 2.0.0 ~ 2.5.1
• NGINX Ingress Controller 3.5.0 ~ 3.7.2, 4.0.0 ~ 4.0.1, 5.0.0 ~ 5.4.1

सुधार संस्करण

• NGINX 1.31.0 (13 मई 2026 को जारी)

ट्रिगर शर्तें

भेद्यता को ट्रिगर करने के लिए निम्नलिखित NGINX कॉन्फ़िगरेशन पैटर्न की आवश्यकता है:

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

मुख्य शर्तें:

1. rewrite निर्देश के प्रतिस्थापन स्ट्रिंग में ? (प्रश्न चिह्न) शामिल है
2. बाद का set निर्देश नियमित अभिव्यक्ति कैप्चर समूह (जैसे $1) को संदर्भित करता है
3. अनुरोध URI में एस्केप करने योग्य वर्ण (जैसे +, &, % आदि) शामिल हैं

मूल कारण विश्लेषण

स्क्रिप्ट इंजन का दो-चरणीय प्रसंस्करण

NGINX का स्क्रिप्ट इंजन rewrite/set निर्देशों को निष्पादित करने के लिए दो-चरणीय प्रसंस्करण का उपयोग करता है:

1. पहला चरण (लंबाई गणना) : अंतिम स्ट्रिंग के लिए आवश्यक मेमोरी आकार की गणना करता है
2. दूसरा चरण (डेटा प्रतिलिपि) : वास्तविक डेटा को आवंटित बफर में लिखता है

अवस्था असंगति के कारण अतिप्रवाह

भेद्यता का मूल दो चरणों के बीच इंजन अवस्था असंगति है:

चरण 1: rewrite is_args फ़्लैग सेट करता है

जब rewrite निर्देश के प्रतिस्थापन स्ट्रिंग में ? शामिल होता है, तो ngx_http_script_start_args_code फ़ंक्शन सेट करता है:

void ngx_http_script_start_args_code(ngx_http_script_engine_t *e)
{
    e->is_args = 1;  // स्थायी रूप से सेट, कभी रीसेट नहीं होता!
    e->args = e->pos;
    e->ip += sizeof(uintptr_t);
}

चरण 2: set निर्देश की लंबाई गणना नया उप-इंजन का उपयोग करती है

जब बाद का set निर्देश कैप्चर समूह को संदर्भित करता है, तो ngx_http_script_complex_value_code एक पूरी तरह से शून्य किया गया उप-इंजन बनाता है:

void ngx_http_script_complex_value_code(ngx_http_script_engine_t *e)
{
    ngx_http_script_engine_t le;
    // ...
    ngx_memzero(&le, sizeof(ngx_http_script_engine_t)); // le.is_args = 0
    le.ip = code->lengths->elts;

चरण 3: लंबाई गणना बनाम वास्तविक प्रतिलिपि में विभाजन

लंबाई गणना (उप-इंजन le का उपयोग करती है, is_args=0) :

// ngx_http_script_copy_capture_len_code
if ((e->is_args || e->quote) && (e->request->quoted_uri || e->request->plus_in_uri))
{
    // is_args=0, शर्त असत्य है, else शाखा में जाता है
    return cap[n + 1] - cap[n];  // मूल लंबाई (अनएस्केप्ड) लौटाता है
}

वास्तविक प्रतिलिपि (मुख्य इंजन e का उपयोग करती है, is_args=1) :

// ngx_http_script_copy_capture_code
if ((e->is_args || e->quote) && (e->request->quoted_uri || e->request->plus_in_uri))
{
    // is_args=1, शर्त सत्य है, if शाखा में जाता है
    e->pos = (u_char *) ngx_escape_uri(pos, &p[cap[n]],
                                        cap[n + 1] - cap[n],
                                        NGX_ESCAPE_ARGS);
    // प्रत्येक एस्केप करने योग्य वर्ण 1 बाइट से 3 बाइट तक विस्तारित होता है!
}

अतिप्रवाह आकार

• आवंटित बफर आकार: raw_size (मूल कैप्चर लंबाई)
• वास्तविक लिखा गया आकार: raw_size + 2 * N (N = एस्केप करने योग्य वर्णों की संख्या)
• अतिप्रवाह मात्रा = 2 * N बाइट्स

उदाहरण के लिए, यदि URI में 100 + चिह्न हैं, तो अतिप्रवाह 200 बाइट्स है।

शोषण विधियाँ

1. DoS (सेवा से वंचित करना)

सबसे सरल शोषण विधि - कई एस्केप करने योग्य वर्णों वाले अनुरोध भेजने से वर्कर प्रक्रिया क्रैश हो जाती है:

GET /api/+++++++++++++++++++++++++++++++++++ HTTP/1.1
Host: target.com

2. RCE (दूरस्थ कोड निष्पादन)

पूर्ण RCE शोषण श्रृंखला (ASLR बंद या बाईपास की आवश्यकता है):

1. हीप लेआउट नियंत्रण : कनेक्शन क्रम के माध्यम से ngx_pool_t के हीप लेआउट को नियंत्रित करना
2. cleanup पॉइंटर को ओवरफ़्लो करना : आसन्न मेमोरी पूल संरचना पर अतिप्रवाह
3. नकली cleanup संरचना स्प्रे करना : POST अनुरोध बॉडी के माध्यम से system() पते सहित नकली संरचना इंजेक्ट करना
4. निष्पादन ट्रिगर करना : पीड़ित कनेक्शन बंद करना, ngx_destroy_pool को cleanup लिंक्ड सूची को ट्रैवर्स करने के लिए ट्रिगर करना

NGINX की बहु-प्रक्रिया आर्किटेक्चर शोषण को अधिक विश्वसनीय बनाती है - वर्कर क्रैश होने के बाद मास्टर समान मेमोरी लेआउट वाला नया वर्कर फ़ोर्क करता है।

फ़ाइल विवरण

• README.md - यह फ़ाइल, भेद्यता विश्लेषण दस्तावेज़
• Dockerfile - असुरक्षित NGINX वातावरण बनाने के लिए
• nginx.conf - भेद्यता को ट्रिगर करने वाला NGINX कॉन्फ़िगरेशन
• poc_crash.py - DoS PoC (वर्कर क्रैश ट्रिगर करता है)
• docker-compose.yml - एक क्लिक परीक्षण वातावरण शुरू करने के लिए

त्वरित पुनरुत्पादन

# 1. असुरक्षित NGINX बनाएं और प्रारंभ करें
docker-compose up -d

# 2. DoS PoC चलाएं
python3 poc_crash.py

# 3. क्रैश की पुष्टि के लिए NGINX त्रुटि लॉग देखें
docker-compose logs nginx

संदर्भ

• NGINX आधिकारिक CHANGES - सुधार घोषणा
• depthfirst अनुसंधान रिपोर्ट - मूल भेद्यता खोजकर्ता का तकनीकी विश्लेषण
• F5 सुरक्षा बुलेटिन K000160932 - आधिकारिक सुरक्षा घोषणा

अस्वीकरण

यह सामग्री केवल सुरक्षा अनुसंधान और शैक्षिक उद्देश्यों के लिए है। कृपया इस जानकारी का उपयोग अनधिकृत हमले के व्यवहार के लिए न करें।