Denial-of-service attack in Markdown parser
HackerOne report #1077021 by phli
on 2021-01-12, assigned to @dcouture:
Report | Attachments | How To Reproduce
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 atop
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: