Re: Shared repositories no longer securable against privilege escalation

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Mar 18, 2017, 21:17 UTC
Message-ID: <CACBZZX4VApZnO1u708nxqq711K7PD66U=mTT2tjnbt2XjxmQew@mail.gmail.com>
In-Reply-To: <148971018136.2144.12683278043600094739@richardiv.omgwallhack.org>

On Fri, Mar 17, 2017 at 1:23 AM, Joe Rayhawk <jrayhawk@freedesktop.org> wrote:

Show 5 quoted lines

> Git has started requiring write access to the root of bare repositories
> in order to create /HEAD.lock. This is a major security problem in
> shared environments as it also entails control over the /config link
> i.e. core.hooksPath. Permission to write objects and update refs should
> be entirely separate from permission to edit hook execution logic.

[Full disclosure: I implemented core.hooksPath]

The core.hooksPath facility doesn't introduce any sort of new security problems that didn't exist already, and if you're just focusing on the sort of problems changing core.hooksPath might bring up you're still vulnerable to those.

If you give me general shell access to some repo where I can write refs and objects you can't use hooks to sanity check anything I push. E.g. let's say you have an "update" hook which makes sure I can't push binaries (malware) to your "master" branch. I can just push that to some other branch, then log in and run:

    echo <new_sha1> > /path/to/bare/repo.git/refs/heads/master

Ah ha! You might say, you'll just make that update hook run for any branch or reference! That doesn't matter either, if you give me write access to objects/ and refs/ I can just manually echo the objects I want there, and then manually update the ref.

If you want to run a shared repository via ssh login where you want to reliably execute hooks you need to either use something like Gitolite, as Jakub points out, or e.g. set the user's shell to git-shell or some similar facility which whitelists the commands the user can run. Anything else is just security through obscurity.