The risks of embedded bare repositories in Git

Posted Apr 28, 2022 7:48 UTC (Thu) by marcH (subscriber, #57642)
Parent article: The risks of embedded bare repositories in Git

> 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

Posted Apr 28, 2022 8:49 UTC (Thu) by taladar (subscriber, #68407) [Link] (2 responses)

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

Posted Apr 28, 2022 11:34 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

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

The risks of embedded bare repositories in Git

Posted Apr 28, 2022 14:18 UTC (Thu) by jwarnica (subscriber, #27492) [Link]

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

Posted Apr 28, 2022 9:56 UTC (Thu) by kleptog (subscriber, #1183) [Link] (3 responses)

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

Posted Apr 28, 2022 10:25 UTC (Thu) by Karellen (subscriber, #67644) [Link] (2 responses)

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

Posted Apr 28, 2022 15:44 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

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

Posted Apr 29, 2022 5:45 UTC (Fri) by marcH (subscriber, #57642) [Link]

> "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

Posted Apr 28, 2022 19:30 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

The risks of embedded bare repositories in Git

Posted Apr 29, 2022 6:09 UTC (Fri) by marcH (subscriber, #57642) [Link]

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.