Git security vulnerability announced • Hacker News Board

Re: Git security vulnerability announced

#171

Post by alophawen » Wed, Apr 13, 2022, 6:18 AM UTC

nodesocket wrote: post #170

Will Ubuntu update to v2.35.2? My current install is using the elder v2.25.1: ubuntu@vpn1:$ git --version git version 2.25.1 ubuntu@vpn1:$ cat /etc/os-release NAME="Ubuntu" VERSION="20.04.4 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.4 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_…

Since the security bug is windows-specific, you could play it cool.

Re: Git security vulnerability announced

#172

Post by dotancohen » Wed, Apr 13, 2022, 6:22 AM UTC

Here is a quick fix to prevent system-wide exploits, salt to taste:

  $ grep GIT_CEILING_DIRECTORIES ~/.bashrc 
  export GIT_CEILING_DIRECTORIES=$HOME:/var/www

But malicious Git repos could still affect your user profile. You can harden that by putting all git repos in a sandbox, e.g.:

  export GIT_CEILING_DIRECTORIES=$HOME/sandbox

Re: Git security vulnerability announced

#173

Post by ntauthority » Wed, Apr 13, 2022, 6:25 AM UTC

The Windows-specific 'vulnerability' is weird. For one, it's part of the uninstaller, which isn't a common scenario, and secondly... C:\Windows\Temp isn't even writable by unprivileged users by default, it's not even readable by unprivileged users by default (on my relatively fresh Windows 11 system, at least).

Re: Git security vulnerability announced

#174

Post by bawolff » Wed, Apr 13, 2022, 6:36 AM UTC

kgeist wrote: post #153

>This vulnerability affects users working on multi-user machines where a malicious actor could create a .git directory in a shared location above a victim’s current working directory If a malicious actor has access to the filesystem, isn't it a bigger problem? I remember Raymond Chen recounted in his blog that Microsoft usually dismisses vulnerability reports that start with "to use the exploit, you must have access…

I mean, we have multiple user accounts for a reason. Maybe less so on windows but on unix with its mainframe ancestory, local priv escalation definitely feels like a real bug (then again, on linux it would be super weird for / to be writeable by someone not root)

Re: Git security vulnerability announced

#175

Post by rvwaveren » Wed, Apr 13, 2022, 6:37 AM UTC

Question for Mac users. Apple installs git with its command line tools and is currently at version 2.32. Is it wise to install git via Homebrew so that you can upgrade faster? Or are there some benefits from apple-git?

Re: Git security vulnerability announced

#176

Post by antihero » Wed, Apr 13, 2022, 6:39 AM UTC

rvwaveren wrote: post #175

Question for Mac users. Apple installs git with its command line tools and is currently at version 2.32. Is it wise to install git via Homebrew so that you can upgrade faster? Or are there some benefits from apple-git?

I've always used homebrew for git.

Re: Git security vulnerability announced

#177

Post by berkes » Wed, Apr 13, 2022, 6:41 AM UTC

everybodyknows wrote: post #152

edgyquant wrote: post #110

Earlier quoted context omitted.

The default shell on Mac and a lot of Linux distros do this installation, as well as git for windows.

Can you say what Linux distro does this? Seems like very poor taste for a command shell to be assuming one particular SCM.

On Ubuntu, and I presume therefore many debian derivatives and debian itself, `apt get git` will install a file called `/usr/lib/git-core/git-sh-prompt` (dpkg -S /usr/lib/git-core/git-sh-prompt).

This script allows you to see repository status in your prompt. It comes with 5 utility functions that AFAIKS are usable in all common shells:

    __git_ps1_show_upstream ()
    __git_ps1_colorize_gitstring ()
    __git_eread ()
    __git_sequencer_status ()
    __git_ps1 ()

On Ubuntu those aren't installed into bash by default, but you need to add it yourself to your ~/.bashrc (or zsh or whatever, but those aren't the default in Ubuntu). The mechanisms aren't in place for a package to inject itself into your prompt, but it isn't unthinkable (though maybe unwanted) to have that. Similar to how tab-complete for bash is handled:

The `git` package installs a file `/usr/share/bash-completion/completions/git` which is picked up by bash, on Ubuntu, as a pluggable way to extend autocomplete on bash. Many packages do this, on my machine there's 960 files in there (ls -1 /usr/share/bash-completion/completions/ | wc -l).¹ It would be trivial to have a similar mechanism for `bash_rc.d` which allows for a pluggable system to extend and modify your bash. Again, I presume this to be unwanted. I would oppose it.

¹ This is why I was surprised to learn that people like zsh for the reason that it offers tab-completion: I always presumed bash did that out of the box for any installed package already. Turns out it is Ubuntu (or better: Debian) doing this for me.

Re: Git security vulnerability announced

#178

Post by tommiegannert » Wed, Apr 13, 2022, 6:52 AM UTC

> Run the uninstaller under an administrator account rather than as the SYSTEM user

How do I run something as SYSTEM? I thought I always ran as "me" or Administrator. Is this only likely to happen for deployment automation tools?

> Avoid running the uninstaller until after upgrading

Don't leave us with this cliff-hanger... Does the upgrade installer run the uninstaller first? (The original report doesn't have this bullet point.)

Re: Git security vulnerability announced

#179

Post by fragmede » Wed, Apr 13, 2022, 6:58 AM UTC

everybodyknows wrote: post #152

edgyquant wrote: post #110

Earlier quoted context omitted.

The default shell on Mac and a lot of Linux distros do this installation, as well as git for windows.

Can you say what Linux distro does this? Seems like very poor taste for a command shell to be assuming one particular SCM.

The shell doesn't assume a particular one, but if it's in a directory where a supported one is present, then it enables those extras.

Re: Git security vulnerability announced

#180

Post by Groxx » Wed, Apr 13, 2022, 7:02 AM UTC

hda2 wrote: post #84

dhzhzjsbevs wrote: post #74

Earlier quoted context omitted.

Tbh I thought this was pretty obvious. Git hooks have always been sketchy as hell. Can't stand the Mac specific shit my co-workers keep dumping in there.

Wait, I thought git hooks aren't pulled from remote. Wouldn't untrusted git hooks mean that git verify-* are useless since you're already running untrusted code?

Just to react to:

>Wait, I thought git hooks aren't pulled from remote.

You are correct. They are not. Other tools may auto-install them (I hate it), but git does not ever.