Re: Trust issues with hooks and config files

From: Jeff King <peff@peff.net>
Date: Mar 7, 2014, 21:04 UTC
Message-ID: <20140307210403.GA6790@sigill.intra.peff.net>
In-Reply-To: <5318ECFF.40908@0x4a42.net>

On Thu, Mar 06, 2014 at 10:47:43PM +0100, Julian Brost wrote:

Show 7 quoted lines

> I've noticed some behavior of git that might lead to some security
> issues if the user is not aware of this.
> 
> Assume we have an evil user on a system, let's call him eve. He
> prepares a repository where he allows other user to push changes to.
> If he now adds a post-receive hook, git will happly execute it as
> whatever user pushes to this repository:

Yes, this is a well-known issue. The only safe operation on a repository for which somebody else controls hooks and config is to fetch from it (upload-pack on the remote repository does not respect any dangerous config or hooks).

Show 6 quoted lines

> Something similiar might happen if eve adds some alias to the config
> file in the repository and grants any other user read access to the
> repository. These aliases will be executed when some other user is
> running any git command in this repository. Even though git does not
> allow defining aliases for existing commands, you might mistype
> something, so adding an alias for "lg" instead of "log" might succeed:

Much easier is to define an external diff or textconv tool; then the victim does not even have to typo.

> I'd suggest taking a similar approach as Mercurial [1], i.e. ignoring
> configuration files and hooks owned by another user unless the owner
> is explicitly trusted

It has been discussed, but nobody has produced patches. I think that nobody is really interested in doing so because:

  1. It introduces complications into previously-working setups (e.g., a
     daemon running as "nobody" serving repos owned by a "git" user
     needs to mark "git" as trusted).

  2. In most cases, cross-server boundaries provide sufficient
     insulation (e.g., I might not push to an evil person's repo, but rather
     to a shared repo whose hooks and config are controlled by root on
     the remote server).

If you want to work on it, I think it's an interesting area. But any development would need to think about the transition plan for existing sites that will be broken.

At the very least, the current trust model could stand to be documented much better (I do not think the rule of "fetching is safe, everything else is not" is mentioned anywhere explicitly).

-Peff