Can Git repos be hacked or otherwise manipulated?

Hi,

Let's say you're working with a team of elite hackers, passing a tarball of a Git repo back and forth as you complete your mission. Now let's say one of them has malicious intent. What are the possibilities that he or she can, for instance, hide changes made to a script or binary that does something malicious if executed? Or perhaps maybe there are other such scenarios one should be made aware of?

Thanks and have a nice day!

--Jonathan

Sent with ProtonMail Secure Email.

On Tue, Jan 14, 2020 at 02:48:05PM +0000, 1234dev wrote:

It is absolutely not safe to run Git commands from a tarball of an untrusted repo. There are many ways to execute arbitrary code specified by a config option, and you'd be getting recipients .git/config. Likewise for hooks.

And while we would consider it a bug if you can trigger a memory error by reading a corrupted or malicious on-disk file, that's gotten _way_ less auditing than the code paths which take in objects from a remote. So e.g., I would not be surprised if there are vulnerabilities that could cause out-of-bounds reads of a corrupted .git/index.

-Peff

Hello Jeff and thank you for your response!

To work around this problem, should we instead host this repo on a public service? If so which one would you recommend?

--Jonathan

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, January 14, 2020 10:08 PM, Jeff King <peff@peff.net> wrote:

Hi,

1234dev wrote:

(By the way, this is an area of active work. If you'd like to help, that's welcome. :) See also https://lore.kernel.org/git/20171002234517.GV19555@aiede.mtv.corp.google.com/ and https://lore.kernel.org/git/20191116011125.GG22855@google.com/.)

Cc-ing Josh Steadmon in case he has pointers for how to add some fuzz tests to harden this kind of thing. We definitely want to find any vulnerabilities in this area. (In addition to the case of "ask a friendly sysadmin or member of GitHub tech support to debug my broken repo", this also would affect any users collaborating on a repository on a shared filesystem.)

[...]

If you want to use ordinary file transfer mechanisms to share a repository, you can use "git bundle" to create a copy of your Git repo in a form that is meant to be safe and straightforward to pass around. See "git help bundle" for more details.

Thanks and hope that helps, Jonathan

On Wed, Jan 15, 2020 at 03:18:34AM +0000, 1234dev wrote:

Oops, I forgot to mention the actual solution. :)

Generally it is safe to clone _from_ an untrusted repo, even if it's on a local filesystem. So untarring the repo and running:

  git clone evil.git safe
  cd safe
  git log

should make it OK to run Git commands inside the "safe" directory.

Jonathan Nieder also mentioned using a bundle file, which may be even simpler, as it skips the part where you have to deal with tar. :)

Run:

  git bundle create foo.bundle --all

on the sending side, and then you can just:

  git clone foo.bundle safe

on the receiving side.

-Peff

Jeff King <peff@peff.net> writes:

Then there are those who are even more paranoid to consider that foreign bits hitting their disk platter ^W^W working tree poses risks (e.g. by background thumbnailers crawling there, getting exploited by checked out payload that are not trustworthy).

;-)