Skip to content

PProf activated by default on 0.0.0.0 leads to debugging stats disclosed via endpoint /debug/pprof/*

⚠️ 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 #3030586 by ap-wtioit on 2025-03-11, assigned to @ngeorge1:

Report | Attachments | How To Reproduce

Report

NOTE! Thanks for submitting a report! Please note that initial triage is handled by HackerOne staff. They are identified with a HackerOne triage badge and will escalate to the GitLab team any. 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!

Summary

We discovered on our own gitlab instance that since one of the last few updates notably when we installed 17.9.1 there is an additional port open for gitlab-workhorse on 0.0.0.0:>32768. This port was connectable with go tool pprof http://gitlab.wt-io-it.at:39129/debug/pprof/heap

Steps to reproduce

(Step-by-step guide to reproduce the issue, including:)
1.) Have gitlab-ee omnibus install 17.9.1.
2.) either locally sudo netstat -lnp --tcpto find the port or in theory it should also be discoverable with nmap remotely (not tested)
image.png
3.) use go tool pprof http://gitlab.myhost.com:33895/debug/pprof/heap to connect to the pprof

Impact

Any information that can be retrieved with pprof from workhorse can be retrieved without any authentication or authorization on an up to date gitlab instance that runs on a server reachable to the attacker.

Examples

Not yet explored which information can be extracted from workhorse with pprof

What is the current bug behavior?

The default config for gitlab.rb activates pprof in workhorse.

Gitlabs and pprofs defaults amount to pprof listening on a random tcp port higher than 32768 on 0.0.0.0

What is the expected correct behavior?

The default config for gitlab.rb does not activate pprof in workhorse.

Currently it is possible to deactivate the port with:

gitlab_workhorse['pprof_listen_addr'] = "null"

in gitlab.rb

Relevant logs and/or screenshots

The check for pprof_listen_add beeing an empty string was moved here and seems no longer working:
dbde3ef4

Output of checks
Results of GitLab environment info
System information  
System:		Debian 12  
Proxy:		no  
Current User:	git  
Using RVM:	no  
Ruby Version:	3.2.5  
Gem Version:	3.6.3  
Bundler Version:2.5.11  
Rake Version:	13.0.6  
Redis Version:	7.0.15  
Sidekiq Version:7.2.4  
Go Version:	unknown

GitLab information  
Version:	17.9.1-ee  
Revision:	8f67c219597  
Directory:	/opt/gitlab/embedded/service/gitlab-rails  
DB Adapter:	PostgreSQL  
DB Version:	14.15  
URL:		https://gitlab.wt-io-it.at  
HTTP Clone URL:	https://gitlab.wt-io-it.at/some-group/some-project.git  
SSH Clone URL:	ssh://git@gitlab.wt-io-it.at:2022/some-group/some-project.git  
Elasticsearch:	no  
Geo:		no  
Using LDAP:	no  
Using Omniauth:	yes  
Omniauth Providers: github, openid_connect

GitLab Shell  
Version:	14.40.0  
Repository storages:  
- default: 	unix:/var/opt/gitlab/gitaly/gitaly.socket  
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

Gitaly  
- default Address: 	unix:/var/opt/gitlab/gitaly/gitaly.socket  
- default Version: 	17.9.1  
- default Git Version: 	2.47.2

Impact

An attacker can connect pprof to a gitlab workhorse.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: