Skip to content

Invited group members, with access inherited from parent group, continue to have project access even after invited subgroup is transfered

HackerOne report #1330806 by joaxcar on 2021-09-05, assigned to GitLab Team:

Report | Attachments | How To Reproduce

Report

Summary

I have found an issue similar to the one fixed in patch 14.2.2 link where users had access to a shared project even after the invited group was deleted.

The problem is caused by the group inheritance, when a user shares a project with a subgroup the users from any parent groups are given access to the project as well (which is the documented behavior, see image). The problem is that if the subgroup is later transferred to another parent group, the users in the new parent group will get access to the shared project, but the users from the old parent group does not get their access revoked.

[REDACTED]

Further, if the subgroup which was the target of the shared project is subsequently deleted, only users with access stemming from the current parent groups are revoked. This leaves the project in a state with no apparent invited groups or other members, but with "ghost" members with anything from Guest to Maintainer access depending on the initial invitation.

A "worst care scenario" is that a user shares a project with a group with maximum access level at maintainer, because the user trust the maintainers. This group is later added as a subgroup to another group temporarily for some reason, and then again transferred to its own hierarchy. Any maintainers or owners of this temporary parent group will now have hidden maintainer access to the project, even if the invited group is deleted.

This hidden access seems to be persistent until the project owner starts editing project access again, inviting a new group will "kick out" all hidden members as it seems.

Steps to reproduce

One basic scenario to prove the vulnerability, having three users in a group and moving the subgroup with the shared project out from the parent group.

  1. Create three users project_owner, group_owner and hidden_maintainer
  2. Log in as group_owner and create two groups target_group and temporary_parent
  3. In target_group create a subgroup subgroup01
  4. Invite project_owner as a Developer of target_group
  5. Invite hidden_maintainer as a Maintainer of target_group
  6. Log in as project_owner and create a private project project01 in the user namespace, https://domain.gitlab.com/projects/new#blank_project
  7. Go to https://domain.gitlab.com/project_owner/project01/-/project_members and click "invite group". Search for and select target_group / subgroup and "max-role" Maintainer. Click "Invite".

[REDACTED]

  1. Log in as group_owner and go to https://domain.gitlab.com/groups/target_group/subgroup01/-/edit and expand the "Advanced" tab at the bottom.
  2. Scroll to the option "Transfer group" and select temporary_parent and click "transfer group".

[REDACTED]

  1. When the group is now part of temporary_parent go to https://domain.gitlab.com/groups/target_group/subgroup01/-/edit again and expand the "Advanced" tab. Now scroll to the bottom and click and accept "Remove group"
  2. As group_owner go to https://domain.gitlab.com/project_owner/project01 and verify that you get an 404 not found error (this user is no member any more)
  3. Log in as hidden_maintainer and go to the same https://domain.gitlab.com/project_owner/project01 and verify that this user have access
  4. Go to https://domain.gitlab.com/project_owner/project01/-/project_members and verify that the list only include project_owner

Another scenario would be to have the hidden_maintainer as a member of temporary_parent and transfer the subgroup01 to temporary_parent and then directly back to target_group. This would "touch" the hidden_maintainer and give it access to the group. In these examples the invited group is a subgroup from start, this is not necessary. It could as well be a regular group that is then transferred to a parent group and then moved back out again.

Example

User [REDACTED] having access to the private project owned by [REDACTED]

[REDACTED] [REDACTED]

Impact

Users can get hidden unauthorized access to a project that is shared with a group where the users access is inherited. In the worst care scenario a user could acquire hidden maintainer access to a private project! The user will have full access to the project as a maintainer including settings and repository.

What is the current bug behavior?

When a group containing shared access to a project is transferred out from a parent group, the users of the parent group will retain their access to the shared project.

What is the expected correct behavior?

When a group containing shared access to a project is transferred from a parent group users in the parent group should lose access to the project.

Relevant logs and/or screenshots
Output of checks

This bug happens on GitLab.com

Impact

Users can get hidden unauthorized access to a project that is shared with a group where the users access is inherited. In the worst care scenario a user could acquire hidden maintainer access to a private project! The user will have full access to the project as a maintainer including settings and repository.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section:

Edited by Nikhil George