漏洞复现-GitLab任意读取文件(CVE-2023-2825)

1.漏洞描述

GitLab是一个用于仓库管理系统的开源项目，其使用Git作为代码管理工具，可通过Web界面访问公开或私人项目。据悉,该漏洞影响 GitLab社区版(CE)和企业版(EE)的 16.0.0 版本,其它更早的版本几乎都不受影响。

   该漏洞存在于GitLab CE/EE版本16.0.0中，当嵌套在至少五个组中的公共项目中存在附件时，可在未经身份验证的情况下通过uploads功能遍历读取任意文件，导致敏感信息泄露。

2.影响版本

GitLab CE 16.0.0  社区版

GitLab EE 16.0.0  企业版 

3.影响范围

4.漏洞分析

这个POC看起来很奇怪，有着数个目录，后半部分的URL还被编码了。 
我们先来看看gitlab的架构 
Nginx( C )-> Workhorse(gitlab自己的中间件 Go) -> Unicorn(新版本为 puma) (Ruby) 
用户发起的请求要经过两个中间件的转发才会到puma后端

Nginx

用户发起的请求 第一步需要先通过nginxnginx会对uri进行校验如果目录穿越超过了目录层数 就会返回400状态码 请求也不会转发到后端

但是如果我们把目录穿越的部分进行url编码呢?
/a/b/%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F

结果还是400
分析nginx的代码后，不难发现在处理复杂的URI时，nginx会对URL编码的部分进行解码。

因此，我们需要先绕过nginx，一旦通过了校验，nginx会将未经解码处理的URL传递给Workhorse。

Workhorse

下载文件的请求在Workhorse 里面没有命中自定义的路由 会直接转发到puma

Puma

在Rails中，处理路由的方式略有不同于nginx。Rails匹配路由参数时，不会对URL进行解码。让我们来看一下与uploads相关的路由，其中filename参数使用了正则表达式来匹配URL / 后面的字符串。

Rails 会对获取到的参数进行 URL 解码，并成功将带有 “../“ 的路径作为参数传递给 uploads#show，最终成功读取任意文件。

Poc:

/groups1/groups2/groups3/groups4/groups5/groups6/groups7/groups8/groups9/gitlab/uploads/c5a76aa5602d0eae7ef601eacfe59f64/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd

5.修复建议

目前该漏洞已经修复，受影响用户可升级到以下版本：

GitLab CE/EE版本：>= 16.0.1

https://gitlab.com/gitlab-org/gitlab