* status on security of embedded repos? @ 2022-09-03 18:48 Christoph Anton Mitterer 2022-09-05 10:21 ` Johannes Schindelin 0 siblings, 1 reply; 8+ messages in thread From: Christoph Anton Mitterer @ 2022-09-03 18:48 UTC (permalink / raw) To: git 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: status on security of embedded repos? 2022-09-03 18:48 status on security of embedded repos? Christoph Anton Mitterer @ 2022-09-05 10:21 ` Johannes Schindelin 2022-09-05 13:22 ` Christoph Anton Mitterer 0 siblings, 1 reply; 8+ messages in thread From: Johannes Schindelin @ 2022-09-05 10:21 UTC (permalink / raw) To: Christoph Anton Mitterer; +Cc: git [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: status on security of embedded repos? 2022-09-05 10:21 ` Johannes Schindelin @ 2022-09-05 13:22 ` Christoph Anton Mitterer 2022-09-06 13:56 ` Johannes Schindelin 0 siblings, 1 reply; 8+ messages in thread From: Christoph Anton Mitterer @ 2022-09-05 13:22 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: status on security of embedded repos? 2022-09-05 13:22 ` Christoph Anton Mitterer @ 2022-09-06 13:56 ` Johannes Schindelin 2022-09-07 14:05 ` Christoph Anton Mitterer 0 siblings, 1 reply; 8+ messages in thread From: Johannes Schindelin @ 2022-09-06 13:56 UTC (permalink / raw) To: Christoph Anton Mitterer; +Cc: git 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. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: status on security of embedded repos? 2022-09-06 13:56 ` Johannes Schindelin @ 2022-09-07 14:05 ` Christoph Anton Mitterer 2022-09-08 16:56 ` Glen Choo 0 siblings, 1 reply; 8+ messages in thread From: Christoph Anton Mitterer @ 2022-09-07 14:05 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: status on security of embedded repos? 2022-09-07 14:05 ` Christoph Anton Mitterer @ 2022-09-08 16:56 ` Glen Choo 2022-09-09 0:05 ` Christoph Anton Mitterer 0 siblings, 1 reply; 8+ messages in thread From: Glen Choo @ 2022-09-08 16:56 UTC (permalink / raw) To: Christoph Anton Mitterer, Johannes Schindelin; +Cc: git 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: status on security of embedded repos? 2022-09-08 16:56 ` Glen Choo @ 2022-09-09 0:05 ` Christoph Anton Mitterer 2022-09-09 18:26 ` Christoph Anton Mitterer 0 siblings, 1 reply; 8+ messages in thread From: Christoph Anton Mitterer @ 2022-09-09 0:05 UTC (permalink / raw) To: Glen Choo, Johannes Schindelin; +Cc: git 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: status on security of embedded repos? 2022-09-09 0:05 ` Christoph Anton Mitterer @ 2022-09-09 18:26 ` Christoph Anton Mitterer 0 siblings, 0 replies; 8+ messages in thread From: Christoph Anton Mitterer @ 2022-09-09 18:26 UTC (permalink / raw) To: Glen Choo, Johannes Schindelin; +Cc: git 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-09-09 18:32 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-03 18:48 status on security of embedded repos? Christoph Anton Mitterer 2022-09-05 10:21 ` Johannes Schindelin 2022-09-05 13:22 ` Christoph Anton Mitterer 2022-09-06 13:56 ` Johannes Schindelin 2022-09-07 14:05 ` Christoph Anton Mitterer 2022-09-08 16:56 ` Glen Choo 2022-09-09 0:05 ` Christoph Anton Mitterer 2022-09-09 18:26 ` Christoph Anton Mitterer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.