Git के carriage return और clone RCE vulnerability

 (dgl.cx)
1 पॉइंट द्वारा GN⁺ 2025-07-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Git repository के अंदर carriage return character का उपयोग करने वाली एक attack technique का परिचय
  • इस vulnerability के कारण remote code execution (RCE) की संभावना पैदा होती है
  • कुछ खास git clone प्रक्रियाओं के दौरान malicious command execute हो सकते हैं
  • Linux और Windows environment में इसका प्रभाव देखा गया है
  • सुरक्षा के लिहाज़ से कमज़ोर Git repository management के जोखिम पर ज़ोर दिया गया है

carriage return character और Git vulnerability

  • Git repository के भीतर carriage return (\r) character वाले filename बनाए जा सकते हैं
  • ऐसे filename वाली repository को git clone से clone करने पर, command parsing की प्रक्रिया में अनचाहे command execution संभव हो सकते हैं

remote code execution (RCE) scenario

  • attacker carriage return character डाले गए file को repository में add करके commit करता है
  • जब user इस repository को git clone करता है, तो file system और git command की गलत व्याख्या के कारण अनचाहे code execution का जोखिम पैदा हो सकता है
  • खास तौर पर, hooking script (जैसे .git/hooks folder के code) को अपने-आप execute होने के लिए उकसाया जा सकता है

प्रभावित environment और response

  • Linux और Windows सहित कई operating system के git में यह समस्या हो सकती है
  • Git repository manage करने वाले या अक्सर external repository clone करने वाले developer और company के लिए यह गंभीर security threat है

security advisory

  • बाहर के अविश्वसनीय git repository को clone करते समय latest version का उपयोग और security status की जांच ज़रूरी है
  • repository के भीतर असामान्य character, खासकर carriage return जैसे, वाले filename को detect करके clone से पहले review करना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2025-07-09
