Removed Developer can continue editing the source code of a public project
HackerOne report #2082560 by theluci
on 2023-07-24, assigned to GitLab Team
:
Report | Attachments | How To Reproduce
Report
Hello,
Background
Gitlab provides a feature to create a fork of a project.
Gitlab also provides a feature to Collaborate on merge requests across forks. This feature allows upstream members to collaborate with you on your branch, when this option is enabled members who have permission to merge to the target branch get permission to write to the merge request’s source branch.
According to docs,
Vulnerability
When a merge request is created from a public project victim-project
to one of its forks victim-project-fork
(Public project but merge requests has been set as Only Project Members), Only the members of the victim-project-fork
has the ability to view, edit as well as delete the merge request.
A malicious developer of victim-project
can utilize the above to create a merge request from victim-project
to victim-project-fork
with collaboration option enabled and continue affecting the integrity of victim-project
even after malicious developer has been removed.
Attack flow looks as follows,
-
victim
is the Owner of public projectvictim-project
-
attacker
is a Developer ofvictim-project
-
attacker
creates a public fork ofvictim-project
in his Personal namespacevictim-project-fork
. -
attacker
goes tovictim-project-fork
settings and set Merge requests as Only Project Members. -
attacker
creates merge requests from every non-protected branch invictim-project
to their respective branches invictim-project-fork
with collaboration option enabled. -
attacker
is removed fromvictim-project
. -
victim
cannot view or delete the merge requests invictim-project-fork
. -
attacker
continues to be able to edit the source code ofvictim-project
using open merge requests invictim-project-fork
.
Steps to reproduce
-
victim
creates a public groupvictim-group
and a public projectvictim-project
inside. -
victim
goes tovictim-group
membership pagehttps://gitlab.com/groups/<victim-group>/-/group_members
and addsattacker
as Developer. -
victim
goes tovictim-project
and creates branchanother-branch
. -
attacker
goes tovictim-project
and creates a public fork in his Personal namespacevictim-project-fork
. -
attacker
goes tovictim-project-fork
settingshttps://gitlab.com/<attacker_username>/<victim-project-fork>/edit
, Expand Visibility, project features, permissions and set Merge requests as Only Project Members. -
attacker
goes tohttps://gitlab.com/<victim-group>/<victim-project>/-/merge_requests/new
and creates a merge request fromanother-branch
invictim-project
toanother-branch
invictim-project-fork
with collaboration option enabled.
In a real-world scenario, attacker
will create merge requests from every non-protected branch in victim-project
to their respective branches in victim-project-fork
with collaboration option enabled.
-
victim
removesattacker
fromvictim-group
.
victim
is not able to view or delete the merge requests in victim-project-fork
and has no idea merge requests with collaboration option enabled exists.
attacker
continues to be able to edit the source code of victim-project
using open merge requests in victim-project-fork
.
8. attacker
visits victim-project
9. attacker
is able to make changes to another-branch
in victim-project
- To create a new file,
attacker
switches toanother-branch
and create the file using+
symbol. - To edit an existing file
attacker
goes to the following API endpoint,
https://gitlab.com/<victim-group>/<victim-project>/-/edit/another-branch/<file_name>
As can be seen, attacker
continues to be able to edit the source code of victim-project
.
POC
Output of checks
This bug happens on GitLab.com (Probably on instance too).
Impact
A Removed Developer can continue editing the source code of a public project
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: