Skip to content

Arbitrary read access via `git clone --filter=sparse:path=<path>`

Merged into Git 2.22.0-rc3

This feature is disabled by default

Introduced in Git 2.18 (or maybe later), --filter=sparse:path=<path> can be used when cloning to limit the contents of a clone to only files matching specific patterns. It is disabled by default, but can be enabled with uploadpack.allowFilter.

However there is an arbitrary file access issue which was reported by reported by Peff https://public-inbox.org/git/20181108050755.GA32158@sigill.intra.peff.net/ while testing:

But I'm also concerned it's dangerous. We're reading gitignore patterns
from an arbitrary name on the server's filesystem, with that name coming
from an untrusted client. So I can do:

  git clone --filter=sparse:path=/etc/passwd $remote

and the server will read /etc/passwd. There's probably a lot of mischief
you can get up to with that. Sadly reading /proc/self/mem doesn't work,
because the gitignore code fstat()s the file to find out how much to
read, and the st_size there is 0. But there are probably others
(/proc/kcore is a fun one, but nobody is running their git server as
root, right?).

Further details

The motivation of this feature is that is allow the repository owner to specify a file containing a configuration of the files to include. For a giant mono repo, there might be 15 projects, each needing their own combination of trees to actually develop on locally. The idea was that these configurations should be stored/versioned centraly.

Proposal

The solution proposed by Jeff Hostetler (Microsoft) is to change the implementation to:

  • --filter=sparse:path=<rev>:<path> where the path is relative to the root of the repo

This would resolve the security issue and prevent arbitrary file access.

Links / references

https://public-inbox.org/git/20181108050755.GA32158@sigill.intra.peff.net/

Edited by Christian Couder