Orphaned upload files that were not moved properly during a group transfer need to be cleaned up
During discussion in https://gitlab.com/gitlab-org/gitlab-ee/issues/6012, I realized there was a similar problem on the primary side. Meaning some level of exposure right now on GitLab.com.
This bug with transferring groups https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17658 was fixed in 10.6RC6 and 10.5.5.
But groups that were transferred in an earlier version may have orphaned upload files. In 10.5.5, namespace redirects were permanent, so the path was safely blocked.
But in 10.7.0, all redirects are overwriteable: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17521
Which means any project uploads that I was unable to find and fix in https://gitlab.com/gitlab-com/migration/issues/465 are currently at risk on GitLab.com.
Steps to obtain unauthorized access to uploads:
- GitLab v10.5.4 or lower
- Create project
foo/bar
- Create group
qux
- Transfer group
foo
intoqux
(i.e. the project is now atqux/foo/bar
) - Upgrade GitLab to 10.7+
- Create project
foo/bar
- Generate an export
.zip
So if you know paths that were used by groups that were transferred before 10.6RC6, in paths that you have permission to claim, and you know the project names, and if those projects uploads were ones that I didn't fix, then you may be able to exploit this issue.
I was able to reproduce this whole process with a Docker GitLab v10.5.4 then upgrading to v11.1.1.
Ways to mitigate this
- Crawl project uploads on the primary and delete any files that are not tracked in
uploads
table - Migrate uploads to object storage and delete local uploads dir (or ensure project export doesn't grab local uploads if object storage is enabled)
- Migrate projects to hashed storage