1.漏洞描述

GitLab是一個用于倉庫管理系統(tǒng)的開源項(xiàng)目，其使用Git作為代碼管理工具，可通過Web界面訪問公開或私人項(xiàng)目。據(jù)悉,該漏洞影響 GitLab社區(qū)版(CE)和企業(yè)版(EE)的 16.0.0 版本,其它更早的版本幾乎都不受影響。

?? 該漏洞存在于GitLab CE/EE版本16.0.0中，當(dāng)嵌套在至少五個組中的公共項(xiàng)目中存在附件時，可在未經(jīng)身份驗(yàn)證的情況下通過uploads功能遍歷讀取任意文件，導(dǎo)致敏感信息泄露。

2.影響版本

GitLab CE 16.0.0? 社區(qū)版

GitLab EE 16.0.0? 企業(yè)版?

3.影響范圍

4.漏洞分析

這個POC看起來很奇怪，有著數(shù)個目錄，后半部分的URL還被編碼了。 
我們先來看看gitlab的架構(gòu) 
Nginx( C )-> Workhorse(gitlab自己的中間件 Go) -> Unicorn(新版本為 puma) (Ruby) 
用戶發(fā)起的請求要經(jīng)過兩個中間件的轉(zhuǎn)發(fā)才會到puma后端

Nginx

用戶發(fā)起的請求 第一步需要先通過nginxnginx會對uri進(jìn)行校驗(yàn)如果目錄穿越超過了目錄層數(shù) 就會返回400狀態(tài)碼 請求也不會轉(zhuǎn)發(fā)到后端

但是如果我們把目錄穿越的部分進(jìn)行url編碼呢?
/a/b/%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F

結(jié)果還是400
分析nginx的代碼后，不難發(fā)現(xiàn)在處理復(fù)雜的URI時，nginx會對URL編碼的部分進(jìn)行解碼。

因此，我們需要先繞過nginx，一旦通過了校驗(yàn)，nginx會將未經(jīng)解碼處理的URL傳遞給Workhorse。

Workhorse

下載文件的請求在Workhorse 里面沒有命中自定義的路由 會直接轉(zhuǎn)發(fā)到puma

Puma

在Rails中，處理路由的方式略有不同于nginx。Rails匹配路由參數(shù)時，不會對URL進(jìn)行解碼。讓我們來看一下與uploads相關(guān)的路由，其中filename參數(shù)使用了正則表達(dá)式來匹配URL / 后面的字符串。

Rails 會對獲取到的參數(shù)進(jìn)行 URL 解碼，并成功將帶有 “../“ 的路徑作為參數(shù)傳遞給 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.修復(fù)建議

目前該漏洞已經(jīng)修復(fù)，受影響用戶可升級到以下版本：

GitLab CE/EE版本：>= 16.0.1

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