Headline

CVE-2022-3283: DOS via issue preview and markdown preview (#361982) · Issues · GitLab.org / GitLab · GitLab

A potential DOS vulnerability was discovered in GitLab CE/EE affecting all versions before before 15.2.5, all versions starting from 15.3 before 15.3.4, all versions starting from 15.4 before 15.4.1 While cloning an issue with special crafted content added to the description could have been used to trigger high CPU usage.

2 years ago

CVE

Open in Source

#vulnerability #ddos #dos #git #auth #docker

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

Unauthed via Markdown Preview API: https://hackerone.com/reports/1544465
REDoS via create/update issue: https://hackerone.com/reports/1543606

A fourth report, DoS via moving an issue, has a separate cause and separate issue: https://gitlab.com/gitlab-org/gitlab/-/issues/362379+ / 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

Given an authorized user (on GitLab.com - anyone can self-register. On EE - depends on instance configuration).
Create an issue with the following description (provided a one-line python script to avoid bloating):
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: