LWN: Comments on "The risks of embedded bare repositories in Git"

The risks of embedded bare repositories in Git

NYKevin — Sun, 01 May 2022 18:31:05 +0000

Yes, I'm aware of that.

I guess my concern is that a user might have a setup like this:

1. The user regularly clones untrusted Git repositories, for whatever reason.
2. If a repository containes a .git directory (actually checked in, not in the root of the repo), then the user (or some software acting on behalf of the user) will avoid cloning that repo, because they don't want to deal with the possibility of corrupt/malicious sub-repositories.
3. Bare repositories don't contain a .git directory, so this doesn't work.

The risks of embedded bare repositories in Git

timon — Sat, 30 Apr 2022 13:31:14 +0000

> If a bare repo is literally just a directory with magic contents

Well, any git repo is just a directory with magic contents. Instead of `git init foo` you could do a minimal git init by hand and get a working repository:

mkdir -p foo/.git/objects
mkdir -p foo/.git/refs
echo 'ref: refs/heads/main' > foo/.git/HEAD

The risks of embedded bare repositories in Git

NYKevin — Fri, 29 Apr 2022 22:39:02 +0000

Now I'm wondering if a malicious user could construct an invalid bare repo in such a way that it causes Git to segfault and/or execute arbitrary code. If a bare repo is literally just a directory with magic contents, that seems like a possible outcome...

The risks of embedded bare repositories in Git

glasserc — Fri, 29 Apr 2022 18:39:49 +0000

It's a little surprising that Git still considers it a bare repository even after changing the core.bare setting to false! Glen Choo writes in the original post that apparently Git considers a directory a bare repository if it has subdirectories called "HEAD", "refs/" and "objects/". TIL!

The risks of embedded bare repositories in Git

johill — Fri, 29 Apr 2022 14:42:06 +0000

It does in fact not even like to check out such a repo, saying

"error: invalid path 'inner/.git/config'"

or such things.

The risks of embedded bare repositories in Git

mathstuf — Fri, 29 Apr 2022 12:13:25 +0000

Full repos show up as submodules which go through `clone` and therefore do not pull a config file. Maybe one could craft a tree to commit a non-bare repository, but the tooling would likely barf as it would expect a submodule or try to convert it to one at some point.

The risks of embedded bare repositories in Git

marcH — Fri, 29 Apr 2022 06:09:30 +0000

True - except web sandboxing (Javascript / WebAssembly etc.) has stood the test of time.

Javascript did really blur that line and created something new and intermediate between "just looking" and "running" but it produced something useful and incredibly popular and... it worked.

The risks of embedded bare repositories in Git

marcH — Fri, 29 Apr 2022 05:45:01 +0000

> "git clone" can actually verify that what it received is consistent,

You can but do you actually verify every time?

When my "neighbour" tells me "take a quick _look_ at this project" she won't give me a SHA1 to make sure I'm looking at the exact same, audited and "safe" version of the project clone that she has right now. Because I'm _just looking_ so that would be overkill and overhead. If she wants me to _use_ the project then it's a totally different story and then yes she will probably point me at a specific git tag, maybe even a signed one.

> whereas for a Word document via the email I can't even easily check it's the same thing my neighbour got.

For a Word document you must indeed trust that the server you're downloading it from has not been hacked in the meantime which is in theory not required for git but it that really a huge security difference in practice? Also, you neighbor will likely have sent you the Word doc by email directly :-)

I think all these "secure transport" differences are fairly minor and TBH mostly off-topic compared to the very sneaky loss of a safe "read only" mode. Even non-technical users tend to understand the security difference between merely reading media and running code. I think anything blurring that conceptually simple et very useful line is doing users and security a great disservice - as Office macros did for many years.

The risks of embedded bare repositories in Git

Alan.Stern — Fri, 29 Apr 2022 02:32:19 +0000

Maybe I'm dumb, but I don't see why the article concentrates on the dangers of embedded bare repositories. Isn't any embedded repository just as potentially dangerous, whether it is bare or not?

The risks of embedded bare repositories in Git

pabs — Fri, 29 Apr 2022 02:25:34 +0000

Yep, that is where the idea came from; I'm one of the upstream maintainers of myrepos, and use it regularly, although not the mrtrust feature.

The risks of embedded bare repositories in Git

pabs — Fri, 29 Apr 2022 02:24:27 +0000

Right, although that doesn't solve the issue that k3ninho mentions; running arbitrary unreviewed code (which developers do a lot) could update the list of trusted directories. You would need to use bubblewrap or another container solution to prevent random code from touching the list of trusted dirs.

The risks of embedded bare repositories in Git

NYKevin — Thu, 28 Apr 2022 19:30:13 +0000

The risks of embedded bare repositories in Git

