User with developer role can read protected/secret group variables

HackerOne report #631073 by rpadovani on 2019-06-27, assigned to estrike:

Summary

A user, member of a group, with permission "Developer" can read "Protected" group variables, that should be accessible only to Maintainers

Steps to reproduce

  1. Alice is a member of the group "Bob's developers", with a role of "Developer".
  2. Bob has created a group variable, marked as "protected", called "My_most_deep_secret". Alice (nor any other developer) has access to this group variable. Bob is very careful to what he merges in protected branches, to do not disclose the group variable.
  3. Alice creates a new project under her own namespace, something like Alice/i_steal_everything. Alice is, of course, owner of this new project.
  4. Alice uses the new transfer api to transfer the project under the "Bob's developers" namespace.
  5. Alice is now maintainer of this project. Thus, she can choose which branches are protected.
  6. Alice creates a .gitlab-ci.yml file where she prints the protected variable (just echo ${My_most_deep_secret}
  7. Alice now protects the branch with this file, and she is able to having the secret variable injected.

Alice has access to the value of ""My_most_deep_secret" by Bob - that btw, was "I_love_Alice" ;).

The documentation says

You can transfer an existing project into a group if:

  • You have at least Maintainer permissions to that group.

That is actually not true. The code checks only if the user can create a project, and you need only to be a developer to create a project in a group.

def allowed_transfer?(current_user, project)  
      @new_namespace &&  
        can?(current_user, :change_namespace, project) &&  
        @new_namespace.id != project.namespace_id &&  
        current_user.can?(:create_projects, @new_namespace)  
  end

Impact

According to the Gitlab's guide, using group variables

It’s the recommended method to use for storing things like passwords, SSH keys, and credentials.

Every developer in a group has then access to password, SSH keys, and credentials that shouldn't have access to, probably of production environments.

I suppose there are other possible impacts being able to escalate privileges inside a project of a group, but I don't find any other example right now.

Examples

You need to have an user with access to a group as developer. I have a group with a secret variable, I can give access to when requested

What is the current bug behavior?

Alice can transfer the project / Alice is maintainer of the project.

What is the expected correct behavior?

Alice cannot transfer the project, or at least she is not maintainer of the new project - as when you create a new project inside a group as a developer, you are not maintainer but developer

Output of checks

This bug happens on GitLab.com

Impact

According to the Gitlab's guide, using group variables

It’s the recommended method to use for storing things like passwords, SSH keys, and credentials.

Every developer in a group has then access to password, SSH keys, and credentials that shouldn't have access to, probably of production environments.

Edited by GitLab SecurityBot