Denial-of-service attack in Markdown parser

HackerOne report #1077021 by phli on 2021-01-12, assigned to @dcouture:

Report

NOTE! Thanks for submitting a report! Please replace all the (parenthesized) sections below with the pertinent details. Remember, the more detail you provide, the easier it is for us to triage and respond quickly, so be sure to take your time filling out the report!

Summary

I really appreciate the help fom GitLab security group in verifying the existence of the bug.

An attacker prepares the attack by uploading a special Markdown file to a repository in a deployed GitLab server or GitLab.com. When any user tries to view the Markdown file in the browser, the server-side can consume 100% CPU usage for more than half a minute in the particular CPU core that handles the job. When multiple such Markdown file views happen simultaneously, all CPU cores can be occupied, which finally leads to DoS.

Steps to reproduce

Known vulnerable attack surfaces. 1) Self-deployed GitLab server instance, version 13.7.3 (on Linux Debian 9); and 2) GitLab.com. Probably there exist many other vulnerable cases I haven't tested.
2 The attacker is privileged to edit a repository that belongs to the victim server. The attacker uploads special Markdown files. Multiple users (can also be attackers) try to visit and view the page at the same time, CPU cores can be all occupied. No user authentication is needed if the repository is set as publicly accessible.

To reproduce

A special Markdown file is uploaded to the victim GitLab server. For example, the 600000.md in https://gitlab.com/ppnuts/PoC
A user tries to view the Markdown file by clicking on the file name. The user is then directed to https://gitlab.com/ppnuts/PoC/-/blob/master/600000.md
The user shall observe a loading shape on the screen without actually get the rendered content. Check screenshot below.
.
However, at this moment, the CPU on the server-side is 100% consumed. For example, when I do a top on the server-side, I can observe the process takes 100% CPU usage. Check screenshot below.
If multiple users view the Markdown file simultaneously, all CPU cores can be occupied. Or simply just several browser instances.
After a long time, the client-side might show Error loading viewer. Check screenshot below.
.
And the server-side CPU is then released.

Impact

If all CPU cores are occupied, other resources become unavailable.

Examples

Please check https://gitlab.com/ppnuts/PoC.

What is the current bug behavior?

Client-side cannot load/render the Markdown file on time; Server-side CPU is over-consumed. The whole services can be down if all CPU cores are occupied.

What is the expected correct behavior?

The Markdown file shall be rendered correctly on time.

Relevant logs and/or screenshots

See above.

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Installed using apt-get. Host environment:

$uname -a  
Linux labpc 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux

System information  
System:		Debian 9.13  
Current User:	git  
Using RVM:	no  
Ruby Version:	2.7.2p137  
Gem Version:	3.1.4  
Bundler Version:2.1.4  
Rake Version:	13.0.1  
Redis Version:	5.0.9  
Git Version:	2.29.0  
Sidekiq Version:5.2.9  
Go Version:	unknown

GitLab information  
Version:	13.7.3  
Revision:	1ef3b81f122  
Directory:	/opt/gitlab/embedded/service/gitlab-rails  
DB Adapter:	PostgreSQL  
DB Version:	12.4  
URL:		http://137.189.89.174  
HTTP Clone URL:	http://137.189.89.174/some-group/some-project.git  
SSH Clone URL:	git@137.189.89.174:some-group/some-project.git  
Using LDAP:	no  
Using Omniauth:	yes  
Omniauth Providers:

GitLab Shell  
Version:	13.14.0  
Repository storage paths:  
- default: 	/var/opt/gitlab/git-data/repositories  
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell  
Git:		/opt/gitlab/embedded/bin/git

Impact

Turn down the GitLab server, and make all services unavailable, i.e., DoS.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section:

Edited Aug 25, 2021 by Nick Thomas