git repository found 漏洞

2023年4月，漏洞安全研究员Tobias Klein在macOS自带的漏洞Git版本中发现了一个编号为CVE-2023-23947的漏洞。触发条件不复杂：只要用Git命令行工具对一个恶意构造的漏洞仓库执行`git clone`，攻击者就能在受害者机器上执行任意代码。漏洞不需要用户额外确认，漏洞不需要输入密码，漏洞克隆动作本身就是漏洞触发器。

这不是漏洞Git第一次因为"仓库即攻击面"翻车。2022年底，漏洞另一个更隐蔽的漏洞漏洞被披露——攻击者可以构造一个仓库，让`git clone`在克隆过程中直接覆写系统文件。漏洞原理说出来其实不玄乎：Git在克隆时会根据仓库中的漏洞配置文件创建文件路径，而某些路径可以指向系统敏感目录。漏洞Windows上有人用它覆写了`.gitconfig`，漏洞macOS上则能写到`~/Library`下的漏洞启动项。

为什么"克隆"这个动作这么危险？

大多数开发者对`git clone`的心理模型是"下载代码"。但实际上，Git在克隆阶段做的事情远不止下载。它会解析仓库中的`.gitmodules`、`config`、`hooks`等元数据文件，然后根据这些内容执行一系列本地操作——创建目录、写文件、甚至运行钩子脚本。问题就出在这里：这些元数据来自远端仓库，完全由攻击者控制。

一个具体的攻击场景是这样的：攻击者在GitHub上建一个看起来正常的项目，README写得像模像样，star数刷一刷。然后他在`.git/config`里塞入一个恶意的`core.fsmonitor`配置项，指向一个会被自动执行的脚本路径。受害者clone之后，Git在初始化仓库时读取这个配置，脚本就被拉起来了。整个过程没有任何弹窗提示。

真实的攻击面比想象中大

Git的钩子机制本来是给开发者做自动化用的，pre-commit、post-checkout这些钩子能在特定操作后执行脚本。但克隆一个仓库时，Git默认不会执行仓库自带的钩子——这是有意的安全设计。问题是，某些版本的Git在处理`core.hooksPath`配置时存在绕过，能把钩子目录指向仓库内的恶意脚本。

Klein在macOS上的发现更直接：Git for Mac在处理仓库路径时存在符号链接处理缺陷，攻击者可以构造一个包含符号链接的仓库，让Git在克隆时把文件写到链接指向的系统位置。他演示了覆写`~/Library/LaunchAgents`下的plist文件，配合一个简单的重启触发条件，就能实现持久化。

Windows平台上的情况略有不同但同样不乐观。Git for Windows在处理长路径和NTFS备用数据流时有过几个漏洞，攻击者可以把恶意代码藏在仓库文件的备用数据流里，克隆后通过Git的自动执行机制触发。微软和Git社区为此打了多次补丁，但每次修复都伴随着新的绕过方式出现。

防御没那么复杂，但需要改变习惯

最有效的缓解措施其实很朴素：在克隆不受信任的仓库之前，先看一眼它的`.git/config`和`.gitmodules`有没有可疑内容。用`git clone --no-checkout`先只拉元数据不检出文件，检查完再决定是否继续。或者更彻底一点，在容器或虚拟机里克隆陌生仓库。

Git 2.38之后的版本默认启用了`protocol.file.allow`的限制，对本地路径克隆做了更严格的约束。2.40版本则加强了对`core.fsmonitor`和`core.hooksPath`的校验。如果你还在用系统自带的旧版Git——macOS Ventura自带的是2.37——建议手动升级。

这件事的本质是：Git仓库不只是一堆代码文件，它是一个带有可执行语义的数据包。你对一个仓库执行clone，相当于让Git解析并部分执行这个数据包里的指令。把"克隆"当成纯粹的只读操作，是很多安全问题的认知根源。