kleptog — Thu, 28 Apr 2022 15:44:07 +0000

I think I didn't make myself clear. I wasn't saying that an untrusted Git repository is any safer than an untrusted Word document; it's obviously not.

What I'm saying is that the social and technical mechanisms around how Git repositories are usually managed means that the default level of trust for many Git repositories is much much higher than that of a random Word document. "git clone" can actually verify that what it received is consistent, whereas for a Word document via the email I can't even easily check it's the same thing my neighbour got.

The risks of embedded bare repositories in Git

mathstuf — Thu, 28 Apr 2022 14:47:37 +0000

For prior art along these lines, see myrepos' `.mrtrust` file. https://myrepos.branchable.com/

The risks of embedded bare repositories in Git

MrWim — Thu, 28 Apr 2022 14:19:00 +0000

I believe the suggestion was that you have a *local* list of repositories on your computer that *you* trust. It could be `~/.gittrusted` for example. It might look like:

Projects/linux
Projects/foo
Projects/bar

So then when you run `git status` in Projects/linux the hooks will be run, while if you run it in ~/Downloads/my-dodgy-project no hooks will be run.

The risks of embedded bare repositories in Git

jwarnica — Thu, 28 Apr 2022 14:18:02 +0000

The Word document could be prose instructions on how to format a drive.

The embedded macro might actually do it, automatically.

A git repository might be of, say, `shred`. Or a bunch of .md files instructing you how to use shred. And have a git-whatever that formats your drive.

Its not different, at all.

The risks of embedded bare repositories in Git

MrWim — Thu, 28 Apr 2022 12:20:01 +0000

Exactly, that's what I meant by:

> It might come embedded inside a [...] tarball.

The risks of embedded bare repositories in Git

pbonzini — Thu, 28 Apr 2022 11:34:51 +0000

It is not essential for git repositories. Git repositories need not be code repositories.

The risks of embedded bare repositories in Git

k3ninho — Thu, 28 Apr 2022 11:13:10 +0000

>I feel like the right solution is to have a list of trustworthy repositories configured in your global git config and only allow running commands from them.
Sure, give me the web address of the shell script to update the whitelist and I'll curl-pipe-sudo-bash it right away.

Oops.

K3n.

The risks of embedded bare repositories in Git

Karellen — Thu, 28 Apr 2022 10:25:22 +0000

What? Not all git repos are hosted on github

But also, we're not talking about running `make`. We're talking running something only a bit more complex than `git status`, or even just `cd`ing into a subdirectory for the purposes of running `ls` or `cat readme.md` - except your fancy shell prompt runs some `git` commands to figure out the current branch and whether any changes have been made, in the background, and suddenly you're run attacker-controlled code.

The risks of embedded bare repositories in Git

geert — Thu, 28 Apr 2022 10:04:05 +0000

The git repository might be inside a tarball.

The risks of embedded bare repositories in Git

kleptog — Thu, 28 Apr 2022 09:56:04 +0000

The big difference being that when you look at a Git repository you're looking at something that many other people have already used and has possibly even been scanned by various public scanners and built using buildbots.

This is quite different to Word documents received via the email. If I received a Git repository in the email I wouldn't trust running make in it either.

The risks of embedded bare repositories in Git

MrWim — Thu, 28 Apr 2022 09:27:04 +0000

Or a central list of hooks that are deemed "safe" that could run in any git repo. A malicious git repo might not be embedded inside another one afterall. It might come embedded inside a hg repo or tarball. Just because it's on your filesystem doesn't mean it can be trusted.

Generally speaking actions that feel safe should be made safe. Extracting a tarball, cloning a git repo, `cd`ing to a directory, `cat`ing a file all feel rather pedestrian - and if there are subtle security issues with them it's the software that needs to be fixed.

The risks of embedded bare repositories in Git

taladar — Thu, 28 Apr 2022 08:49:21 +0000

I wouldn't say it is the exact same problem since code as content is essential for source code repositories but not essential for office documents.

The risks of embedded bare repositories in Git

marcH — Thu, 28 Apr 2022 07:48:28 +0000

> There are plenty of other pitfalls when using untrusted Git repositories, but those are already well-known; simply using make or the build script for an untrusted project is a leap of faith unless the repository is carefully scrutinized, for example.

This type of problem happens every single time some "convenience" feature violates the "but I'm just looking" assumption.

Blurring the line between "just looking" and running code is EXACTLY the same problem as https://docs.microsoft.com/en-us/deployoffice/security/in... which Linux people have been using for decades to laugh at Microsoft's approach to security.

We never learn.

The risks of embedded bare repositories in Git

pabs — Thu, 28 Apr 2022 02:46:35 +0000

I feel like the right solution is to have a list of trustworthy repositories configured in your global git config and only allow running commands from them.