On 2022-04-06 at 22:43:08, Glen Choo wrote:
> An attack might look like this:
> 
> * Attacker creates a repository where subdirectory "Documentation/" is a bare
>   repository i.e. it contains "HEAD", "refs/" and "objects/" [4]. Attacker
>   also adds "config" with a malicious setting for core.fsmonitor.
> * Attacker convinces User to read their project's documentation by `git
>   clone`-ing their repository and inspecting the "Documentation/" directory.
> * User cd-s into "Documentation/" and their shell prompt runs `git status`,
>   executing the core.fsmonitor command defined by Attacker.

As mentioned elsewhere, git status doesn't work without a working tree.

> = Next steps
> 
> I propose that we prevent repositories from containing bare repositories by
> doing the following (in order):
> 
> * Implement (2) by adding a new fsck message "embeddedBareRepo".
>   * When this is done, hosting sites can hopefully use this capability to
>     prevent transmission, and help us understand the prevalence of such attacks.
> * Implement (1b) by teaching unpack_trees.c to check whether the tree contains
>   an entire bare repo, and die() if so. This will be guarded by a
>   defaults-to-true config value.
>   * This would only block a bare repo from being written in a single operation.
>     It wouldn’t stop a user from writing a bare repo entry-by-entry using "git
>     checkout <path>", but the amount of social engineering required probably
>     renders this attack infeasible.
>   * As I noted earlier, I foresee some difficulty actually implementing this
>     because I don’t think we have facilities for checking multiple tree entries
>     at once.

I'm aware of repositories that happen to break in this case.  It's not
uncommon to embed bare repositories when working with tools that involve
Git, and this will definitely break them.  git fast-import isn't always
a valid option because the test data may involve specific structures or
tooling that can't be replicated that way, or it involves things like
commit signatures which aren't round-tripped.

Instead, I'd rather see us avoid executing any program from the config
or any hooks in a bare repository without a working tree (except for
pushes).  I think that would avoid breaking things while still improving
security.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA