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.
- Create three users
project_owner
,group_owner
andhidden_maintainer
- Log in as
group_owner
and create two groupstarget_group
andtemporary_parent
- In
target_group
create a subgroupsubgroup01
- Invite
project_owner
as aDeveloper
oftarget_group
- Invite
hidden_maintainer
as aMaintainer
oftarget_group
- Log in as
project_owner
and create a private projectproject01
in the user namespace, https://domain.gitlab.com/projects/new#blank_project - 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]
- 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. - Scroll to the option "Transfer group" and select
temporary_parent
and click "transfer group".
[REDACTED]
- 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" - 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) - Log in as
hidden_maintainer
and go to the same https://domain.gitlab.com/project_owner/project01 and verify that this user have access - 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: