Skip to content

Auditor users can create merge requests on projects they don't have access to

⚠ 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 #2046752 by js_noob on 2023-07-02, assigned to @greg:

Report | Attachments | How To Reproduce

Report

Summary

Hello team, according to docs, an auditor has read-access to projects he doesn't have access to.

Have read-only access to projects you aren’t a member of.

However, an auditor can still create merge requests in projects he cannot access, using changes/branches originating from forks.

Steps to reproduce

As an admin:

  1. Spin up your own GitLab instance, and apply the ultimate trial to it (https://about.gitlab.com/free-trial/?hosted=self-managed)
  2. Create a private dummy project
  3. Create a new user in your instance (or you can easily signup from another browser)

As the other user:

  1. Verify that you can't access the project created in Step 2

As the admin:

  1. Promote that user to Auditor https://YOUR_DOMAIN/admin/users/USER_USERNAME/edit

image.png

As the auditor (previously the "other user"):

  1. Verify that you can "read" that project (created in step 2)
  2. Navigate to the merge requests page and verify that can't create MRs, now let's workaround that
  3. Fork that project into your namespace, create a new branch and add any changes to it
  4. Create a new MR with the base as your project with the new branch and target the original project with the main branch

image.png

As the admin:

  1. Verify that a new MR is created
Examples/POC

bandicam_2023-07-02_10-52-20-985.mp4

What is the current bug behavior?

An auditor can create MRs, originating from forks, on projects he doesn't have access to.

What is the expected correct behavior?

Auditor MRs, originating from forks, on projects he doesn't have access to should be blocked just like any other MRs.

Results of GitLab environment info
System information  
System:         Debian 11  
Proxy:          no  
Current User:   git  
Using RVM:      no  
Ruby Version:   3.0.6p216  
Gem Version:    3.4.13  
Bundler Version:2.4.14  
Rake Version:   13.0.6  
Redis Version:  6.2.11  
Sidekiq Version:6.5.7  
Go Version:     unknown

GitLab information  
Version:        16.1.1-ee  
Revision:       d3582d7719f  
Directory:      /opt/gitlab/embedded/service/gitlab-rails  
DB Adapter:     PostgreSQL  
DB Version:     13.11  
URL:            https://gitlab-private.net  
HTTP Clone URL: https://gitlab-private.net/some-group/some-project.git  
SSH Clone URL:  git@gitlab-private.net: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

User with read-only access (auditor) can create merge requests on projects he doesn't have access to.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: