Skip to content

DOS via issue preview and markdown preview

HackerOne report #1543718 by legit-security on 2022-04-18, assigned to @kmorrison1:

There were two additional reports by the same team which, since this was imported first, are being treated as duplicates due to sharing the same root cause

A fourth report, DoS via moving an issue, has a separate cause and separate issue: DOS via move_issue (#362379 - closed) / https://hackerone.com/reports/1543584

Report | How To Reproduce

Report

Summary

Unauthenticated requests to the markdown preview API /api/v4/markdown and authenticated previewing of an issue with a specially-crafted description results in high CPU usage for 60 seconds (request timeout).

Multiple requests can be issued in parallel to create a larger impact.

Steps to reproduce
  1. Given an authorized user (on GitLab.com - anyone can self-register. On EE - depends on instance configuration).
  2. Create an issue with the following description (provided a one-line python script to avoid bloating):
  3. Hit the preview button.

Steps 2&3 can be accomplished via the preview_markdown API endpoint.

The script:
python -c "print('![l' * int(1048576 / 3 - 1) + '\n')"
Note: this is essentially the maximal description size, but a smaller number of repetitions works too.

Impact

After 60 seconds (timeout) - the request fails.
Meanwhile, on the server end, (a single) CPU is burnt out (verified against a local EE instance).
Issuing multiple requests in parallel results in multiple CPUs burn out.
Using the DockerHub image, the entire server is completely unavailable by repeatedly sending a small number of requests repeatedly.

Examples

The bug is instance-independent, works on latest versions. Since GitLab.com is open-core - it would work on GitLab too.

What is the current bug behavior?

The HTTP request fails for timeout while the server is burning CPU.

On the code side:
texts_and_contexts is being initialized here:

def analyze(text, context = {})  
      [@]texts_and_contexts << { text: text, context: context }  
    end

It is then used at banzai/reference_extractor.rb:

def html_documents  
      ...  
      [@]html_documents ||= Renderer.cache_collection_render([@]texts_and_contexts)  
      ...

The CPU utilization is found in the execution of cache_collection_render.

What is the expected correct behavior?

Fix the implementation of cache_collection_render.

Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info

Impact

A complete denial of service of a GitLab EE instance.
As this vulnerability impacts GitLab.com, we assume that this vulnerability opens the door for a DDOS attack.

How To Reproduce

Please add reproducibility information to this section:

Edited by Nick Malcolm