Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab FOSS GitLab FOSS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1
    • Merge requests 1
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #53477
Closed
Open
Created Nov 02, 2018 by James Edwards-Jones@jamedjoContributor

Secret CI variables can exposed by creating a tag with the same name as an existing protected branch

Steps to reproduce

  1. Add a secret variable and mark it as protected. It should only be accessible on protected tags/branches to prevent unauthorized access
  2. Create a branch matching a protected branch or wildcard. A master protection is created by default and can be used here instead
  3. Add .gitlab-ci.yml with a script that will steal the secret variable. For test purposes echo $PROTECTED_SECRET works but an attacker might do this silently
  4. Create a tag with the same name as (2)
  5. Find way to trigger a pipeline for that tag.
    • Note: We'd expect this to happen automatically, but because of a bug we accidentally check can_update_branch? for the tag and prevent the pipeline being created. If that bug is fixed this step can be skipped, but for now an attacker might be able to trigger the pipeline using trigger tokens or repository mirroring. See discussion below.
  6. Notice that the secret incorrectly available to the script

Output

$ echo $PROTECTED_SECRET
myhiddenpassword
Job succeeded

Related

  • https://gitlab.com/gitlab-org/gitlab-ce/issues/38984
  • https://gitlab.com/gitlab-org/gitlab-ce/issues/42085
Edited Nov 08, 2018 by James Edwards-Jones
Assignee
Assign to
Time tracking