Server Denial-Of-Service through uncontrolled resource consumption when viewing a maliciously crafted cargo.toml file.
:warning: **Please read [the process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.**
**[HackerOne report #2648665](https://hackerone.com/reports/2648665)** by `l33thaxor` on 2024-08-09, assigned to @kmorrison1:
[Report](#report) | [Attachments](#attachments) | [How To Reproduce](#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 https://gitlab.com/gitlab-org/gitlab/-/issues/431924 , 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:
1. Create a new project or open an existing one.
2. Push the malicious `cargo.toml` file to the repository.
3. Open the file in the gitlab web app.
4. 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!
* [demo_files.zip](https://h1.sec.gitlab.net/a/ecf91948-b2d5-413c-95a5-a611ed80b50b/demo_files.zip)
* [recording-1723199580785.webm](https://h1.sec.gitlab.net/a/42adef20-730a-471b-969f-de3e6cafa11f/recording-1723199580785.webm)
## How To Reproduce
Please add [reproducibility information] to this section:
1.
1.
1.
[reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues
issue