Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git security vulnerability announced

github.blog

Post reply on HN
Print view View original

281–290 of 302 posts

Re: Git security vulnerability announced

#281

Post by seba_dos1 »

hsbauauvhabzb wrote: post #275
seba_dos1 wrote: post #218

Earlier quoted context omitted.

No? Why would someone zip me a git repo? You can clone/push/pull directly between machines.

You’ve never unzipped a repo? That’s something I regularly do - clients can’t get me access to their scm, and it’s not worth the effort.

I don't think I ever did. I usually have an opposite problem and sometimes accidentally zip/tar a repo when it shouldn't be included (at least there's `--exclude-vcs`).

In any case, this doesn't sound like a good idea at all, as git hooks exist.

Re: Git security vulnerability announced

#282

Post by rst »

leni536 wrote: post #194
zeroimpl wrote: post #7

Earlier quoted context omitted.

Yes I’ve run “git status”, “git log” and “git diff” on other people’s repo’s plenty of times to help debug things, so it’d be sad to see this stop working. It seems some basic readonly operations should still be supported.

Maybe the pragmatic way from now on is to clone the repo, even if it's on the local machine.

Cloning will miss any uncommitted local edits (which you might want to have run "git status" to detect)...

Re: Git security vulnerability announced

#283

Post by seba_dos1 »

nybble41 wrote: post #268
seba_dos1 wrote: post #218

Earlier quoted context omitted.

No? Why would someone zip me a git repo? You can clone/push/pull directly between machines.

The source machine may not be set up as a server, or you may not have an account there. Sending a .zip file could be simpler than pushing the repo to a third system the receiver does have access to.

Sure, mailing binaries can also be the right thing sometimes, but just as with git repos, you definitely shouldn't be taking them from untrusted sources.

(and I bet that many people don't even realize how easy using `git push` to mirror a repo actually is, since git is very commonly used in a centralized fashion)

Re: Git security vulnerability announced

#284

Post by gnubison »

wongarsu wrote: post #258
_wldu wrote: post #235

Earlier quoted context omitted.

As an aside, those same low-level remote management tools are used by cyber actors (criminals and governments) to compromise entire organizations with ransomware and other malware. That's the real reason ransomware is such an issue today. If corporate systems were stand-alone/isolated, we probably would not have this problem to the extent that we do.

In a company with 10000 computers you don't want to have an IT person walk to each of them to roll out new software or install an update. Sure, attackers would have a harder time, but IT departments would also have to be orders of magnitude larger

Humor me for a second: why not have them install the software themselves?

Re: Git security vulnerability announced

#285

Post by jyrkesh »

Sharparam wrote: post #217
jyrkesh wrote: post #196

Earlier quoted context omitted.

There's a lot of different ways to install Git on a lot of different OSes, and some of them put helper shell scripts down by default.

That isn't Git installing things though, that is third-party Git distributions bundling things along with Git.

I'm aware, which is why I phrased it like I did. A lot of folks don't know or understand the distinction when they're installing Git (or installing something else that happens to bring Git with it).

The overarching point is that the shell itself is not installing anything at shell runtime. E.g. it's the Git Bash installer, not opening `bash`.

Re: Git security vulnerability announced

#286

Post by hsbauauvhabzb »

seba_dos1 wrote: post #281
hsbauauvhabzb wrote: post #275

Earlier quoted context omitted.

You’ve never unzipped a repo? That’s something I regularly do - clients can’t get me access to their scm, and it’s not worth the effort.

I don't think I ever did. I usually have an opposite problem and sometimes accidentally zip/tar a repo when it shouldn't be included (at least there's `--exclude-vcs`). In any case, this doesn't sound like a good idea at all, as git hooks exist.

You’re right but also I’m mad that you’re right. I need to check what hook functions there are, but I knew about hooks and still overlooked them, which to me thinks that they’re non obvious. Maybe git should prompt you on first run, which is either whitelisted on your host or signed by your git keys or similar

Re: Git security vulnerability announced

#287

Post by kazinator »

If you can create a .git directory above a victim's home directory, then you're root.

Or else, if you're not root, you're in messed up system. Whoever is root should go read some 40-year-old book on Unix about how it's supposed to be laid out.

This is not a genuine security vulnerability; though of course, it's good to fix it.

Here is how I would fix it. Forget about permissions and ownership entirely. There is a weaker, more powerful condition we can check. Ready?

Git should terminate if it is executed from a subdirectory of a git repo that contains no tracked files according to the first .git/ directory that it finds while ascending the file system.

If you're in a directory that contains no files that are tracked by the closest .git/ that can be found by walking up the stairs, then that directory has no relationship to that repo. Git should diagnose that and bail out. (It could allow files in that directory to be added to the index, but only with -f option to force it.)

If git finds a .git/ dir, and that repo's index shows that at least one item in, or below, your working directory is in that repo's index, it should go ahead and work with it, regardless of ownership.

Re: Git security vulnerability announced

#288

Post by kazinator »

hsbauauvhabzb wrote: post #157
calvinmorrison wrote: post #56

Earlier quoted context omitted.

in other news, access to a users account gives them access to a users account

This is really dismissive. Unexpected execution is not a users fault, and can happen for a variety of reasons (you telling me you’ve never unzipped a full git path someone sent you?)

Hi!

I can cheerfully confirm that I've absolutely never:

- received a git repo as an archive from someone, and then

- changed to root with "su" before unpacking it somewhere, such that

- the chosen location was above the home directory layer of a multi-user system.

- in such a way that one of the directories of the /path/to/home path has a .git/ subdirectory as a direct child, and not as an unpacked-tarball/.git grandchild which would not be accidentally found by git. I.e. that one of these directories exists, which might be found by someone running "git" in their home:

  /.git
  /path/.git
  /path/to/.git
  /path/to/home/.git
rather than the more likely:

  /foo-project-123/.git
  /path/foo-project-123/.git
  /path/to/foo-project-123/.git
  /path/to/home/foo-project-123/.git
which will not be found by someone running "git" in their home directory.

If I did such a thing, I'd care more about what happens when I happen to step on one of the malicious hooks in that repo as root, and less about what happens if users step on it.

Re: Git security vulnerability announced

#289

Post by silverwind »

This "fix" breaks deployments where files are checked out as the root user and then chowned to an app-specific user. Any subsequent action as the root user will fail.

It seems they forgot to provide an exception for the root user or a way to disable this "feature" on a global level, instead of per-directory.

Re: Git security vulnerability announced

#290

Post by xyse53 »

kazinator wrote: post #287

If you can create a .git directory above a victim's home directory, then you're root. Or else, if you're not root, you're in messed up system. Whoever is root should go read some 40-year-old book on Unix about how it's supposed to be laid out. This is not a genuine security vulnerability; though of course, it's good to fix it. Here is how I would fix it. Forget about permissions and ownership entirely. There is a wea…

The issue isn't specific to home directories. /tmp, for example.

Your suggestion may protect against accidents, but doesn't seem to me to do anything for deliberately malicious behavior.

Post reply on HN