HTTP/2 CONTINUATION फ़्लड: तकनीकी विवरण

 (nowotarski.info)
3 पॉइंट द्वारा GN⁺ 2024-04-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें

HTTP/2 CONTINUATION Flood कमजोरी: तकनीकी विवरण

  • CONTINUATION Flood कई HTTP/2 प्रोटोकॉल implementations में पाई गई vulnerabilities की एक श्रेणी है, जो Rapid Reset हमले से भी अधिक गंभीर खतरा पैदा करती है।
  • हमले के परिणाम server crash से लेकर performance degradation तक हो सकते हैं, और attack requests HTTP access logs में दिखाई नहीं देतीं।

भूमिका

  • अक्टूबर 2023 में HTTP/2 Rapid Reset हमले के बारे में पता चला, और HTTP/2 पर security analysis के दृष्टिकोण से शोध शुरू करने का निर्णय लिया गया।

HTTP/2 का संक्षिप्त परिचय

  • HTTP/1.1 और HTTP/2 के बीच मुख्य अंतर यह है कि बाद वाला एक binary protocol है, और client व server text lines के बजाय frames का आदान-प्रदान करते हैं।
  • HEADERS frame और CONTINUATION frame की व्याख्या आवश्यक है।

HEADERS frame

  • HEADERS frame का उपयोग request और response के HTTP headers भेजने के लिए किया जाता है, और यह header data को compress करने के लिए HPACK encoding algorithm का उपयोग करता है।
  • frame में END_HEADERS और END_STREAM जैसे flags सेट किए जा सकते हैं।

CONTINUATION frame

  • CONTINUATION frame, HEADERS frame से बहुत मिलता-जुलता है, लेकिन इसमें केवल END_HEADERS flag होता है, और जब यह flag सेट होता है, तो इसका अर्थ है कि header stream समाप्त हो गई है।

CONTINUATION Flood कमजोरी

  • यदि client एक नई HTTP/2 stream शुरू करता है और HEADERS व CONTINUATION frames भेजता है, लेकिन END_HEADERS flag कभी भी सेट नहीं किया जाता, तो server को अनंत header stream को parse करके memory में store करना पड़ता है।
  • HTTP/1.1 में header size limits और request/header timeouts अनंत headers से सुरक्षा देते हैं, लेकिन कई HTTP/2 servers में ये safeguards अनुपस्थित हैं या गलत तरीके से implement किए गए हैं।

CPU consumption: Golang का मामला

  • Golang, CONTINUATION Flood के कारण CPU consumption का एक उदाहरण है, जहाँ http2MetaHeadersFrame नामक एक abstract class का उपयोग HEADERS frame और CONTINUATION frame को process करने के लिए किया जाता है।
  • HPACK decoder को इस तरह सेट किया गया है कि header size limit तक पहुँचने पर वह header emission रोक दे, लेकिन यदि END_HEADERS flag नहीं है, तो function return नहीं करता और headers को decode करना जारी रखता है।

memory exhaustion

  • memory exhaustion सबसे गंभीर मामलों में से एक है, क्योंकि कुछ implementations CONTINUATION frames का उपयोग करके बनाई गई header list के आकार को सीमित नहीं करतीं।
  • जिन implementations में header timeout नहीं है, उनमें केवल एक HTTP/2 connection से server को crash किया जा सकता है।

संभव assertion crash: Node.js (विशेष मामला)

  • Node.js CONTINUATION frames की अनंत stream को ठीक से संभालता है, लेकिन header stream के दौरान connection टूटने पर data race bug उत्पन्न होता है।
  • Node.js Http2Session destructor के भीतर memory allocation को track करता है, और connection टूटने के समय current_nghttp2_memory_ value एक साथ update होने से crash हो सकता है।

पिछली HTTP/2 vulnerabilities से तुलना

  • पहले भी कई HTTP/2 vulnerabilities रिपोर्ट की गई हैं, और CONTINUATION Flood इन पुरानी vulnerabilities से अलग तरीके से काम करता है।
  • CONTINUATION Flood खाली headers भेजने के बजाय, server द्वारा निर्धारित frame size limit तक बहुत सारे arbitrary headers भेजता है।

अंतिम टिप्पणी

  • HTTP/2 traffic सभी मानवीय HTTP traffic का लगभग 60% हिस्सा है, और प्रभावित projects के महत्व को देखते हुए, इंटरनेट का एक बड़ा हिस्सा आसानी से exploit की जा सकने वाली vulnerabilities से प्रभावित था।
  • यदि इस कमजोरी का वास्तविक दुनिया में दुरुपयोग किया गया होता, तो उचित HTTP/2 ज्ञान के बिना server administrators के लिए इसे debug करना बहुत कठिन होता।

