status on security of embedded repos?

status on security of embedded repos?

[Christoph Anton Mitterer]

Hey.

A while ago there was this discussion about security issues with
respect to bare repos embedded in another repo[0][1].


I just wondered what's the status on this? Was that fixed in a way that
one can clone untrusted repos and navigate / use git commands within
them, without any risk… or is it still open?

Saw proposed patches like:
https://lore.kernel.org/git/pull.1261.git.git.1651861810633.gitgitgadget@gmail.com/#r

But it seems at least as of git 2.37.2, ther's no safe.barerepository
option, yet.


Also, couldn't the same happen for non-bare repos, too, or how is that
prevented for such?


Thanks,
Chris.


[0] https://lwn.net/ml/git/kl6lsfqpygsj.fsf@chooglen-macbookpro.roam.corp.google.com/
[1] https://lwn.net/Articles/892755/

Re: status on security of embedded repos?

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

Hi Chris,

On Sat, 3 Sep 2022, Christoph Anton Mitterer wrote:

> A while ago there was this discussion about security issues with
> respect to bare repos embedded in another repo[0][1].
>
>
> I just wondered what's the status on this? Was that fixed in a way that
> one can clone untrusted repos and navigate / use git commands within
> them, without any risk… or is it still open?
>
> Saw proposed patches like:
> https://lore.kernel.org/git/pull.1261.git.git.1651861810633.gitgitgadget@gmail.com/#r

As you can see at the corresponding Pull Request, the patch series has
been accepted:
https://github.com/git/git/pull/1261#issuecomment-1193004345

If you follow the link to the commit
(https://github.com/git/git/commit/18bbc795fc52), you will see that it is
not yet in any official tagged version (otherwise you would see the list
of tags below the branch name).

This means that it will be part of the next release.

The current timeline for that release can be seen at
https://tinyurl.com/gitcal, the projected date for Git v2.38.0 is October
3rd, 2022.

Note: The default will still be at `safe.bareRepository = all`. I foresee
myself setting this to `explicit` via my user-wide configuration.
Potentially a future Git version will add deprecation warnings and an even
more distant Git version might switch the default. This is still up for
discussion, I believe.

Ciao,
Johannes

Re: status on security of embedded repos?

[Christoph Anton Mitterer]

Hey Johannes.

Thanks.

Is it known whether this will automatically prevent the issue also for
any 3rd party modules for git?
I mean is special action needed by them to consider the option? Or is
it likely that there are some which manually discover the git config
and could thereby still suffer from the vulnerability.


I assume the same wouldn't be possible for non-bare embedded repos? I
tried to try this, but when git add(ing) such repo, it already warns
that the embedded (non-bare) repo would not be included in clones.



On Mon, 2022-09-05 at 12:21 +0200, Johannes Schindelin wrote:
> Note: The default will still be at `safe.bareRepository = all`.

That seems like a not so secure default, given that probably only few
people will ever encounter embedded bare repos.

OTOH, the attack surface seems rather big, if one just needs to clone
some arbitrary repo where one wants to look at some code, and is then
in principle already fully vulnerable?!


Thanks,
Chris.

Re: status on security of embedded repos?

[Johannes Schindelin]

Hi Chris,

answers inline.

On Mon, 5 Sep 2022, Christoph Anton Mitterer wrote:

> Is it known whether this will automatically prevent the issue also for
> any 3rd party modules for git?

As long as they use the core Git CLI at a new-enough version: yes.

But libgit2 and JGit, two separate Git implementations that are in wide
use, too, probably do not have support for this.

In other words, users of libgit2 & JGit will likely be unaffected by
setting `safe.bareRepository` and sill still need to take manual
precautions.

If you are using applications based on those projects, you might be
interested in porting support for `safe.bareRepository` to those projects
and contribute the enhancement.

> I mean is special action needed by them to consider the option? Or is
> it likely that there are some which manually discover the git config
> and could thereby still suffer from the vulnerability.
>
>
> I assume the same wouldn't be possible for non-bare embedded repos? I
> tried to try this, but when git add(ing) such repo, it already warns
> that the embedded (non-bare) repo would not be included in clones.

Yes, indeed, `.git` entries in Git's tree objects are forbidden.

Ciao,
Johannes

> On Mon, 2022-09-05 at 12:21 +0200, Johannes Schindelin wrote:
> > Note: The default will still be at `safe.bareRepository = all`.
>
> That seems like a not so secure default, given that probably only few
> people will ever encounter embedded bare repos.
>
> OTOH, the attack surface seems rather big, if one just needs to clone
> some arbitrary repo where one wants to look at some code, and is then
> in principle already fully vulnerable?!
>
>
> Thanks,
> Chris.
>

Re: status on security of embedded repos?

[Christoph Anton Mitterer]

Hey Johannes.


On Tue, 2022-09-06 at 15:56 +0200, Johannes Schindelin wrote:
> But libgit2 and JGit, two separate Git implementations that are in
> wide
> use, too, probably do not have support for this.
> 
> In other words, users of libgit2 & JGit will likely be unaffected by
> setting `safe.bareRepository` and sill still need to take manual
> precautions.


> If you are using applications based on those projects, you might be
> interested in porting support for `safe.bareRepository` to those
> projects
> and contribute the enhancement.

Well I'm not really in any way experienced with git's code ... so I'm
rather just wearing a user hat.

Wouldn't it make sense if someone really experienced within git
development to kinda follow that up for other projects, too?
Sure, it's other projects,... but still, the vulnerability seems rather
critical and many people using git also use such things like libgit2
(potentially even without knowing).

I can however open a ticket over at libgit2, if that helps you.

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, indeed, `.git` entries in Git's tree objects are forbidden.

And I blindly assume that this is not only checked and forbidden when
trying to commit, but also when cloning/fetching/etc.?!


Thanks for your answers :-)
Chris.

