- Unix आधारित सिस्टम पर अगर किसी अविश्वसनीय repository को
git clone --recursive से clone किया जाए, तो CVE-2025-48384 के कारण remote code execution संभव हो सकता है, इसलिए Git और Git-embedded software को update करना ज़रूरी है
- मूल कारण यह है कि Git config को पढ़ने और फिर से लिखने की प्रक्रिया में carriage return(
\r) को संभालने का तरीका अलग है, जिससे validated value और वास्तव में इस्तेमाल होने वाली value में mismatch पैदा होता है
- अगर
.gitmodules में submodule path के अंत में \r जोड़ दिया जाए, तो checkout path validation के बाद किसी दूसरे path में बदल सकता है
- Windows में file name में control characters की अनुमति नहीं होती, इसलिए यह सीधे प्रभावित नहीं है, लेकिन macOS, CVE-2024-32002 और CVE-2025-48384 दोनों से प्रभावित है
- patch में
\r वाले config values को quotes में wrap करने के लिए बदलाव किया गया है, जिससे .git के अंदर file write और Git hook creation जैसे attack paths रुकते हैं
भेद्यता का सार और तुरंत उठाए जाने वाले कदम
- CVE-2025-48384 Git की एक भेद्यता है, जो Unix आधारित platforms पर किसी अविश्वसनीय repository को
git clone --recursive से clone करने पर remote code execution तक ले जा सकती है
- patched Git versions पर update करें, और GitHub Desktop सहित Git-embedded software को भी साथ में update करना चाहिए
- अगर command line पर सिर्फ
git clone चलाया जाए, तो submodules अपने-आप clone नहीं होते
- mitigation के लिए पहले
git clone को --recursive के बिना चलाया जा सकता है, फिर .gitmodules सुरक्षित है या नहीं यह जांचकर submodules को initialize किया जा सकता है
- GitHub Desktop default रूप से recursive option के साथ clone करता है, इसलिए इस behavior में यह प्रभावित हो सकता है
carriage return और Git config files
- carriage return ASCII character number 13 है, और C strings में इसे
\r के रूप में लिखा जाता है
- Unix line separation के लिए केवल LF यानी
\n का उपयोग करना चाहता था, लेकिन Windows और कई internet protocols CR+LF यानी \r\n का उपयोग करते हैं
- Git का
.ini style config format सिर्फ user config files में ही नहीं, बल्कि repository में शामिल .gitmodules file में भी इस्तेमाल होता है
- DOS line ending support करने के लिए Git config parser character पढ़ते समय इस तरह काम करता है
- अगर current character
\r है, तो अगला character देखता है
- अगर अगला character
\n है, तो \r को हटा देता है और newline की तरह process करता है
- अगर अगला character
\n नहीं है, तो अगले character को वापस रख देता है और \r को ही return करता है
- यह processing line-by-line लागू होती है, इसलिए अगर कोई line CR पर खत्म होती है, तो पूरे file format से अलग उस CR को हटाया जा सकता है
पढ़ने और लिखने में असंगति
- Git सिर्फ config files पढ़ता ही नहीं, बल्कि
git config की तरह config values लिखते समय भी key = value pairs रिकॉर्ड करता है
- पुराना code config value को दोबारा लिखते समय केवल इन स्थितियों में value को double quotes में wrap करता था
- जब value whitespace से शुरू होती हो
- जब value के अंदर
; या # हो
- जब value whitespace पर खत्म होती हो
- दूसरी ओर, config reading code double-quoted strings को support करता है, इसलिए
write_pair द्वारा लिखी गई value को बाद में फिर पढ़ते समय अंतिम \r हट सकता है
- उदाहरण के लिए अगर config file में
key = "foo^M" है, तो दोबारा लिखे जाने के बाद यह key = foo^M बन सकता है
- यहां
^M literal CR character है
- जब यह behavior किसी अविश्वसनीय
.gitmodules value के साथ जुड़ता है, तो submodule path handling अस्थिर हो जाती है
submodule path confusion और प्रभाव का दायरा
- Unix आधारित systems में file names में control characters डाले जा सकते हैं, इसलिए
.gitmodules के path में CR शामिल value डाली जा सकती है
- उदाहरण इस तरह है
[submodule "foo"]
path = "foo^M"
- जब यह value Git config code द्वारा
.git/modules/foo/config में लिखी जाती है, तो यह कुछ इस तरह बन सकती है
[core]
workdir = ../../../foo^M
- validation पहले ही
.gitmodules से पढ़े गए अविश्वसनीय path पर पूरी हो चुकी होती है
- इसके बाद जब config को फिर से पढ़ा जाता है, तो अंतिम
\r हट जाने पर Git validated path से अलग path का उपयोग करने लगता है
- नतीजतन, submodule clone के दौरान
path = ... से पढ़ी गई location और वास्तव में लिखी/इस्तेमाल की गई location अलग हो सकती है
- यह सिद्धांत CVE-2024-32002 जैसा है
- CVE-2024-32002 में submodule में case sensitivity का उपयोग करके Git को भ्रमित किया जाता है
- CVE-2025-48384 के लिए ऐसा file system चाहिए जो file names में control characters की अनुमति देता हो
- Windows file names में control characters की अनुमति नहीं देता, इसलिए यह इस खास bug से सीधे प्रभावित नहीं है
- macOS, CVE-2024-32002 और CVE-2025-48384 दोनों से प्रभावित है
patch और attack की संभावना
- patch में
write_pair को बदलकर यह किया गया है कि अगर value में \r हो, तो string को quotes में wrap किया जाए
- बदलाव सरल है:
; या # की जांच करने वाली condition में '\r' जोड़ा गया है
for (i = 0; value[i]; i++)
- if (value[i] == ';' || value[i] == '#')
+ if (value[i] == ';' || value[i] == '#' || value[i] == '\r')
quote = "\"";
- path confusion की वजह से submodule की malicious files को file system पर लगभग arbitrary location पर रखा जा सकता है, और validation bypass होने के कारण repository के बाहर के symbolic links को भी follow किया जा सकता है
- सबसे सीधा exploit यह है कि
.git directory के अंदर file लिखी जाए और Git hook script बनाई जाए, ताकि Git जब hook चलाए तो attacker-controlled code execute हो
- दूसरी संभावना
.git/config को overwrite करने की है
- अभी PoC public नहीं हुआ है, लेकिन कहा गया है कि CVE-2024-32002 exploit को लगभग मामूली बदलाव के साथ इस्तेमाल किया जा सकता है
- fix commit की tests attack method के बारे में बड़ा संकेत दे सकती हैं
बार-बार सामने आने वाली CR समस्या और सीख
- यह पहली बार नहीं है कि carriage return ने Git में समस्या पैदा की हो
- जनवरी में RyotaK ने carriage return के जरिए धोखा दिए जा सकने वाले credential helper protocol issue को खोजा
- 2023 में André Baptista और Vítor Pinho ने config parsing की logical error वाली CVE-2023-29007 खोजी थी
- यह भेद्यता C language की समस्या नहीं, बल्कि लगभग हर language में हो सकने वाली logical error के ज्यादा करीब है
- समानता यह है कि ये Git के internal components के बीच या Git और external processes के बीच inter-process communication में होती हैं
- इसकी संरचना HTTP के CRLF injection, request smuggling, और SMTP smuggling जैसी लगती है
- पहले internet ने Postel के robustness principle “be conservative in what you send, be liberal in what you accept” पर भरोसा किया था, लेकिन अब यह सबसे समझदारी वाली सलाह नहीं रह गई हो सकती
- इस विषय पर RFC 9413 में और विस्तार से चर्चा है
आभार और संबंधित fixes
- यह भेद्यता Git audit के दौरान खोजी गई थी
- उसी release में अलग-अलग severity वाले दूसरे bugs भी साथ में fix किए गए
- G-Research Open Source ने इस काम को संभव बनाया
अभी कोई टिप्पणी नहीं है.