Hacker News की राय

  • इन सबका नतीजा यह है कि submodule clone करते समय पढ़ते हुए path = ... फ़ॉर्म इस्तेमाल होता है, लेकिन लिखते समय ^M पर खत्म न होने वाले किसी दूसरे path में रिकॉर्ड हो जाता है

    • लेख में जिस "remote code execution" की बात की गई है, वह यहाँ कैसे होती है, और security के लिहाज़ से यह कितनी गंभीर है, इस पर सवाल उठाया गया

    • अभी तक PoC सार्वजनिक नहीं किया गया है, लेकिन कहा गया कि यह लगभग CVE-2024-32002 exploit का ही हल्का-सा बदला हुआ रूप है, और इसे fix करने वाले commit के tests भी बड़ा hint देते हैं

    • CVE-2024-32002 का विवरण उद्धृत: submodule वाला repository अगर malicious तरीके से तैयार किया जाए, तो Git के bug का उपयोग करके submodule worktree की बजाय .git/ directory में files लिखी जा सकती हैं. इसकी वजह से ऐसा hook लिखा जा सकता है जो clone के दौरान ही चल जाए, यानी user को वास्तव में चलने वाले code की जाँच का मौका भी न मिले

    • संक्षेप में, malicious git hook को repository में डाला जा सकता है, और आम तौर पर git hook git clone पर install नहीं होते, लेकिन यह attack उसे संभव बना देता है, जिससे clone प्रक्रिया के दौरान hook चल सकता है

    • नए CVE के बारे में और जानकारी यहाँ मिल सकती है

      • config value पढ़ते समय Git CR और LF characters हटा देता है, लेकिन लिखते समय CR को quote नहीं करता, इसलिए पढ़ते समय data loss होता है
      • अगर submodule path के अंत में CR character हो, तो stripped path इस्तेमाल होने लगता है, जिससे submodule गलत location पर checkout हो सकता है
      • अगर उस stripped path और submodule hook directory के बीच पहले से symlink मौजूद हो, तो attacker post-checkout hook के ज़रिए arbitrary code execution करा सकता है
      • राय यह भी है कि इस CVE के अलावा भी Git में कई vulnerabilities हैं, इसलिए उन्हें साथ में देखना चाहिए

    • यह साधारण लेकिन असुविधाजनक सच्चाई बताई गई कि arbitrary file write संभव हो तो अक्सर बात RCE तक पहुँच जाती है

  • ad-hoc DSL से config files लिखने के ख़तरे की बात की गई

    • अक्सर grammar की कोई औपचारिक specification नहीं होती, और parsing का असली आधार अलग-अलग जगह फैला self-made serialization/deserialization implementation होता है

    • अगर दोनों अलग हो जाएँ, जैसे parser में नई syntax जोड़ दी लेकिन writer में नहीं, तो parser difference की वजह से बड़ा खतरा पैदा हो सकता है

    • सीख: एक source of truth होना चाहिए, और उस पर निर्भर हिस्सों को उसी आधार पर auto-generate करना चाहिए

    • यह भी बताया गया कि यह bug source of truth वाली समस्या से अलग है

      • यह एक शुद्ध logic error है, और अगर Unix में ऐसी कोई standard system library होती, तो वही समस्या वहाँ भी ठीक इसी तरह फट सकती थी
      • अगर ऐसी standard library में यह issue होता, तो असर कहीं ज़्यादा गंभीर होता; अभी नुकसान अपेक्षाकृत कम है क्योंकि यह ज़्यादातर developers तक सीमित है

    • यहाँ इस्तेमाल किया गया DSL (ini file format) भले ad-hoc हो, लेकिन इतना common, familiar और व्यवस्थित है कि व्यावहारिक रूप से specification जैसा ही माना जा सकता है

      • राय यह है कि bug की जड़ format नहीं बल्कि बीच में डाला गया hand-coded parser (या lexer) है, और अब ऐसे code लिखना बंद कर देना चाहिए
      • कुछ जगह clever hand-coding की ज़रूरत अभी भी हो सकती है, लेकिन data interchange formats के लिए इसका इस्तेमाल बिल्कुल नहीं होना चाहिए; ini चाहिए तो toml, वह पसंद नहीं तो JSON, यहाँ तक कि YAML भी ठीक, बहुत दर्द चाहिए तो XML, और अगर binary format पर ज़ोर है तो protobufs
      • नतीजा: अगर आप programming language author नहीं हैं, तो parser खुद न लिखें, library का इस्तेमाल करें

  • किसी ने खुद issue reproduce करके इस repository में डाला

    • तुरंत Git का latest version update करने की कोशिश की, लेकिन अभी Arch पर उपलब्ध नहीं है

    • नए patch आने तक pull से बचने का इरादा है; चिंता जताई गई कि जिन मशहूर repositories में automatic pull लगा है, वहाँ समस्या हो सकती है, इसलिए upgrade में समय लग सकता है

    • यह सवाल भी उठाया गया कि क्या यह vulnerability patch से पहले ही public हो गई थी

      • पहले आम तौर पर ऐसे posts patch आने के महीनों बाद आते थे, लेकिन अब इच्छा यह है कि हर post में साफ़-साफ़ बताया जाए कि "यह अभी सचमुच खतरनाक है" या "यह पहले ही patch हो चुका है, चिंता की बात नहीं", ताकि भ्रम न रहे

  • पुराने exploit में "बस हल्का-सा बदलाव किया" जैसी बात देखकर सवाल उठा कि Git Landlock क्यों नहीं इस्तेमाल करता (Landlock Linux-only sandbox security feature है)

    • सुझाव दिया गया कि git clone में config directory पर read-only access हो, clone target directory पर read/write access हो, और child processes को invoke करने की अनुमति न हो

    • यह भी तंज कसा गया कि exploits में हर बार calculator खोलना कितना cliché हो गया है

    • जवाब में कहा गया कि अगर child process invocation रोकी जाए, तो post-checkout जैसे सारे git hooks टूट जाएँगे

      • ज़रूरत न हो तो seccomp जैसे container environment में git चलाया जा सकता है, लेकिन इससे कई features सीमित हो जाएँगे

    • और यह भी बताया गया कि child processes न हों तो ssh के जरिए git का इस्तेमाल भी नहीं हो पाएगा

  • पूछा गया कि क्या Homebrew खुद समस्या का हिस्सा है, यानी क्या वह recursive clone करता है

    • इस code में इसकी संभावना मिली

    • राय यह रही कि Homebrew का मकसद ही repository code चलाना है, इसलिए recursive clone न हो तो उल्टा अजीब लगेगा

      • RCE तभी मायने रखता है जब cloned data को execute नहीं होना चाहिए, और ऐसे cases कम होते हैं

  • Jon Postel की CR+LF पर कही बात याद करके पुरानी यादें ताज़ा की गईं

    • इस लेख का लिंक दिया गया, और कहा गया कि 2003 की तुलना में आज वह सलाह शायद सही नहीं बैठती
    • Mark Crispin की उस समय की व्याख्या का हवाला देते हुए कहा गया कि लोग बात को गलत समझ रहे थे, और इसे 1990 के दशक के अंत में Daniel J. Bernstein द्वारा human-machine conversion (parsing/quoting) से पैदा होने वाली समस्याओं की ओर ध्यान दिलाने से जोड़ा गया
    • देखा गया कि 25 साल बाद भी CR को escape न करने वाले quoter code की समस्या दोहराई जा रही है, और fix होने के बाद भी सभी whitespace की जाँच नहीं हो रही
    • git blame के मुताबिक समस्या वाला code 19 साल पहले लिखा गया था, जो Bernstein के 10 साल बाद के retrospective के समय के आसपास का है
    • संबंधित commit, qmail paper आदि अतिरिक्त सामग्री भी साझा की गई
    • आखिर में ज़ोर दिया गया कि 20वीं सदी में मुश्किल से सीखे गए सबक 21वीं सदी में भी बार-बार सीखने पड़ रहे हैं

  • Homebrew में git 2.50.1 update अभी तक नहीं आया, इसलिए शायद थोड़ा और इंतज़ार करना पड़े

    • update के लिए इस issue या brew install git --HEAD का सुझाव दिया गया

  • यह भी साझा किया गया कि Homebrew और Debian Bookworm, दोनों अभी भी vulnerable versions दे रहे हैं

    • बाद में बताया गया कि अब Homebrew में 2.50.1 version उपलब्ध है

  • यह सोचने वाली बात उठाई गई कि अगर directory listing लाने वाली system call को ऐसे file names मिलें जिनमें ASCII control characters (bytes) हों, तो क्या उसे उन files के अस्तित्व से इनकार कर देना चाहिए, disk corruption मानना चाहिए, या कुछ और करना चाहिए

    • यह भी कहा गया कि मौजूदा locale में उन bytes का कोई और मतलब हो सकता है, क्योंकि Windows की तरह file names को uniformly UTF-16 नहीं माना जाता, इसलिए unexpected situations बन सकती हैं

    • संक्षेप में कहा गया कि Unix-जैसी systems में file names (और दूसरी strings) सिर्फ bytes की arrays होने के कारण ऐसी समस्याएँ पैदा होती हैं