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'"`
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.
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.
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...
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.
> 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.
> 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.
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.
33 comments
[ 2.9 ms ] story [ 78.7 ms ] threadI don't see any actual exploit here.
There is an issue around embedded bare repos in archives, however, that is not the given exploit in the linked repo at all.
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...
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.
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.
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.
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.
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.
I made a little test repo for this a while back https://github.com/abathur/LittleGaryGitles :)
> not disabled by default yet
You're saying there's a way to "disable" this behavior?
https://github.com/git/git/commit/8d1a7448206e11cd