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.
