5 ms·
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 an
by xyzzy_plugh 3y ago
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?
- upon_drumhead 3y agoIt 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.
- TeMPOraL 3y agoIf 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?
- upon_drumhead 3y agoSure, 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?
- TeMPOraL 3y agoExcluding 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.
- upon_drumhead 3y agoThis 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.
- gruez 3y agoYou put the directory somewhere (eg. usb drive) and hope someone enters the directory and executes a git command.
- naruhodo 3y agoTo 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.
- jabbany 3y agoThat doesn't work if . is at the end of $PATH though? Since the real ones would take precedence due to how executable searching works...?
- deleted 3y ago[deleted]
- locustous 3y agoYou never type sl on accident?
- jwilk 3y agoYou should install https://github.com/mtoyoda/sl https://github.com/mtoyoda/sl as a hardening measure.
- jabbany 3y agoSurprisingly, 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...
- 3y ago
- armada651 3y agoThere 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.
- meatmanek 3y agoI 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.
- xyzzy_plugh 3y agoIt'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.
- thfuran 3y agoWould you ever run a kernel written by someone else?
- shortcake27 3y ago> 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.
- xyzzy_plugh 3y ago
- chlorion 3y agoI 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.
- abathur 3y agoIf 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 https://github.com/abathur/LittleGaryGitles :)
- tomlx 3y agogit 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.