Re: Bare repositories in the working tree are a security risk

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> Then we'd probably be better off just walking up the entire hierarchy
>> and excluding worktrees from embedded bare repositories, or otherwise
>> restricting the config we read.  That will probably mean we'll need to
>> walk the entire directory hierarchy to see if it's embedded (or at least
>> to the root of the device) in such a case, but that should be relatively
>> uncommon.
>
> I find this direction to notice iffy "user data" and disable it
> quite reasonable.  A configuration file can define alias, and it
> would be yet another attack vector to overload common ones users
> likely use ("git co", "git st", ...).  There may also be a hooks/
> directory.
>
> I wonder if it is an acceptable defence to deliberately "corrupt"
> such user data when we notice that they smell fishy, perhaps by
> renaming "config" and "hooks", when they are found next to "HEAD"
> and "objects" and "refs", to "config.disabled" and "hooks.disabled"?
> I am just thinking aloud without assessing if it is sensible or
> feasible at ths point.

> I am not sure if "walking the hierarchy up" is an effective enough
> defence offhand.  Do we consider it too much social engineering to
> make the user follow cloning instruction of the malicious project to
> prepare a repository, with core.worktree set to elsewhere, and pull
> into it?  Since walking up from any subdirectory of the directory
> the core.worktree points at will never see a directory, with ".git/"
> subdirectory that is the malicious project, "git status" run in the
> "embedded" place in such a scenario will not notice that it is a
> repository lookalike that came from outside.  But we can write it
> off as an approach needing too much  social engineering, that's OK.