GitLab Addresses Critical Path Traversal Vulnerability - PoC Released

In a bid to thwart a severe security flaw, GitLab has urgently dispatched an update, version 16.0.1. This security patch addresses a critical path traversal flaw, with a CVSS v3.1 score of 10.0, the highest severity rating possible. The flaw is identified as CVE-2023-2825.

GitLab, a widely-used web-based Git repository platform designed to facilitate remote code management for developer teams, boasts approximately 30 million registered users, with a million being paying customers.

The vulnerability at hand, identified in both GitLab Community Edition (CE) and Enterprise Edition (EE) version 16.0.0, was brought to light by a security researcher operating under the alias 'pwnie.' The finding was submitted through the project's HackOne bug bounty program.

Interestingly, only version 16.0.0 of GitLab CE and EE is affected, older versions are not susceptible to this flaw.

The flaw originates from a path traversal issue that gives an unauthenticated attacker the ability to read arbitrary files on the server, under specific conditions. This access becomes possible when an attachment is present in a public project that's nested within at least five groups.

Exploiting CVE-2023-2825 has potentially catastrophic implications, exposing sensitive data including, but not limited to, proprietary software code, user credentials, tokens, files, and other private information.

The nature of the issue suggests that it pertains to GitLab's method of managing or resolving paths for attached files, specifically when these files are nested within several layers of the group hierarchy. However, GitLab hasn't divulged much information about the flaw, likely due to its critical severity and the recency of its discovery.

CVE-2023-2825 - A Path Traversal Vulnerability Checker released

A security firm, OccamSec has released the PoC code that checks or verifies for the GitLab CVE-2023-2825 vulnerability. This PoC leverages a path traversal vulnerability to retrieve the /etc/passwd file from a system running GitLab 16.0.0.

OccamSec does mention that, the vulnerability has an interesting requirement where the project needs to be nested in at least 5 groups. 

" In our testing, we found a direct correlation with the amount of groups and the directories you can traverse. The rule seems to be N + 1, meaning if you wish to traverse 10 directories you need to have 11 groups" - OccamSec wrote.

On a standard Gitlab install, file attachments are uploaded to /var/opt/gitlab/gitlab-rails/uploads/@hashed/<a>/<b>/<secret>/<secret>/<file>. So if you want to reach the filesystem root, you must go back 10 directories and therefore you need 11 groups.

When you upload a file as an attachment on a GitLab issue, a request is sent to POST - /:repo/upload. This returns a JSON response with the file URL, allowing you to access the file.

The file URL is composed of /:repo/uploads/:id/:file where :file is the file name itself. Replacing :file with any file path will cause GitLab to return the requested file. GitLab fails to sanitize this file path, leading to path traversal.

To successfully exploit this vulnerability, you must URL encode the / in the file path. GitLab will read this as a value and decode it internally. Failing to encode it will lead to GitLab interpreting the / in the file path as part of the route.

The Urgency of the Update

Recognizing the severity of the issue, GitLab has emphasized the urgent need for all users running the affected version to upgrade their installations to the latest version without delay.

In GitLab's security bulletin, they reiterate the importance of this update, stating, "We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible."

This advisory is all-encompassing, including all types of product deployment (omnibus, source code, helm chart, etc.) which means all deployments are potentially affected.

The Mitigating Factor

On a lighter note, the vulnerability only becomes a concern under specific conditions. That is, an attachment must exist in a public project nested within at least five groups - a structure not commonly seen in all GitLab projects.

However, regardless of project structure, all users operating GitLab 16.0.0 are strongly advised to promptly update to version 16.0.1 to avert any potential risks. Unfortunately, as of now, no workaround exists for this vulnerability.

Updating GitLab Installation

For users seeking to upgrade their GitLab installation, comprehensive instructions are provided on the project's update page. For guidance on updating GitLab Runner, refer to this guide.

In light of this vulnerability, prompt action in applying this security patch is paramount in maintaining the safety and integrity of your data on GitLab.