NGINX Rift - नया NGINX exploit

 (github.com/DepthFirstDisclosures)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • NGINX Rift NGINX ngx_http_rewrite_module में मौजूद गंभीर heap buffer overflow CVE-2026-42945 के लिए एक remote code execution PoC है
  • यह vulnerability उन सर्वरों पर unauthenticated remote code execution संभव बनाती है जो rewrite और set directives का उपयोग करते हैं
  • समस्या 2008 में जोड़े गए एक bug से उत्पन्न हुई, जहाँ NGINX script engine के length calculation pass और copy pass is_args flag को अलग-अलग तरीके से handle करते हैं
  • जब rewrite replacement string में ? होता है, तो main engine में is_args set हो जाता है, लेकिन length calculation एक नए sub-engine में चलती है जिसे 0 पर reinitialize किया गया होता है, इसलिए वह सिर्फ original capture length लौटाती है
  • copy stage में is_args = 1 स्थिति के साथ ngx_escape_uri और NGX_ESCAPE_ARGS call किए जाते हैं, जिससे escape किए जा सकने वाले हर byte का विस्तार 3 bytes तक हो जाता है और कम allocate किया गया heap buffer attacker-controlled URI data से overflow हो जाता है
  • exploit requests के बीच heap feng shui का उपयोग करके पास के ngx_pool_t के cleanup pointer को corrupt करता है, और क्योंकि URI bytes में null byte नहीं डाला जा सकता, इसलिए spray POST body के जरिए किया जाता है
  • corrupt हुआ pointer एक fake ngx_pool_cleanup_s की ओर redirect किया जाता है और pool destruction के समय system() call करने के लिए configure किया जाता है
  • CVE-2026-42945 के साथ-साथ, depthfirst के security analysis system ने NGINX source को एक बार onboard करने भर से CVE-2026-42946, CVE-2026-40701 और CVE-2026-42934 समेत 3 memory corruption issues भी स्वतः खोज लिए
  • प्रभावित versions हैं NGINX Open Source 0.6.27–1.30.0 और NGINX Plus R32–R36, जबकि fixes Open Source 1.31.0/1.30.1 और Plus R36 P4/R35 P2/R32 P6 में दिए गए हैं
  • पूरी vendor advisory https://my.f5.com/manage/s/article/K000160932 पर उपलब्ध है, और तकनीकी विवरण technical write-up में दिए गए हैं
  • PoC को Ubuntu 24.04.3 LTS पर test किया गया था, और यह ./setup.sh, docker compose -f env/docker-compose.yml up, python3 poc.py --shell के क्रम में vulnerable NGINX container चलाकर shell execute करने का flow देता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News की राय

  • एक security ज़िम्मेदार व्यक्ति के रूप में, यह देखकर थकान होती है कि बहुत से लोग यह तय कर रहे हैं या इशारा कर रहे हैं कि यह समस्या इसलिए बहुत कम डरावनी है क्योंकि public exploit ASLR bypass नहीं करता
    मूल लेख का दावा है कि इस हमले से ASLR को भरोसेमंद तरीके से bypass करने का तरीका मौजूद है, और भले ही सबूत न हो, इसे default assumption मानना उचित है
    ASLR सिर्फ एक defense in depth तकनीक है जो exploit को कठिन बनाती है, और ज़्यादातर मामलों में समय और कौशल हो तो ASLR bypass जुड़ ही जाता है
    LLM agents की वजह से समय और कौशल की वह बाधा भी हर कुछ हफ्तों में कम होती जा रही है, इसलिए पूरी तरह weaponized exploit आना बस समय की बात है; वह public भी हो सकता है, private भी रह सकता है
    “ASLR on है तो जोखिम नहीं है” कहना साफ़ तौर पर गलत है, और जो लोग इस पर भरोसा करते हैं उनके लिए बहुत हानिकारक है
    यह गलत धारणा कि mitigation techniques exploit को मुश्किल बना देती हैं, इसलिए security vulnerabilities की चिंता करने की ज़रूरत नहीं, पहले भी बहुत नुकसान कर चुकी है
    आधुनिक mitigation techniques होना अच्छी बात है, लेकिन patch जितनी जल्दी हो सके लगाना चाहिए, और अगर आप vendor हैं तो researcher ने ASLR bypass नहीं दिखाया इस वजह से vulnerability report को अमान्य न मानें; root cause को ठीक करें

    • remotely accessible vulnerabilities को हल्के में नहीं लेना चाहिए
      लेकिन अभी के लिए preconditions कुछ असामान्य लगती हैं
      10 साल में कई configurations के साथ nginx चलाया है, लेकिन rewrite और set को साथ में एक बार भी इस्तेमाल नहीं किया
    • जो लोग कहते हैं “AI cyber को solve कर देगा” और जो लोग कहते हैं “ASLR on है तो सब ठीक है”, ये 1:1 overlap करते हैं, ऐसा मानना सुरक्षित है
      और वे हमेशा “cyber” ही कहते हैं
    • मैं इस नज़रिए से सहमत नहीं हूँ, या कम से कम इसे अलग तरह से कहना चाहूँगा
      ASLR एक अतिरिक्त password जैसा है जिसे guess करना पड़ता है, इसमें कुछ entropy होती है और यह आम तौर पर स्थिर रहता है
      अगर vulnerability में information leak वाला हिस्सा नहीं है, तो ASLR उस vulnerability को पूरी तरह mitigate कर सकता है, या फिर दूसरी vulnerability चाहिए होगी
      यह अलग चर्चा है
      ASLR किसी individual vulnerability को पूरी तरह mitigate कर सकता है, लेकिन exploit chain को नहीं रोक सकता
      फिर भी, तेज़ patching के लिए मनवाने में information leak पैदा करने वाली दूसरी vulnerability की संभावना का तर्क देना बेहतर है
      exploit chains हर तरह की vulnerabilities में खतरनाक होती हैं
    • इंटरनेट पर misinformation के फैलाव को रोकना मुश्किल है, और ज़्यादातर लोगों को पता भी नहीं होता कि वे गलत हैं
      सच में हानिकारक चीज़ है आत्मविश्वास से भरी random internet comments पर भरोसा कर लेना
      इन्हें परखने की क्षमता विकसित कर लें तो security के अलावा दूसरी जगह भी काम आएगी
    • public internet पर exposed software के बारे में remote code execution report पढ़ूँ तो आम तौर पर कुछ ही मिनटों में upgrade कर देता हूँ
      मैं ऐसी reports इसी वजह से पढ़ता हूँ, और इन्हें गंभीरता से लेना चाहिए
      नहीं तो मशीन जल्दी ही compromise हो जाएगी
      हाल में लगता है कि public होने वाले remote code execution exploits में pre-notification अक्सर नहीं होती, कम से कम software upgrade करने के लिए कुछ मिनट तो मिलने चाहिए
      यह वैसा दौर लगता है जैसे 1980 के दशक के अंत से 1990 के दशक की शुरुआत, जब remotely exploitable sendmail bugs की बाढ़ आती थी और disclosure में कोई safety guard नहीं होता था
      अगर ऐसी reports न पढ़ें, या बहुत देर से पढ़ें, तो लाखों machines compromise हो सकती हैं
      इस समय nginx public web server market का लगभग 39~43% हिस्सा रखता है, इसलिए मामला काफ़ी गंभीर है

  • यह मामला काफ़ी खराब है, लेकिन इसमें preconditions हैं
    replacement string में question mark वाला rewrite directive चाहिए, और उसके बाद regex capture group को refer करने वाला set directive आना चाहिए
    उदाहरण: set $var $1
    साथ ही proof of concept ASLR disabled मानकर चलता है

    • उदाहरण: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
    • क्या कोई distribution default में ASLR off रखती है?
      manually off भी करें तो nginx ऐसा candidate नहीं लगता
    • आजकल rewrite लगभग कोई इस्तेमाल नहीं करता, है न?
      लगता है यह PHP और Apache के पुराने दौर की चीज़ है

  • आधिकारिक F5 पेज यहाँ है: https://my.f5.com/manage/s/article/K000161019
    जैसा दूसरी जगह भी लिखा गया है, ASLR सुरक्षा देता है
    प्रभावित platforms के fixed builds का इंतज़ार करते समय mitigation के रूप में “rewrite definitions में unnamed captures की जगह named captures इस्तेमाल करें” कहा गया है
    मतलब, “इस example में vulnerability को mitigate करने के लिए $1 और $2 को उचित named captures $user_id, $section से बदलें”
    F5 ने 1.31.0 और 1.30.1 patch कर दिए हैं
    OpenResty के लिए 1.27 और 1.29 के patches हैं: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
    Nginx-आधारित Lua application server OpenResty की प्रगति यहाँ देख सकते हैं: https://github.com/openresty/openresty/issues/1119

  • proof of concept ASLR को disable करता है: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

    • worker processes master से fork होते हैं, इसलिए उन्हें वही memory layout मिलता है
      workers पर unlimited crashes कराए जा सकते हैं
      इससे read oracle बनाने का तरीका होने की संभावना काफ़ी है
      कम से कम reliable denial of service तो संभव है
      Depth First का पूरा analysis: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

  • क्या Apache और Nginx के अच्छे alternatives में कोई ऐसा है जो memory-safe language में लिखा गया हो और जिसमें security holes कम हों?
    Java में लिखे Jetty और Go में लिखे Caddy को थोड़ा देखा, लेकिन Jetty में shell injection जैसी दूसरी तरह की vulnerabilities का इतिहास है, इसलिए यक़ीन नहीं कि वह बेहतर है

    • memory safety अच्छी चीज़ है, लेकिन यह हर threat को नहीं रोकती
      आजकल infra operators को active defense यानी MAC, जैसे SELinux और AppArmor, से परिचित होना चाहिए
      पहले friction ज़्यादा था, लेकिन अब इस्तेमाल आसान बनाने वाले tools ज़्यादा हैं
      https://presentations.nordisch.org/apparmor/
      https://github.com/nobody43/apparmor-profiles/blob/master/ng...
      https://github.com/nobody43/apparmor-suggest
      संदर्भ के लिए, ये दोनों repositories मैंने खुद बनाई हैं
    • Apache और nginx के पैमाने पर इस्तेमाल होने वाले software में vulnerability history होना लगभग तय है
      दोनों का इतने लंबे समय तक market share बनाए रखना उलटे एक अच्छा संकेत है
    • Caddy इस्तेमाल करने में सचमुच बहुत आसान था
      लेकिन proper plugin system की जगह मनचाहे plugin combinations के हिसाब से हज़ारों binaries बनने वाला मॉडल थोड़ा खराब है
      फिर भी, source से build करें तो यह काफ़ी साफ़ और सरल है
    • Apache और शायद Nginx में भी features और components की संख्या बहुत ज़्यादा है
      अधिकतर alternative HTTP servers अपना scope काफ़ी कम रखते हैं, इसलिए पहले तय करना होगा कि कौन-से features चाहिए
      memory-safe languages में HTTP servers पर बहुत चर्चा नहीं देखी
      C आधारित तीन बड़े servers, Apache, Nginx और lighttpd, तीनों काफ़ी मज़बूत हैं, और लगता नहीं कि सिर्फ language की वजह से बहुत लोग नए project पर switch करना चाहेंगे
      और ज़्यादातर memory-safe languages चुनने का मतलब उस language का कभी-कभी बहुत बड़ा runtime, virtual machine और उससे जुड़े components भी साथ लेना होता है
      अगर Java web server होगा तो संभव है कि किसी random Java project की तरह वह log4j भी इस्तेमाल करे
    • load balancer के use case में HAProxy बहुत अच्छा काम कर रहा है

  • “exploit requests के बीच cross-request heap feng shui का इस्तेमाल करता है” — इस तरह feng shui का इस्तेमाल पहली बार देखा

  • क्या Debian 12 में यह patch हो चुका है?
    और अगर कहीं भी rewrite या set इस्तेमाल नहीं हो रहा, तो क्या मानें कि प्रभाव नहीं पड़ेगा?

    • https://security-tracker.debian.org/tracker/CVE-2026-42945
    • Ubuntu आज सुबह तक patch हो चुका था
      Debian ने अभी शायद trixie को patch नहीं किया है
    • nginx इस्तेमाल करते हुए कम से कम set भी न इस्तेमाल हो, ऐसा बहुत कम होगा
      nginx के ज़्यादातर use cases में TLS terminate किया जाता है और request को node/php/go वगैरह को forward किया जाता है
      इसलिए लगा कि proxy_set_header X-Host $host; जैसी lines में attacker-controlled data के साथ कम से कम एक set तो होगा
      सुधार: named captures शायद प्रभावित नहीं होते
      अगर कहीं $1 नहीं है, तो शायद ठीक है

  • बेहतर links:
    https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
    https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)