LfsLinkService allows disclosure of LFS objects by SHA256 hash

Summary

The LfsLinkService allows to obtain LFS files stored on a GitLab instance by just knowing the file's SHA256 hash.

This can be easily exploited by using the MergeRequests::LinkLfsObjectsService which in turn is run on Merge Requests by the MergeRequests::RefreshService.

Steps to reproduce

Assume we have a target file which is stored as an LFS object on gitlab.com, the attacker only knows the file's SHA256 hash.

To obtain the file proceed as follows:

  1. Create a repository A
  2. Fork A to A-fork
  3. Turn off LFS in A-fork's settings
  4. Create a file leak in A-fork's main branch with the content:
version https://git-lfs.github.com/spec/v1
oid sha256:1a95dc7532d60219a9fcf0d2c75f8bf8db5676df9690e8c0c1d3ba0986bdb8f5
size 1337

Where the oid sha256: value should match the target file's SHA256 hash. The above value can be used as an example (see also this Slack conversation [internal link])

  1. Create a MR from A-fork to A
  2. In the MR diff view download the leak file

That downloaded file should have the contents of the target file.

What is the current bug behavior?

LFS files can be leaked based on knowing their SHA256 hash.

What is the expected correct behavior?

Only files which were uploaded in context of a repository should be accessible from within that repository.

cc @gitlab-com/gl-security/appsec

Edited by the other joern -