A member with insufficient permissions can override the value of CI/CD protected variables in a project or group.
HackerOne report #1508976 by st4nly0n
on 2022-03-12, assigned to @nmalcolm:
Report | Attachments | How To Reproduce
Report
Summary
CI/CD variables are a type of environment variable that can be used to control the behavior of jobs and pipelines, store values you want to reuse, avoid hardcoding values in the .gitlab-ci.yml
file
You can add CI/CD variables to a project's settings via /-/settings/ci_cd. Only project members with the Maintainer role can add or update project CI/CD variables. To keep a CI/CD variable secret, place it in the project configuration, not in the .gitlab-ci.yml
file.
When a variable is protected, it means that it will be exported for pipelines running on protected branches or tags.
To read more see the following link https://docs.gitlab.com/ee/ci/variables/
A project member with developer permissions is not authorized to alter the data integrity of protected variables configured for a project or group, doing so would be losing integrity or availability in the CI/CD process.
The gitlab web interface does not allow creating a branch with the name refs/heads/main
, you will get an error message that the branch name is not valid, still insufficient validation causes the branch to crash. you can push from cli with git client.
Commits that are pushed to the refs/heads/main
branch will not be displayed in the gitlab web interface, since refs/heads/main
and main are the same thing.
The aforementioned, allows an attacker to override the value of the protected variables configured for a project, this is achieved if from the CLI the attacker pushes a branch with the name of refs/heads/<branch-name>
, for example, when the attacker pushes the branch with the name of refs/heads/main
, it would be preventing the protected variables configured for the project from being exported to the pipes of the main branch, in the context of integrity, the attacker is deleting data in the application, and in the context of availability, the attacker is preventing a deployment from happening.
Steps to reproduce:
• Perform the steps below as the victim user:
1. Create a repository on gitlab.com
2. Invite a member with developer permissions.
3. Create two project-protected variables in /-/settings/ci_cd
, one of type variable and the other of type file.
4. Create a CI/CD configuration file .gitlab-ci.yml
with the following content:
stages:
- build
build-job:
variables:
CI_DEBUG_TRACE: "false"
stage: build
script:
- echo $<type-variable>
- cat $<type-file>
• Perform the steps below as the attacker user (guest user in step 2):
1. From the CLI, clone the repository and go into the directory.
git clone <repo>
cd <repo>
2. Create and switch to a new branch named refs/heads/main
git checkout -b 'refs/heads/main'
3. Delete the .gitlab-ci.yml
file.
rm .gitlab-ci.yml
4. Add and commit the changes.
git add .
git commit -m POC
5. Push the refs/heads/main
branch to the remote.
git push origin HEAD
To see that the protected variables are not being exported, change the value of CI_DEBUG_TRACE in the .gitlab-ci.yml
file to true, and note that in the debug log, export <VARIABLE>=<value>
does not appear.
What is the current bug behavior?
Protected variables set for a project or group are not exported after a project member pushes a branch named refs/heads/<branch-name>
What is the expected correct behavior?
Protected variables configured for a project should be available when a branch is pushed.
Relevant logs and/or screenshots
In the proof of concept video see how protected variables configured for the project will not be available to main branch pipelines after a project member with insufficient permissions pushes a branch named refs/heads/main
POC video removed to redact researcher project details - it can be viewed in H1 if needed
Output of checks
This bug happens on GitLab.com
Impact
A member of the group or project with insufficient permissions can override the value of variables configured for a project or group, from an integrity point of view an attacker is deleting data in the application preventing pipes that depend on the variables protected to run successfully, from an availability point of view, an attacker would prevent the deployment or deployment of an application.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: