GitLab的文件读取问题导致的RCE漏洞 (gitlab干什么用的)

教程大全 2025-07-13 15:28:43 浏览次

漏洞概述

gitlab CE/EE的8.9、8.10、8.11、8.12以及8.13版本中存在任意文件读取漏洞，攻击者或可利用这个漏洞来获取应用程序中敏感文件的访问权。在获取到这些机密数据之后，攻击者将可以通过执行恶意命令来访问应用程序服务器。

8.9、8.10、8.11和8.12版本中漏洞的CVSS(通用漏洞评分系统)评分为8.4分(CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H)。而8.13版本中相同漏洞的CVSS评分为9.0分，因为在该版本中攻击者完全可以在无需获得管理员权限的情况下利用这个漏洞(CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H)。在所有版本的攻击场景中，GitLab实例需要导入并启用GitLab的输出文件功能。

漏洞分析

GitLab的输出上传功能中存在一个漏洞，这个漏洞将允许攻击者读取GitLab实例中的任意文件，这个漏洞主要是由json.parse中的错误操作而导致的，因为JSON.parse中有可能会包含或引用GitLab导出文件的符号链接。当我准备开始对这个功能进行分析之前，我创建了一个演示仓库，并且还通过项目的管理员面板导出了这个GitLab实例。当我们创建了一个新的项目之后，我们就可以直接导入这些GitLab文件了。演示站点为点击”GitLab导出”)。通常情况下，一个简单的GitLab导出文件一般包含下列文件：

当我们再次加载之前导出的GitLab文件时，将会发生以下几件事情。首先，系统会等待文件写入磁盘(针对大型仓库而言);其次，系统会根据VERSION文件来检测导入项目的版本;最后，GitLab会根据project.json文件来创建一个新的Project实例。

这里的第一步其实并不重要，所以我们现在直接来看一看第二步中系统所执行的相关代码(Gitlab::ImportExport::VersionChecker，第12-18行)：

请各位注意第13行的代码，它将会打开文件并调用readline方法，而这个方法将会返回稳健的第一行数据。第16行代码会捕获系统运行过程中的所有异常，并将异常信息压入errors栈。所有的这些错误都将被发送至前端。接下来，让我们看一看该文件中的第27-31行代码：

这也就意味着，如果文件版本不正确的话，系统会返回一个异常，异常信息中会包含这份GitLab导出文件的版本信息。我们解压GitLab的导出文件，用一个符号链接替换其中的VERSION文件，然后再重新进行压缩。tar文件的结构如下所示：

在创建好了新的GitLab导出文件之后(在导出目录中执行tar -czvf test.tar.gz)，我们就可以加载这份新的GitLab文件了。加载成功之后，因为文件存在版本错误，所以系统将会抛出一个异常，而GitLab实例将会返回第一行错误信息：

但是，这种方法只能读取某个文件的第一行数据。这的确很有意思，但这肯定不是我们想要的，我们想要读取文件的完整内容。于是我们继续分析，看看是否能找到读取完整文件的方法。正如我之前所提到的，导入过程中的第三步就是创建一个新的Project实例。此时，下列代码将会被执行(Gitlab::ImportExport::ProjectTreeRestorer，第11-22行)：

这段代码采用的结构与负责进行版本检测的代码结构非常相似，第13-18行代码可以捕获异常，然后将错误信息压入errors栈。ActiveSupport会使用JSON.parse来解码JSON数据，如果解码失败的话，系统会将待解码的字符串包含在错误信息中一起返回。这也就意味着，如果我们可以让解码器抛出一个异常的话，我们就可以读取稳健的内容了。其实也并不难，先来看看下面给出的这个文件结构：

在这个例子中，project.json文件是一个指向/etc/passwd的符号链接。第14行代码可以调用IO.read方法来读取文件内容。很明显，/etc/passwd文件中并不包含有效的JSON数据。因此，系统肯定会抛出一个异常，而异常信息中将会包含/etc/passwd文件的内容。使用tar来对文件进行压缩，然后准备上传[演示文件下载-test.tar.gz(F130233)]。文件导入成功之后，我们就可以从错误信息中获取链接文件的内容了：

需要声明的是，这并不是我自己的/etc/passwd文件。下面给出的是gitlab.com中/etc/passwd文件的最后五行数据：