GN⁺ की राय

  • यह कमजोरी server availability को गंभीर रूप से प्रभावित कर सकती है, और खासकर logs में दर्ज न होने के कारण इसका पता लगाना और प्रतिक्रिया देना कठिन है।
  • server administrators को नियमित रूप से security updates लागू करने चाहिए और असामान्य patterns का पता लगाने के लिए traffic analysis tools का उपयोग करना चाहिए।
  • ऐसी vulnerabilities cyber security community के लिए चेतावनी का काम करती हैं और अधिक सुरक्षित protocol design व implementation के महत्व को रेखांकित करती हैं।
  • आलोचनात्मक दृष्टि से देखें तो यह कमजोरी व्यापक रूप से उपयोग किए जाने वाले protocol की मूल design flaws को उजागर करती है, जो इंटरनेट के बुनियादी infrastructure की विश्वसनीयता पर सवाल उठाती है।
  • यदि कोई संबंधित क्षेत्र का विशेषज्ञ नहीं है, तो ऐसी जटिल vulnerabilities को समझना और उनसे निपटना कठिन हो सकता है, इसलिए security education और awareness बढ़ाने की आवश्यकता है।

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

1 टिप्पणियां

 
GN⁺ 2024-04-06
Hacker News राय

  • इस समस्या को हाल ही में Bandit में ठीक किया गया

    • एक महीने पहले Bandit में यही समस्या हल करने का व्यक्तिगत अनुभव।
    • लिंक के ज़रिए कोड की सटीक लोकेशन दी गई।
    • इम्प्लीमेंट करने वाले के नज़रिए से यह समस्या बहुत स्पष्ट थी, और लगा था कि दूसरे implementations ने भी पहले से बचाव के उपाय कर लिए होंगे।
    • लेकिन दर्जनों implementations जाँचने पर पता चला कि प्रमुख HTTP/2 servers में भी ऐसे protection mechanisms नहीं थे या वे गलत तरीके से लागू किए गए थे।

  • डेवलपमेंट संस्कृति पर आलोचना

    • यह इंगित किया गया कि डेवलपर्स dynamic auto-scaling के इतने आदी हो गए हैं कि वे यह सोचते ही नहीं कि कोई चीज़ कितनी बड़ी हो सकती है।
    • यह समस्या सिर्फ HTTP/2 तक सीमित नहीं है, लेकिन HTTP/2 की complexity इसे और बदतर बना सकती है।
    • पहले HTTP/1.x के दौर में C जैसी भाषाओं का उपयोग करते हुए buffer length management पर लगातार ध्यान देना पड़ता था, और request header allocation को अनंत तक बढ़ाने जैसी बात नहीं होती थी।

  • प्रभावित न होने वाले server/reverse proxy की सूची

    • पिछले लेख में बताई गई उन web servers और reverse proxies की सूची जो प्रभावित नहीं हैं।
    • Nginx, Jetty, HAProxy, NetScaler, Varnish प्रभावित नहीं हैं।

  • HTTP/1.1 की सुरक्षा पर विचार

    • उल्लेख किया गया कि उनकी साइट पूरे दिन ध्यान का केंद्र बनी रही।
    • अगर साइट पर ट्रैफ़िक कम हो, तो क्या HTTP/1.1 इस्तेमाल करना ज़्यादा सुरक्षित होगा—यह सवाल उठाया गया।

  • लेखक की प्रशंसा

    • लेखक ने व्यापक दृष्टिकोण अपनाया, अपनी खोजों को ज़िम्मेदारी से रिपोर्ट किया, और उन्हें पढ़ने में आसान तरीके से साझा किया—इसके लिए उनकी सराहना की गई।

  • Slowloris v2 का उल्लेख

    • मज़ाक में कहा गया कि अगर इस समस्या को धीरे-धीरे पैदा किया जाए, तो इसे 'slowloris v2' कहा जा सकता है।

  • टाइपो का उल्लेख

    • 'serveral retries' जैसी टाइपो को मज़ेदार बताया गया।

  • HTTP/2 पर आलोचनात्मक नज़रिया

    • इस बात की आलोचना कि HTTP/2 को application layer protocol के लिए 'upgrade' के transport layer की तरह कैसे आगे बढ़ाया जा सकता है।