Denial-of-service attack in Markdown parser
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!
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.
A special Markdown file is uploaded to the victim GitLab server. For example, the
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
topon 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.
If all CPU cores are occupied, other resources become unavailable.
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
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
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://220.127.116.11 HTTP Clone URL: http://18.104.22.168/some-group/some-project.git SSH Clone URL: email@example.com: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
Turn down the GitLab server, and make all services unavailable, i.e., DoS.
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: