Subject: Trust issues with hooks and config files

From: Julian Brost <[email-masked]>
Date: Thu, 06 Mar 2014 22:47:43 +0100

Hi,

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:

  root@argon /tmp/git-eve # ls -l /tmp/git-eve/hooks/post-receive
  -rwxr-xr-x 1 eve users [...] /tmp/git-eve/hooks/post-receive
  root@argon /tmp/git-root # cat /tmp/git-eve/hooks/post-receive
  #!/bin/sh
  id
  root@argon /tmp/git-root # git push /tmp/git-eve master
  Counting objects: 3, done.
  Writing objects: 100% (3/3), 185 bytes | 0 bytes/s, done.
  Total 3 (delta 0), reused 0 (delta 0)
  remote: uid=0(root) gid=0(root) groups=0(root),[...]
  To /tmp/git-eve
   * [new branch]      master -> master

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:

  root@argon /tmp/git-eve # ls -l /tmp/git-eve/config
  -rw-r--r-- 1 eve users [...] /tmp/git-eve/config
  root@argon /tmp/git-eve # cat config
  [core]
  	repositoryformatversion = 0
  	filemode = true
  	bare = true
  [alias]
  	lg = !id
  root@argon /tmp/git-eve # git lg
  uid=0(root) gid=0(root) groups=0(root),[...]

This gets even worse if you know something about the aliases your
victim uses, so for example you can override an alias 'l = log'
defined in the user's config with something malicious in the
repository config file.

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.

Regards,
Julian

[1] http://mercurial.selenic.com/wiki/Trust