{"thread":{"id":"58395","subject":"status on security of embedded repos?","startedAt":"2022-09-03T18:48:56Z","lastAt":"2022-09-09T18:32:36Z","messageCount":8,"participants":["Christoph Anton Mitterer","Johannes Schindelin","Glen Choo"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"462580","messageId":"4e9ad5486e8a887f1e92cc4e401ca61be5f2bb9a.camel@scientia.org","threadId":"58395","inReplyTo":null,"subject":"status on security of embedded repos?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2022-09-03T18:48:43Z","receivedAt":"2022-09-03T18:48:56Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"Hey.\n\nA while ago there was this discussion about security issues with\nrespect to bare repos embedded in another repo[0][1].\n\n\nI just wondered what's the status on this? Was that fixed in a way that\none can clone untrusted repos and navigate / use git commands within\nthem, without any risk… or is it still open?\n\nSaw proposed patches like:\nhttps://lore.kernel.org/git/pull.1261.git.git.1651861810633.gitgitgadget@gmail.com/#r\n\nBut it seems at least as of git 2.37.2, ther's no safe.barerepository\noption, yet.\n\n\nAlso, couldn't the same happen for non-bare repos, too, or how is that\nprevented for such?\n\n\nThanks,\nChris.\n\n\n[0] https://lwn.net/ml/git/kl6lsfqpygsj.fsf@chooglen-macbookpro.roam.corp.google.com/\n[1] https://lwn.net/Articles/892755/\n"},{"id":"462623","messageId":"6sq30r84-1s65-91n4-5qoq-23s9q433sno1@tzk.qr","threadId":"58395","inReplyTo":"4e9ad5486e8a887f1e92cc4e401ca61be5f2bb9a.camel@scientia.org","subject":"Re: status on security of embedded repos?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-09-05T10:21:17Z","receivedAt":"2022-09-05T10:22:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Chris,\n\nOn Sat, 3 Sep 2022, Christoph Anton Mitterer wrote:\n\n> A while ago there was this discussion about security issues with\n> respect to bare repos embedded in another repo[0][1].\n>\n>\n> I just wondered what's the status on this? Was that fixed in a way that\n> one can clone untrusted repos and navigate / use git commands within\n> them, without any risk… or is it still open?\n>\n> Saw proposed patches like:\n> https://lore.kernel.org/git/pull.1261.git.git.1651861810633.gitgitgadget@gmail.com/#r\n\nAs you can see at the corresponding Pull Request, the patch series has\nbeen accepted:\nhttps://github.com/git/git/pull/1261#issuecomment-1193004345\n\nIf you follow the link to the commit\n(https://github.com/git/git/commit/18bbc795fc52), you will see that it is\nnot yet in any official tagged version (otherwise you would see the list\nof tags below the branch name).\n\nThis means that it will be part of the next release.\n\nThe current timeline for that release can be seen at\nhttps://tinyurl.com/gitcal, the projected date for Git v2.38.0 is October\n3rd, 2022.\n\nNote: The default will still be at `safe.bareRepository = all`. I foresee\nmyself setting this to `explicit` via my user-wide configuration.\nPotentially a future Git version will add deprecation warnings and an even\nmore distant Git version might switch the default. This is still up for\ndiscussion, I believe.\n\nCiao,\nJohannes\n"},{"id":"462631","messageId":"c209dc21f6826bbb60d75450e6f7f9ff2258d18c.camel@scientia.org","threadId":"58395","inReplyTo":"6sq30r84-1s65-91n4-5qoq-23s9q433sno1@tzk.qr","subject":"Re: status on security of embedded repos?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2022-09-05T13:22:14Z","receivedAt":"2022-09-05T13:29:59Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"Hey Johannes.\n\nThanks.\n\nIs it known whether this will automatically prevent the issue also for\nany 3rd party modules for git?\nI mean is special action needed by them to consider the option? Or is\nit likely that there are some which manually discover the git config\nand could thereby still suffer from the vulnerability.\n\n\nI assume the same wouldn't be possible for non-bare embedded repos? I\ntried to try this, but when git add(ing) such repo, it already warns\nthat the embedded (non-bare) repo would not be included in clones.\n\n\n\nOn Mon, 2022-09-05 at 12:21 +0200, Johannes Schindelin wrote:\n> Note: The default will still be at `safe.bareRepository = all`.\n\nThat seems like a not so secure default, given that probably only few\npeople will ever encounter embedded bare repos.\n\nOTOH, the attack surface seems rather big, if one just needs to clone\nsome arbitrary repo where one wants to look at some code, and is then\nin principle already fully vulnerable?!\n\n\nThanks,\nChris.\n"},{"id":"462656","messageId":"4697o162-0pop-4715-150r-2317p0n69581@tzk.qr","threadId":"58395","inReplyTo":"c209dc21f6826bbb60d75450e6f7f9ff2258d18c.camel@scientia.org","subject":"Re: status on security of embedded repos?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-09-06T13:56:48Z","receivedAt":"2022-09-06T15:44:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Chris,\n\nanswers inline.\n\nOn Mon, 5 Sep 2022, Christoph Anton Mitterer wrote:\n\n> Is it known whether this will automatically prevent the issue also for\n> any 3rd party modules for git?\n\nAs long as they use the core Git CLI at a new-enough version: yes.\n\nBut libgit2 and JGit, two separate Git implementations that are in wide\nuse, too, probably do not have support for this.\n\nIn other words, users of libgit2 & JGit will likely be unaffected by\nsetting `safe.bareRepository` and sill still need to take manual\nprecautions.\n\nIf you are using applications based on those projects, you might be\ninterested in porting support for `safe.bareRepository` to those projects\nand contribute the enhancement.\n\n> I mean is special action needed by them to consider the option? Or is\n> it likely that there are some which manually discover the git config\n> and could thereby still suffer from the vulnerability.\n>\n>\n> I assume the same wouldn't be possible for non-bare embedded repos? I\n> tried to try this, but when git add(ing) such repo, it already warns\n> that the embedded (non-bare) repo would not be included in clones.\n\nYes, indeed, `.git` entries in Git's tree objects are forbidden.\n\nCiao,\nJohannes\n\n> On Mon, 2022-09-05 at 12:21 +0200, Johannes Schindelin wrote:\n> > Note: The default will still be at `safe.bareRepository = all`.\n>\n> That seems like a not so secure default, given that probably only few\n> people will ever encounter embedded bare repos.\n>\n> OTOH, the attack surface seems rather big, if one just needs to clone\n> some arbitrary repo where one wants to look at some code, and is then\n> in principle already fully vulnerable?!\n>\n>\n> Thanks,\n> Chris.\n>\n"},{"id":"462712","messageId":"aeb235f7a914539ad50eff96479106f8c8ec8d48.camel@scientia.org","threadId":"58395","inReplyTo":"4697o162-0pop-4715-150r-2317p0n69581@tzk.qr","subject":"Re: status on security of embedded repos?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2022-09-07T14:05:33Z","receivedAt":"2022-09-07T14:05:49Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"Hey Johannes.\n\n\nOn Tue, 2022-09-06 at 15:56 +0200, Johannes Schindelin wrote:\n> But libgit2 and JGit, two separate Git implementations that are in\n> wide\n> use, too, probably do not have support for this.\n> \n> In other words, users of libgit2 & JGit will likely be unaffected by\n> setting `safe.bareRepository` and sill still need to take manual\n> precautions.\n\n\n> If you are using applications based on those projects, you might be\n> interested in porting support for `safe.bareRepository` to those\n> projects\n> and contribute the enhancement.\n\nWell I'm not really in any way experienced with git's code ... so I'm\nrather just wearing a user hat.\n\nWouldn't it make sense if someone really experienced within git\ndevelopment to kinda follow that up for other projects, too?\nSure, it's other projects,... but still, the vulnerability seems rather\ncritical and many people using git also use such things like libgit2\n(potentially even without knowing).\n\nI can however open a ticket over at libgit2, if that helps you.\n\nAlso, even with default settings, git, AFAIU, would be still vulnerable\nfor the majority of people (many of whom likely haven't even heard\nabout the issue).\n\n\n> \n> Yes, indeed, `.git` entries in Git's tree objects are forbidden.\n\nAnd I blindly assume that this is not only checked and forbidden when\ntrying to commit, but also when cloning/fetching/etc.?!\n\n\nThanks for your answers :-)\nChris.\n"},{"id":"462813","messageId":"kl6ltu5h954s.fsf@chooglen-macbookpro.roam.corp.google.com","threadId":"58395","inReplyTo":"aeb235f7a914539ad50eff96479106f8c8ec8d48.camel@scientia.org","subject":"Re: status on security of embedded repos?","fromName":"Glen Choo","fromEmail":"chooglen@google.com","sentAt":"2022-09-08T16:56:35Z","receivedAt":"2022-09-08T16:57:39Z","isPatch":false,"sender":{"key":"glencbz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58092771?v=4"},"body":"Hi Christoph!\n\nI'm the original author of safe.bareRepository. I didn't chime in\nearlier because I didn't have anything to add on top of Johannes'\nexcellent answers :)\n\nChristoph Anton Mitterer <calestyo@scientia.org> writes:\n\n> Hey Johannes.\n>\n>\n> On Tue, 2022-09-06 at 15:56 +0200, Johannes Schindelin wrote:\n>> But libgit2 and JGit, two separate Git implementations that are in\n>> wide\n>> use, too, probably do not have support for this.\n>> \n>> In other words, users of libgit2 & JGit will likely be unaffected by\n>> setting `safe.bareRepository` and sill still need to take manual\n>> precautions.\n>\n>\n>> If you are using applications based on those projects, you might be\n>> interested in porting support for `safe.bareRepository` to those\n>> projects\n>> and contribute the enhancement.\n>\n> Well I'm not really in any way experienced with git's code ... so I'm\n> rather just wearing a user hat.\n>\n> Wouldn't it make sense if someone really experienced within git\n> development to kinda follow that up for other projects, too?\n> Sure, it's other projects,... but still, the vulnerability seems rather\n> critical and many people using git also use such things like libgit2\n> (potentially even without knowing).\n\nIn a world where we had someone who headed all of the Git ecosystem\nmaking these decisions, that sounds like a great outcome. Unfortunately,\nI don't think such a person exists.\n\nPerhaps this sort of \"really experienced person working with other\nprojects\" has happened before (I'm relatively new to the project), but\nit sounds very very difficult to do in practice. For example, you'd have\nto answer questions like how do we know which projects to engage with? \ne.g. we'd probaby need JGit and libgit2, but what about smaller\nimplementations like gitoxide, editor plugins, and the long tail of\nother projects in the space? The technical fixes probably aren't hard,\nbut communication and collaboration with so many projects sounds really\ndifficult.\n\n> I can however open a ticket over at libgit2, if that helps you.\n\nIt would help all users :)\n\n> Also, even with default settings, git, AFAIU, would be still vulnerable\n> for the majority of people (many of whom likely haven't even heard\n> about the issue).\n\nYes. We've talked earlier about finding a safer default for\nsafe.bareRepository; but it hasn't been highly prioritized. Feedback\nlike yours is very valuable because it gives us a sense of how important\nthis is and can definitely have an impact on prioritization.\n\n>> \n>> Yes, indeed, `.git` entries in Git's tree objects are forbidden.\n>\n> And I blindly assume that this is not only checked and forbidden when\n> trying to commit, but also when cloning/fetching/etc.?!\n\nYes, the checks are quite extensive :) `.git` isn't allowed in the\nindex, so you cannot checkout a `.git` anywhere.\n\n>\n>\n> Thanks for your answers :-)\n> Chris.\n"},{"id":"462842","messageId":"c5ce968cb5f764032345b654857c21745f0c1b1a.camel@scientia.org","threadId":"58395","inReplyTo":"kl6ltu5h954s.fsf@chooglen-macbookpro.roam.corp.google.com","subject":"Re: status on security of embedded repos?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2022-09-09T00:05:11Z","receivedAt":"2022-09-09T00:05:27Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"Hey Glen.\n\n\nOn Thu, 2022-09-08 at 09:56 -0700, Glen Choo wrote:\n> In a world where we had someone who headed all of the Git ecosystem\n> making these decisions, that sounds like a great outcome.\n> Unfortunately,\n> I don't think such a person exists.\n\nWell it's clear that there's no such one, but at least there should be\npeople far more experienced than me (who in terms of git is nothing\nmore than an average user)... and would be far more able to see which\nother projects might be affected.\n...\n\n> how do we know which projects to engage\n> with? \n> e.g. we'd probaby need JGit and libgit2, but what about smaller\n> implementations like gitoxide, editor plugins, and the long tail of\n> other projects in the space?\n\n... clear, too, but again, you already named more than I'd have known\nabout ;-) ... I mean I knew libgit2 (which is utilised by some git\ntools I use) and had heard of jgit before, though I don't use it.\n\nThese are some other git related tools, which I would assume are used\nwidespread or in some more (security) critical places:\n- dgit\n- git-debrebase\n- git-buildpackage\n(the above being used in Debian package management)\n\n- git-remote-gcrypt\n- git-evtag\n(the above being used by who likely have high security requirements)\n\n- libgit-wrapper-perl\n\nall these seem to either depend on git itself or libgit2, so one can\nhope they'd be safe as soon as git and libgit2 were. But I guess it's\nreally not more than just \"hope\", because any of them could e.g.\nmanually look for git config and do stuff with it, thereby picking up\nthat from an attacker in an embedded bare repo. Right?\n\nNot sure what about things like:\n- meld (which has *some* git support, but probably implements all that\n  by itself - at least it doesn't depend on the usual suspects)\n\nBut even tools like gitg, which use libgit2 or libgit-wrapper-perl\nwhich uses git itself could still \"manually\" read some config file,\nthereby avoiding any \"fix\" of safe.bareRepository.\n\n\n\n> > I can however open a ticket over at libgit2, if that helps you.\n> \n> It would help all users :)\n\nI've did this now for libgit2:\nhttps://github.com/libgit2/libgit2/issues/6400\n\nBut I'd really hope someone with more background in that field could\nfollow that up for other 3rd party projects.\n\n\n\n> > Also, even with default settings, git, AFAIU, would be still\n> > vulnerable\n> > for the majority of people (many of whom likely haven't even heard\n> > about the issue).\n> \n> Yes. We've talked earlier about finding a safer default for\n> safe.bareRepository; but it hasn't been highly prioritized. Feedback\n> like yours is very valuable because it gives us a sense of how\n> important\n> this is and can definitely have an impact on prioritization.\n\nMaybe I misunderstand the issue and make just a lot of noise for\nnothing.\n\nMy understanding was, that an embedded bare repo, would allow arbitrary\ncode execution, when one has cloned or fetched that as part of some\nregularly used repo... and as soon as one runs git commands inside of\nthat.\nRight?\n\nThat sounds pretty severe to me. I was surprised to not see some\nemergency fix, even if that would have usage of embedded bare repos.\n\n\nIn some mails it was said to be social engineering, but I wouldn't\nagree with that:\nSocial engineering is when one tricks a user into doing something\n(security-wise) stupid, like pishing or the CEO-fraud.\n\nCloning/fetch and \"inspect\" through an arbitrary (untrusted) repo is\nhowever IMO expected to base functionality of git. Unlike e.g. running\nmake or any other code from such repo.\n\nIt's as if libjpeg would contain some RCE hole, and one calls it social\nengineering because it's only a problem when people display the wrong\nimages.\n\n\nFor git, the issue seems even more critical, given that the people\nusing it may be easily high-value targets for some attackers (and not a\nransom ware group or so, but rather something like APT - I guess they'd\nbe quite happy if they could easily infiltrate the computers of kernel\ndevelopers or such of similar critical projects).\n\n\nIIRC other have previously proposed having a option in the system/user-\nwide (only) git configuration, where one has to explicitly specify the\npaths of the allowed embedded bare repos.\n\nBut as long as something like that or better is implemented... there\nshould be safe-out-of-the-box default, better last month than tomorrow\n- at least if the issue is as critical as my understanding is.\n\nEspecially considering, that most end-users of git likely haven't even\nheard about all that.\n\nSomething like a warning in git-fsck, which I think was also proposed,\ndefinitely doesn't seem enough, cause when do regular users invoke\nthis?\n\nAlso the bare repo can be embedded with any commit in any branch, or\ncould even be removed again later (to hide traces but still wait for\npeople to check out some older revision).\n\n\n\nTBH, given how critical (RCE) and how easy to exploit this issue seems,\nI'm rather surprised that not more is done.\n\nThe original issue is open since April and even the safe.bareRepository\nworkaround is an opt-in fix.\nAt least it seems that the issue is not taken that extremely serious?\nIs there even a CVE for it?\n\nAt least I, personally, don't use other repos anymore at all since back\nthen (which is of course like half of a showstopper for git)... and if\nthat's so easy to exploit, I wonder how anyone could.\n\n\n\n\nAs e.g. indicated in the LWN article, a similar problem exist for e.g.\na .git \"hidden\" in a tar, which is extracted an may be used for the\nsame purpose by an attacker.\nSeems also quite easy to do and not really something an average user\nwould expect.\nPeople may have things like git-prompt active and so just by changing\ninto the extracted tar they might be pwned.\n\n\nSo maybe there should be an option in the system/user wide config which\nlists all repos (bare or non-bare) which are allowed. git clone could\ne.g. automatically add a repo in there (of course it would make things\na bit less out-of-the-box when people e.g. move the repo dir - but\nstill better than an easy remote code execution).\nThat might also mitigate any shenanigans attackers could try via hooks\nor similar.\n\n\n\nWhat's the policy from git maintainers on all this?\nIs it desired that any such holes are fixed (definitely - and not just\nfor 99% of all cases) or is the policy that people cannot clone repos\nthat aren't 100% trusted or use git on systems where e.g. possibly\nuntrusted archives with a \".git\" are extracted?\n\n\nThanks,\nChris.\n\n"},{"id":"462882","messageId":"0100c85e9395b0a0768a136cf1ca1373e716cb6f.camel@scientia.org","threadId":"58395","inReplyTo":"c5ce968cb5f764032345b654857c21745f0c1b1a.camel@scientia.org","subject":"Re: status on security of embedded repos?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2022-09-09T18:26:50Z","receivedAt":"2022-09-09T18:32:36Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Fri, 2022-09-09 at 02:05 +0200, Christoph Anton Mitterer wrote:\n> As e.g. indicated in the LWN article, a similar problem exist for\n> e.g.\n> a .git \"hidden\" in a tar, which is extracted an may be used for the\n> same purpose by an attacker.\n\nI spent some more thought about that, and I'd even also call this case\na security hole in git.\n\n\nIf someone downloads an untrusted tar and executes some code within it\n(makefile, binary, script)... then it's quite clear to anyone that this\nmay allow an attacker to do as he likes.\n\nBut if the tar contains for example a PDF or some image and these are\ndisplayed as thumbnail by e.g. a GUI file browser, then no one would\nsay it's a wrongdoing of the user (as one would say if some code is\nactively executed by the user) - but rather simply some security hole\nin e.g. the PDF library.\n\n\nThe solution proposed by some others of specifying the pathnames of\nknown repos may be a bit unhandy in practise.\n\nWas it considered to use magic cookies? Either alone or in combination\nwith pathnames?\n\n\nWhenever a user runs git the first time, some jey could be created in\nthe per-user git config.\n\nAnd in git repos some magic cookie (e.g. something signed by the per-\nuser key) would need to be present for git to consider them as such.\n\nThere could further be a system-wide key, for e.g. shared repos.\n\nWhen the user itself e.g. clones a repo, the cookie would be\nautomatically created, so such repos would continue to work out of the\nbox.\n\nAny action in git, that introduces an embedded bare repo (e.g. when a\nclone or fetch action finds one) would notice the user (when run\ninteractively) about that, and asks whether it should be trusted.\nIf so, in the system/user-wide config, it could be stored, that for\nthat particular (per-repo) magic cookie, an embedded bare repo at the\njust accepted path is allowed.\nShould the repo add another one, it wouldn't be allowed by that\nprevious cookie.\n\nA further setting could allow to configure whether the embedded bare\nrepo should only be allowed, when the config/hooks/etc (everything that\nis security critical) haven't changed since the time of being accepted,\ne.g. by creating some hash over them.\n\nThis would prevent any attacks where first the embedded bare repo's git\nconfig looks fine, but later some evil stuff is added.\n\nHaving this as an option would still allow people to fully trust the\nembedded bare repos (either any of them, or just in an accepted path)\nof a given repo (if the trust that).\n\n\n\nSince in the non-bare repo, the per-repo cookie would set whether it is\nallowed or not... and not a path... the user could move the repo\ndirectory as he wishes (without the need to adapt pathnames). The paths\nof the allowed embedded-repos would be relative to the repo they're\npart of.\n\nA new git command could allow to manage this, e.g. having different\nkeys, migrating them, revoking them, listing any allowed embedded non-\nbares, etc..\nThat would also enable to allow normal/embedded repos when things are\nnot running non-interactively.\n\n\nOf course the keys and cookies must never be published.\n\n\nOne could even combine all that with some path-based authorisation\n(i.e. storing the pathnames of trusted repos in the system/per-user\nconfig, in addition to the cookies)... and only allow a repo if both\nmatch... and if e.g. only one matches, ask in interactive mode.\n\n\nThe defaults of all these should be the most safest one, i.e. not\nallowing embedded bare repos per default, and if the user manually\naccepts one, then per default only allow that particular one in the\nrepo and only with the config/hooks/etc. as of the current state.\n\n\nOne might even think of an option, to not checkout files of embedded\nbar repos at all, when no permissions are set, in order to also protect\nany 3rd party programs that are not secured against the attack with\nembedded bares.\n\n\n\n\nIf things work out as I hope, this should fix both issues, the attacks\nwith embedded bare repos, and the ones with \"unexpected\" \".git\" dirs in\nuntrusted content like archives/etc..\nAt least as long all tools (especially 3rd party) support the whole\nthing in all places.\n\nAnd it should still be \"rather\" comfortable. Sure, not as out-of-the-\nbox as right now, but still better than remote code execution.\n\n\nAny thoughts about such system?\n\nThanks,\nChris.\n"}]}