On Thu, Mar 06, 2014 at 10:47:43PM +0100, Julian Brost wrote:
> 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).
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html