Curl में heap overflow कैसे बनाया

 (daniel.haxx.se)
2 पॉइंट द्वारा GN⁺ 2023-10-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • curl 8.4.0 में पाए गए महत्वपूर्ण सुरक्षा मुद्दे CVE-2023-38545 पर लेख, जिसे लंबे समय में curl की सबसे गंभीर सुरक्षा समस्याओं में से एक माना गया
  • समस्या heap overflow की है, जो SOCKS5 proxy से कनेक्ट करने वाले function में एक खामी के कारण होती है
  • यह समस्या 2020 की शुरुआत में तब लाई गई थी, जब function को blocking call से non-blocking state machine में बदला गया था; यह SOCKS5 के ज़रिए बड़े पैमाने पर parallel transfer की performance बेहतर करने के लिए किया गया था
  • खामी state machine की INIT state में है, जहाँ एक local variable सेट किया जाता है और curl यह तय करता है कि host को resolve करना है या नाम को proxy तक भेजना है। अगर host name बहुत लंबा हो, तो code local resolution mode में स्विच हो जाता है, जिससे host name target buffer से लंबा होने पर memory overflow हो सकता है
  • अगर buffer size 65541 bytes से छोटा सेट किया गया हो और host name buffer size से लंबा हो, तो overflow हो सकता है। इसके लिए किसी दुर्भावनापूर्ण actor को फ़ॉर्मूले के अनुसार बहुत बड़ा host name इनपुट देकर खामी ट्रिगर करनी होती है
  • libcurl इस्तेमाल करने वाले client जो SOCKS5 proxy के माध्यम से HTTPS server तक पहुँचते हैं, उनके लिए server को नियंत्रित करने वाला attacker HTTP 30x response के ज़रिए application को manipulated redirect लौटाकर heap buffer overflow ट्रिगर कर सकता है
  • इस समस्या को curl 8.4.0 में इस तरह ठीक किया गया कि host name बहुत लंबा होने पर remote resolution से local resolution पर स्विच करने के बजाय curl error लौटाता है। इस scenario के लिए एक dedicated test case भी जोड़ा गया है
  • लेखक मानते हैं कि अगर curl को C की जगह memory-safe language में लिखा गया होता, तो यह खामी नहीं आती, लेकिन curl को किसी दूसरी language में port करना फिलहाल योजना में नहीं है
  • लेखक का सुझाव है कि memory-safe language में लिखी गई अधिक dependencies को अनुमति देना, इस्तेमाल करना और support करना एक व्यावहारिक तरीका है, और धीरे-धीरे curl के कुछ हिस्सों को बदला भी जा सकता है
  • लेखक अपनी गलती स्वीकार करते हैं और माफ़ी मांगते हैं, और कहते हैं कि बेहतर test set से इस खामी का पता लगाया जा सकता था। वे यह भी बताते हैं कि static code analyzer इस function में समस्या नहीं पकड़ सके
  • लेखक निष्कर्ष निकालते हैं कि 20 अरब से अधिक instances में इंस्टॉल किए गए code में heap overflow भेजना ऐसा अनुभव नहीं है जिसकी सिफारिश की जाए

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

1 टिप्पणियां

 
GN⁺ 2023-10-12
Hacker News राय
  • Curl लाइब्रेरी में heap overflow समस्या पर एक लेख, यह लाइब्रेरी कई डिवाइसों में उपयोग होती है और इसका अधिकांश भाग एक ही व्यक्ति द्वारा लिखा गया है।
  • Curl के लेखक Daniel ने कोड में 1315 दिनों तक न पकड़ी गई खामी से हुई गलती के लिए माफ़ी मांगी।
  • लेख सुझाव देता है कि अगर Curl को C के बजाय memory-safe भाषा में लिखा गया होता, तो memory safety से जुड़ी समस्या से बचा जा सकता था।
  • लेखक Curl के कुछ हिस्सों को धीरे-धीरे अधिक memory-safe भाषा से बदलने की संभावना पर विचार करता है, लेकिन ऐसे विकास की धीमी प्रगति को भी स्वीकार करता है।
  • लेखक का दावा है कि Curl की 41% सुरक्षा कमजोरियों से memory-safe भाषा के ज़रिए बचा जा सकता था।
  • इस लेख को समस्या के पीछे की तर्कशृंखला और दृष्टिकोण को स्पष्ट और ईमानदार लेखन में समझाने के लिए सराहा गया।
  • कुछ टिप्पणियाँ इस समस्या की गंभीरता पर सवाल उठाती हैं, उनका कहना है कि attack vector बहुत छोटा है और इसका दुरुपयोग करने के लिए बहुत विशिष्ट परिस्थितियाँ चाहिए।
  • एक टिप्पणी anti-censorship tool का उपयोग करने वाले लोगों के लिए DNS के ज़रिए उपयोगकर्ता की पहचान लीक कर सकने वाले कोड हिस्से की आलोचना करती है।
  • एक अन्य टिप्पणी बताती है कि लेखक ने RFC1123 में निर्दिष्ट DNS hostname प्रतिबंधों को नज़रअंदाज़ किया, और यह संभव है कि इससे समस्या बढ़ी हो।
  • यह भी उल्लेख किया गया कि Windows 10 के नवीनतम security update में Curl का नया version शामिल नहीं था।