Re: status on security of embedded repos?

[Glen Choo]

Hi Christoph!

I'm the original author of safe.bareRepository. I didn't chime in
earlier because I didn't have anything to add on top of Johannes'
excellent answers :)

Christoph Anton Mitterer <calestyo@scientia.org> writes:

> Hey Johannes.
>
>
> On Tue, 2022-09-06 at 15:56 +0200, Johannes Schindelin wrote:
>> But libgit2 and JGit, two separate Git implementations that are in
>> wide
>> use, too, probably do not have support for this.
>> 
>> In other words, users of libgit2 & JGit will likely be unaffected by
>> setting `safe.bareRepository` and sill still need to take manual
>> precautions.
>
>
>> If you are using applications based on those projects, you might be
>> interested in porting support for `safe.bareRepository` to those
>> projects
>> and contribute the enhancement.
>
> Well I'm not really in any way experienced with git's code ... so I'm
> rather just wearing a user hat.
>
> Wouldn't it make sense if someone really experienced within git
> development to kinda follow that up for other projects, too?
> Sure, it's other projects,... but still, the vulnerability seems rather
> critical and many people using git also use such things like libgit2
> (potentially even without knowing).

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.

Perhaps this sort of "really experienced person working with other
projects" has happened before (I'm relatively new to the project), but
it sounds very very difficult to do in practice. For example, you'd have
to answer questions like 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? The technical fixes probably aren't hard,
but communication and collaboration with so many projects sounds really
difficult.

> I can however open a ticket over at libgit2, if that helps you.

It would help all users :)

> 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.

>> 
>> Yes, indeed, `.git` entries in Git's tree objects are forbidden.
>
> And I blindly assume that this is not only checked and forbidden when
> trying to commit, but also when cloning/fetching/etc.?!

Yes, the checks are quite extensive :) `.git` isn't allowed in the
index, so you cannot checkout a `.git` anywhere.

>
>
> Thanks for your answers :-)
> Chris.

Re: status on security of embedded repos?

[Christoph Anton Mitterer]

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.

Re: status on security of embedded repos?

[Christoph Anton Mitterer]

On Fri, 2022-09-09 at 02:05 +0200, Christoph Anton Mitterer wrote:
> 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.

I spent some more thought about that, and I'd even also call this case
a security hole in git.


If someone downloads an untrusted tar and executes some code within it
(makefile, binary, script)... then it's quite clear to anyone that this
may allow an attacker to do as he likes.

But if the tar contains for example a PDF or some image and these are
displayed as thumbnail by e.g. a GUI file browser, then no one would
say it's a wrongdoing of the user (as one would say if some code is
actively executed by the user) - but rather simply some security hole
in e.g. the PDF library.


The solution proposed by some others of specifying the pathnames of
known repos may be a bit unhandy in practise.

Was it considered to use magic cookies? Either alone or in combination
with pathnames?


Whenever a user runs git the first time, some jey could be created in
the per-user git config.

And in git repos some magic cookie (e.g. something signed by the per-
user key) would need to be present for git to consider them as such.

There could further be a system-wide key, for e.g. shared repos.

When the user itself e.g. clones a repo, the cookie would be
automatically created, so such repos would continue to work out of the
box.

Any action in git, that introduces an embedded bare repo (e.g. when a
clone or fetch action finds one) would notice the user (when run
interactively) about that, and asks whether it should be trusted.
If so, in the system/user-wide config, it could be stored, that for
that particular (per-repo) magic cookie, an embedded bare repo at the
just accepted path is allowed.
Should the repo add another one, it wouldn't be allowed by that
previous cookie.

A further setting could allow to configure whether the embedded bare
repo should only be allowed, when the config/hooks/etc (everything that
is security critical) haven't changed since the time of being accepted,
e.g. by creating some hash over them.

This would prevent any attacks where first the embedded bare repo's git
config looks fine, but later some evil stuff is added.

Having this as an option would still allow people to fully trust the
embedded bare repos (either any of them, or just in an accepted path)
of a given repo (if the trust that).



Since in the non-bare repo, the per-repo cookie would set whether it is
allowed or not... and not a path... the user could move the repo
directory as he wishes (without the need to adapt pathnames). The paths
of the allowed embedded-repos would be relative to the repo they're
part of.

A new git command could allow to manage this, e.g. having different
keys, migrating them, revoking them, listing any allowed embedded non-
bares, etc..
That would also enable to allow normal/embedded repos when things are
not running non-interactively.


Of course the keys and cookies must never be published.


One could even combine all that with some path-based authorisation
(i.e. storing the pathnames of trusted repos in the system/per-user
config, in addition to the cookies)... and only allow a repo if both
match... and if e.g. only one matches, ask in interactive mode.


The defaults of all these should be the most safest one, i.e. not
allowing embedded bare repos per default, and if the user manually
accepts one, then per default only allow that particular one in the
repo and only with the config/hooks/etc. as of the current state.


One might even think of an option, to not checkout files of embedded
bar repos at all, when no permissions are set, in order to also protect
any 3rd party programs that are not secured against the attack with
embedded bares.




If things work out as I hope, this should fix both issues, the attacks
with embedded bare repos, and the ones with "unexpected" ".git" dirs in
untrusted content like archives/etc..
At least as long all tools (especially 3rd party) support the whole
thing in all places.

And it should still be "rather" comfortable. Sure, not as out-of-the-
box as right now, but still better than remote code execution.


Any thoughts about such system?

Thanks,
Chris.