Re: status on security of embedded repos?

[Christoph Anton Mitterer <calestyo@scientia.org>]

Hey Glen.


On Thu, 2022-09-08 at 09:56 -0700, Glen Choo wrote:
> In a world where we had someone who headed all of the Git ecosystem
> making these decisions, that sounds like a great outcome.
> Unfortunately,
> I don't think such a person exists.

Well it's clear that there's no such one, but at least there should be
people far more experienced than me (who in terms of git is nothing
more than an average user)... and would be far more able to see which
other projects might be affected.
...

> how do we know which projects to engage
> with? 
> e.g. we'd probaby need JGit and libgit2, but what about smaller
> implementations like gitoxide, editor plugins, and the long tail of
> other projects in the space?

... clear, too, but again, you already named more than I'd have known
about ;-) ... I mean I knew libgit2 (which is utilised by some git
tools I use) and had heard of jgit before, though I don't use it.

These are some other git related tools, which I would assume are used
widespread or in some more (security) critical places:
- dgit
- git-debrebase
- git-buildpackage
(the above being used in Debian package management)

- git-remote-gcrypt
- git-evtag
(the above being used by who likely have high security requirements)

- libgit-wrapper-perl

all these seem to either depend on git itself or libgit2, so one can
hope they'd be safe as soon as git and libgit2 were. But I guess it's
really not more than just "hope", because any of them could e.g.
manually look for git config and do stuff with it, thereby picking up
that from an attacker in an embedded bare repo. Right?

Not sure what about things like:
- meld (which has *some* git support, but probably implements all that
  by itself - at least it doesn't depend on the usual suspects)

But even tools like gitg, which use libgit2 or libgit-wrapper-perl
which uses git itself could still "manually" read some config file,
thereby avoiding any "fix" of safe.bareRepository.



> > I can however open a ticket over at libgit2, if that helps you.
> 
> It would help all users :)

I've did this now for libgit2:
https://github.com/libgit2/libgit2/issues/6400

But I'd really hope someone with more background in that field could
follow that up for other 3rd party projects.



> > Also, even with default settings, git, AFAIU, would be still
> > vulnerable
> > for the majority of people (many of whom likely haven't even heard
> > about the issue).
> 
> Yes. We've talked earlier about finding a safer default for
> safe.bareRepository; but it hasn't been highly prioritized. Feedback
> like yours is very valuable because it gives us a sense of how
> important
> this is and can definitely have an impact on prioritization.

Maybe I misunderstand the issue and make just a lot of noise for
nothing.

My understanding was, that an embedded bare repo, would allow arbitrary
code execution, when one has cloned or fetched that as part of some
regularly used repo... and as soon as one runs git commands inside of
that.
Right?

That sounds pretty severe to me. I was surprised to not see some
emergency fix, even if that would have usage of embedded bare repos.


In some mails it was said to be social engineering, but I wouldn't
agree with that:
Social engineering is when one tricks a user into doing something
(security-wise) stupid, like pishing or the CEO-fraud.

Cloning/fetch and "inspect" through an arbitrary (untrusted) repo is
however IMO expected to base functionality of git. Unlike e.g. running
make or any other code from such repo.

It's as if libjpeg would contain some RCE hole, and one calls it social
engineering because it's only a problem when people display the wrong
images.


For git, the issue seems even more critical, given that the people
using it may be easily high-value targets for some attackers (and not a
ransom ware group or so, but rather something like APT - I guess they'd
be quite happy if they could easily infiltrate the computers of kernel
developers or such of similar critical projects).


IIRC other have previously proposed having a option in the system/user-
wide (only) git configuration, where one has to explicitly specify the
paths of the allowed embedded bare repos.

But as long as something like that or better is implemented... there
should be safe-out-of-the-box default, better last month than tomorrow
- at least if the issue is as critical as my understanding is.

Especially considering, that most end-users of git likely haven't even
heard about all that.

Something like a warning in git-fsck, which I think was also proposed,
definitely doesn't seem enough, cause when do regular users invoke
this?

Also the bare repo can be embedded with any commit in any branch, or
could even be removed again later (to hide traces but still wait for
people to check out some older revision).



TBH, given how critical (RCE) and how easy to exploit this issue seems,
I'm rather surprised that not more is done.

The original issue is open since April and even the safe.bareRepository
workaround is an opt-in fix.
At least it seems that the issue is not taken that extremely serious?
Is there even a CVE for it?

At least I, personally, don't use other repos anymore at all since back
then (which is of course like half of a showstopper for git)... and if
that's so easy to exploit, I wonder how anyone could.




As e.g. indicated in the LWN article, a similar problem exist for e.g.
a .git "hidden" in a tar, which is extracted an may be used for the
same purpose by an attacker.
Seems also quite easy to do and not really something an average user
would expect.
People may have things like git-prompt active and so just by changing
into the extracted tar they might be pwned.


So maybe there should be an option in the system/user wide config which
lists all repos (bare or non-bare) which are allowed. git clone could
e.g. automatically add a repo in there (of course it would make things
a bit less out-of-the-box when people e.g. move the repo dir - but
still better than an easy remote code execution).
That might also mitigate any shenanigans attackers could try via hooks
or similar.



What's the policy from git maintainers on all this?
Is it desired that any such holes are fixed (definitely - and not just
for 99% of all cases) or is the policy that people cannot clone repos
that aren't 100% trusted or use git on systems where e.g. possibly
untrusted archives with a ".git" are extracted?


Thanks,
Chris.