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.
