Reproducible Vulnerabilities

Introduction

GitLab is transparent about the security bugs it has fixed. This transparency creates opportunities for learning, upskilling, and breaking into the InfoSec industry.

• Anyone can learn how to identify and/or fix security issues in a real product.
• AppSec job candidates and new team members get insight into the bugs we face, and our processes.

The reproducible vulnerabilities are structured with expandable hint sections so that you can adapt the content to your desired challenge level. We want it to be approachable to anyone.

If this sort of thing interests you, we encourage you to check for open roles in our Security Team and to participate in our Bug Bounty program on HackerOne (it pays real money!).

Important Information & FAQ

Warning

Installing software with known vulnerabilities carries inherent risk. Do not allow untrusted connections. Ideally run vulnerable instances locally or in a cloud environment allow-listed to your home IP only. Remove your practice instances when you have finished with them.

Won’t this page help attackers?

That is not the intent of this page. The intent of this page is to educate both team members and those in the community who are interested in learning about security.

GitLab’s disclosure policy is to make patched vulnerabilities public after 30 days. See our process for disclosing security issues. These disclosed issues include steps to reproduce, often include videos or screenshots, and links to the code that patches the issue.

Disclosed vulnerabilities, including those listed here, are already publicly accessible in our issue tracker. This page will never give more assistance or more detail than already exists in those public issues.

What if I find something odd?

If you discover a security issue that still affects current versions of GitLab, for example an incomplete fix, please follow the steps in our Responsible Disclosure Policy.

Reproducible Vulnerabilities

Stored XSS in 15.0

In GitLab 15.0 a malicious user could create a stored XSS payload. See if you can figure out how.

Installation

1. Follow the steps to install a Docker version of GitLab. Depending on your setup, the command will look something like:

1
2
3
4
5
6
7
8
9

sudo docker run --detach \
  --hostname gitlab.example.com \
  --publish 8929:80 --publish 8922:22 \
  --name gitlab15.0.0 \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:15.0.0-ee.0

After installation is complete you can get the root Administrator user password with docker exec -it gitlab15.0.0 grep 'Password:' /etc/gitlab/initial_root_password.

1. Register a user to be the attacker
2. Sign in as the Administrator and approve the new user. Sign out.
3. Sign in as the attacker
4. Good hunting!

Bug hunting

Cross-Site Scripting, or XSS, is an attack where attacker-defined javascript is injected into a page the victim is browsing. This can let an attacker impersonate a victim and click on things, submit forms, view data, watch what is typed, and more.

Vulnerability Details

Remediation

Once you’ve reproduced the bug, have a go at fixing it locally.

Done that? Now compare your proposed change to our patch(es).

Links

• GitLab Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/363293
• Patch: https://gitlab.com/gitlab-org/gitlab/-/commit/e61e9b9434e2198c4c1d5cf6b4531eb4323c3575
• Release Post: https://about.gitlab.com/releases/2022/06/01/critical-security-release-gitlab-15-0-1-released
• CVSS and Bounty: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N (8.7 High / $13,950.00)
• CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1948
• Learn more about XSS:
  • https://owasp.org/www-community/attacks/xss/
  • https://portswigger.net/web-security/cross-site-scripting

Denial of Service in 14.3.5

On GitLab installations before 14.3.6, a malicious actor could perform a Denial of Service attack by submitting crafted issues, MRs, or comments. See if you can figure out how.

Installation

1. Follow the steps to install a Docker version of GitLab. Depending on your setup, the command will look something like:

1
2
3
4
5
6
7
8
9

sudo docker run --detach \
  --hostname gitlab.example.com \
  --publish 8929:80 --publish 8922:22 \
  --name gitlab14.3.5 \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:14.3.5-ee.0

After installation is complete you can view the root user password with docker exec -it gitlab14.3.5 grep 'Password:' /etc/gitlab/initial_root_password. You can use this password to login to the root user on your GitLab instance.

Good hunting!

Bug hunting

Denial of service (DoS) attacks make websites unusable for other users. Typically this happens when a server is so busy dealing with attackers requests that it doesn’t have capacity to respond to normal users.

When using GDK locally, open your CPU & Memory resource monitor and look for abnormally high and sustained usage, particularly of the rails-web and rails-background-jobs processes. If you’re running GitLab in a docker container, try a tool like ctop.

Vulnerability Details

Remediation

Once you’ve reproduced the bug, have a go at fixing it locally. Then compare your proposed change to our patch(es).

Links

• GitLab Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/340449
• Release Post: https://about.gitlab.com/releases/2021/12/06/security-release-gitlab-14-5-2-released/#regular-expression-denial-of-service-via-user-comments
• CVSS and Bounty: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L (4.3 Medium / $610.00 / old bounty range)
• CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39933
• Learn more about Denial of Service:
  • https://owasp.org/www-community/attacks/Denial_of_Service

Contributing

Everyone can contribute to this page - that includes you! You can start by clicking “Open in Web IDE” in the sidebar on the right.

First, find an interesting publicly disclosed vulnerability by looking at our public and closed vulnerability issue list or our security release blog posts. Choose a vulnerability that was fixed in any release prior to the latest security release.

Open a Merge Request to this page, mention @gitlab-com/gl-security/product-security/appsec. It should include:

• A title and non-revealing summary of the vulnerability
• Steps to install the vulnerable version
  • Ideally https://docs.gitlab.com/ee/install/docker.html#install-gitlab-using-docker-engine with a specific version number
  • More complex issues might require a specific installation method, like the Omnibus Linux package.
• A series of progressively revealing hints, so people can try to hunt for the bug themselves but get help if needed. (Remember GitLab is a big product!).
• A link to the GitLab issue, for those who want to follow the original HackerOne report’s steps to reproduce.
• A link to the MR(s) that fixed it.

Here’s a template you can use:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

### `Short title goes here`

On `Free/Premium/Ultimate` installations before `X.Y.Z`, a malicious user could `attack type`. See if you can figure out how.

#### Installation

<!--  Steps to install a vulnerable version //-->

#### Bug hunting

<details  >
  <summary>Hint 1 - where to start looking</summary>
  
<!--  Something that gets people looking in the right place //-->
</details>


<details  >
  <summary>Hint 2</summary>
  
<!--  Another hint. Add as many hints as you want, using already public data. //-->
</details>


<details  >
  <summary>Just tell me how</summary>
  

Follow the steps to reproduce written by [HANDLE](https://hackerone.com/HANDLE) on our GitLab Issue: <https://gitlab.com/gitlab-org/gitlab/-/issues/XXXXXX>

</details>


#### Vulnerability Details

<details  >
  <summary>Click to expand</summary>
  

<!--  Paste the text from the security release post. Adapt if needed. //-->

</details>


#### Remediation

Once you've reproduced the bug, have a go at fixing it locally.

Then compare your proposed change to our patch(es).

<details  >
  <summary>The fix</summary>
  

<!--  Link to the patch, with optional description //-->

</details>


#### Links

<!--  Links go here //-->

View page source - Edit this page - please contribute.