GitLab: Importing GitLab project archives can replace uploads of other users

Summary

Importing a modified exported GitLab project archive can overwrite uploads for other users. If the secret and file name of an upload are known (these can be easily identified for any uploads to public repositories), any user can import a new project which overwrites the served content of the upload with arbitrary content.

This issue could be abused to backdoor project compiled binaries, allowing the spread of malware.

I have not performed a full risk assessment or root cause analysis of this issue at this time. I wanted to get the issue reported to GitLab asap after discovery. If you require any further details or information please let me know.

Steps to reproduce

See the video below for an example of this issue:
{F466353}

The video shows the following steps:

1. As user root (on the left hand side of the video), create a new project
2. Upload a file to the project (e.g. by creating a new issue)
3. Take note of the file secret and file name of the original upload
4. Craft a GitLab project export tar.gz with the replacement upload file with a path equal to the original upload secret and file name, e.g. ./uploads/ed5ab56bc85699117ba230eb799fd3bf/indi.jpg (See {F466355} attached)
5. As user test (on the right hand side of the video) create a new project, importing the crafted tar.gz from the above step
6. As the user root refresh your view of the upload file, and note that it has been modified

This example was demonstrated against the official GitLab docker image from https://hub.docker.com/r/gitlab/gitlab-ce/.

Impact

Any upload type can be replaced using this method, if the secret and file name are known (these can be easily identified for any uploads to public repositories). An attacker could abuse this to backdoor project compiled binaries, allowing the spread of malware.

Examples

See the attached project files:

1. Origin project export {F466356}
2. Modified project export used to change the upload file {F466355}

What is the current bug behavior?

Importing a project as any user can modify the served upload files of other users.

What is the expected correct behavior?

Importing a project should not be able to modify the served upload files of other users.

Relevant logs and/or screenshots

See the following /var/log/gitlab/gitlab-rails/production.log entry:

Started GET "/root/new_project/uploads/ed5ab56bc85699117ba230eb799fd3bf/indi.jpg" for 127.0.0.1 at 2019-04-10 23:07:12 +0000
Processing by Projects::UploadsController#show as HTML
  Parameters: {"namespace_id"=>"root", "project_id"=>"new_project", "secret"=>"[FILTERED]", "filename"=>"indi.jpg"}
Sent file /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test/modified_project/ed5ab56bc85699117ba230eb799fd3bf/indi.jpg (0.2ms)

Note that the request was for the /root/new_project/uploads/ed5ab56bc85699117ba230eb799fd3bf/indi.jpg file, however the file from the test/modified_project was served.

Output of checks

Results of GitLab environment info

GitLab docker environment:

 docker images gitlab/gitlab-ce
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
gitlab/gitlab-ce    latest              7a65562fb501        6 days ago          1.78GB

gitlab-rake gitlab:env:info

System information
System:
Current User:   git
Using RVM:      no
Ruby Version:   2.5.3p105
Gem Version:    2.7.6
Bundler Version:1.16.6
Rake Version:   12.3.2
Redis Version:  3.2.12
Git Version:    2.18.1
Sidekiq Version:5.2.5
Go Version:     unknown

GitLab information
Version:        11.9.6
Revision:       14bac95
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
URL:            http://gitlab.example.com
HTTP Clone URL: http://gitlab.example.com/some-group/some-project.git
SSH Clone URL:  [email protected]:some-group/some-project.git
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers:

GitLab Shell
Version:        8.7.1
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell
Git:            /opt/gitlab/embedded/bin/git

Impact

Any upload type can be replaced using this method, if the secret and file name are known (these can be easily identified for any uploads to public repositories). An attacker could abuse this to backdoor project compiled binaries, allowing the spread of malware.

I have not performed a full risk assessment or root cause analysis of this issue at this time. I wanted to get the issue reported to GitLab asap after discovery.