heads up: security issues in git with respect to embedded bare repos

[calestyo]

Hey.

This is merely a heads up about a security issue that was found a while ago in git itself and which was discussed in detail at [0] as well as [1] with a good overview and simple demo of an exploit at [2] and with a "fix" (i.e. rather a safeguard, that unfortunately even seems to default to the unsafe option) pending for release at [3].

In short, when cloning an untrusted repository and inspecting it (simple git commands or even cding into them, with things like git-prompt enabled, may be enough) allow apparently arbitrary code execution. Code which is controlled by a possible attacker.

Could you please check whether libgit2 is also affected by this issue and if so, provide some fix?

Similarly, it must be checked whether the work tree of a git repo would contain a .git dir, which would allow for the same attack with non-bare repos.
Git apparently already forbids this since long.

Thanks for checking,
Chris.

[boretrk]

I don't think libgit2 even supports fsmonitor, at least I couldn't find any references to it.

[calestyo]

AFAIU, it's no just fsmonitor, but in principle whenever the git implementation would parse/use the embedded bare repos's git-config or e.g. it's hooks.

[extrawurst]

Libgit2 does not support hooks

[calestyo]

Hmm, well but AFAICS from a just very quick glance on its sources, it does parse git’s config.
Not sure whether it also does so for embedded bare repos, though.

Even if none of this would be supported by libgit2 right now, it would probably still make sense to somehow take care that no future version of it, which may add support for further features, becomes exploitable. I mean in one year from now, no one will likely remember this subtle but dangerous issue.

And in principle git is also vulnerable to having a rogue .git, even if it cannot checked out as part of a repo (not sure whether libgit2 prevents even that).
Consider a tarball which is downloaded from somewhere and contains a .git. It's not too hard to imagine that some tool using libgit2 is called within that.
But even plain git itself does as of now nothing to prevent this. I proposed a few ideas how this could be handled upstream [0], but of course it would only make sense to do something about that particular issue, if git itself would also do.

[boretrk]

It is possible that libgit2 may never run hooks by itself.
There is some discussions about it in #964
In particular there are concerns about portability and error handling with shelling out from the library.

OTOH it is very likely that projects using libgit2 are calling the hooks on their own, so any solution should probably be focused on helping library callers to not do anything dangerous.