CVE-2025-48384漏洞揭示，在类Unix平台上，使用git clone --recursive克隆不受信任的仓库可能导致远程代码执行。该漏洞源于对回车符的处理问题，建议用户更新至修复版本，包括GitHub Desktop等嵌入Git的软件。

文章主要内容总结：

标题：CVE-2025-48384：通过回车符破坏Git并实现远程代码执行

发布日期：2025年7月8日

主要内容：

1. 漏洞概述：

   • 在类Unix平台上，使用git clone --recursive克隆不受信任的仓库时，可能导致远程代码执行（RCE）。建议用户更新到修复版本的Git及其嵌入Git的软件（如GitHub Desktop）。

2. 背景知识：

   • 回车符（Carriage Return, CR）和换行符（Line Feed, LF）的历史由来及其在不同操作系统中的处理方式。Unix系统使用LF（\n），而Windows和某些互联网协议使用CR+LF（\r\n）。

3. 漏洞细节：

   • Git的配置文件格式（.ini风格）在处理DOS换行符时存在漏洞。具体来说，get_next_char函数在读取配置时会剥离回车符，但在写入配置时，如果值中包含回车符，可能会导致配置解析错误。
   • 在.gitmodules文件中，路径条目可能包含控制字符（如^M），Git在读取和写入这些路径时，可能会因为剥离回车符而导致路径不一致，从而在克隆子模块时将内容写入错误的路径。

4. 漏洞利用：

   • 通过构造包含回车符的.gitmodules文件，攻击者可以混淆Git的配置解析，导致子模块克隆时写入错误的路径，进而实现远程代码执行。
   • 该漏洞在类Unix系统上有效，Windows系统不受直接影响，因为Windows不允许文件名中包含控制字符。

5. 缓解措施：

   • 在命令行中使用git clone时，避免使用--recursive选项，先检查.gitmodules文件的安全性，再手动初始化子模块。
   • GitHub Desktop默认使用递归克隆，因此使用GitHub Desktop时可能触发该漏洞。

6. 修复方案：

   • 修复方案非常简单，确保在write_pair函数中，写入包含回车符的字符串时进行引号包裹。具体修复代码如下： c for (i = 0; value[i]; i++) <ul> <li>if (value[i] == ';' || value[i] == '#')</li> <li>if (value[i] == ';' || value[i] == '#' || value[i] == '\r') quote = "\"";

7. 相关漏洞：

   • 该漏洞与之前的CVE-2024-32002（子模块路径大小写敏感性问题）类似，但要求文件系统允许文件名中包含控制字符。
   • 此前，回车符在Git的凭证助手协议中也曾引发问题，配置解析逻辑错误也曾被发现。

8. 总结与反思：

   • 该漏洞并非C语言特有的问题，而是逻辑错误，可能出现在几乎所有编程语言中。这与HTTP中的CRLF注入攻击类似，提醒我们在处理输入时应更加谨慎，避免过于宽松的接受规则。

9. 其他修复：

   • 该漏洞是Git审计过程中发现的多个漏洞之一，其他漏洞也在今天的发布中修复。感谢G-Research Open Source的支持。

图片标记： - GitHub Desktop Demo

1. 关于Git更新的延迟

   • 观点：用户对Homebrew尚未更新到Git 2.50.1表示失望。
   • 引用：
     • "guess I have to wait a bit more... no update to git 2.50.1 on Homebrew yet."
     • “看来我还得再等等……Homebrew上还没有更新到Git 2.50.1。”

2. C语言字符串解析的安全性问题

   • 观点：用户对C语言中字符串解析的安全性问题表示担忧，并质疑为何更安全的解析方案未能普及。
   • 引用：
     • "The year is 2025 and we are still cleaning up string parsing RCEs in C."
     • “到了2025年，我们仍在清理C语言中的字符串解析远程代码执行漏洞。”

3. Homebrew的潜在问题

   • 观点：用户质疑Homebrew是否可能因递归克隆而带来安全问题。
   • 引用：
     • "Would homebrew itself be problematic here? Does it do recursive cloning?"
     • “Homebrew本身会是个问题吗？它是否进行递归克隆？”

4. 远程代码执行的严重性

   • 观点：用户探讨了Git子模块克隆中的远程代码执行漏洞的严重性，并解释了其工作原理。
   • 引用：
     • "How does this achieve 'remote code execution' as the article states?"
     • “这如何实现文章中提到的‘远程代码执行’？”
     • "So a repository can contain a malicious git hook."
     • “因此，仓库可能包含恶意的Git钩子。”

5. 配置语言的设计问题

   • 观点：用户指出使用临时DSL（领域特定语言）进行配置的潜在问题，强调应有一个统一的解析来源。
   • 引用：
     • "This is a big problem with using ad-hoc DSLs for config."
     • “使用临时DSL进行配置是一个大问题。”
     • "The lesson: have one source of truth."
     • “教训是：要有一个统一的解析来源。”

6. 语言选择与安全性

   • 观点：用户反驳了“所有语言都可能出现逻辑错误”的观点，认为内存安全语言（如Rust）提供了更安全的抽象，减少了逻辑错误的可能性。
   • 引用：
     • "I completely disagree with author's statement."
     • “我完全不同意作者的观点。”
     • "Rust and similar memory safe languages can emulate literally any problem C can make a mine field out of."
     • “Rust等内存安全语言可以模拟C语言中可能出现的任何问题。”
     • "Parse, don't validate is a lot easier to stick to when you're coding in a language designed with a precept like that in mind."
     • “在设计中考虑到这一原则的语言中，遵循‘解析而非验证’要容易得多。”