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

231–240 of 302 posts

Re: Git security vulnerability announced

#231

Post by teh_klev »

tommiegannert wrote: post #178

> 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 bu…

This is likely aimed at remote management tools that can perform (amongst many other tasks) remote installs of apps across fleets of machines. On Windows you'll likely find these run as SYSTEM.

Re: Git security vulnerability announced

#233

Post by jcranberry »

ghewgill wrote: post #33
eminence32 wrote: post #3

> Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. I'm curious about this -- what's the attack vector here?

The key is the "Git-enabled `PS1`". PS1 is an environment variable recognised by common shell programs (such as bash) that configures the shell prompt. Git often installs its own glue into the prompt that ends up running a Git executable to discover such things as the current branch name and how many changed files. The vulnerability is that it's possible to add malicious things to .git/config that the git executable…

Damn. So the script I use to put the branch name in my prompt is bad? Could I solve this by making .git/config readonly for non sudo?

Re: Git security vulnerability announced

#234

Post by bin_bash »

saagarjha wrote: post #51
bin_bash wrote: post #18

Doesn’t homebrew typically get setup as a different user? How’s that going to work?

Homebrew typically changes the ownership of the directory to the current account.

On install or execution? What happens if there is more than 1 user on the box?

Re: Git security vulnerability announced

#235

Post by _wldu »

teh_klev wrote: post #231
tommiegannert wrote: post #178

> 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 bu…

This is likely aimed at remote management tools that can perform (amongst many other tasks) remote installs of apps across fleets of machines. On Windows you'll likely find these run as SYSTEM.

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.

Re: Git security vulnerability announced

#236

Post by donkeyd »

_wldu wrote: post #235
teh_klev wrote: post #231

Earlier quoted context omitted.

This is likely aimed at remote management tools that can perform (amongst many other tasks) remote installs of apps across fleets of machines. On Windows you'll likely find these run as SYSTEM.

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.

> If corporate systems were stand-alone/isolated, we probably would not have this problem to the extent that we do.

Well.. Yeah, but also... This is what we used to have and have been moving away from. We used to have on premise and then moved to SaaS. I'm pretty sure we all realized that had some security consequences, right?

Re: Git security vulnerability announced

#237

Post by _wldu »

donkeyd wrote: post #236
_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.

> If corporate systems were stand-alone/isolated, we probably would not have this problem to the extent that we do. Well.. Yeah, but also... This is what we used to have and have been moving away from. We used to have on premise and then moved to SaaS. I'm pretty sure we all realized that had some security consequences, right?

Compliance and audit driven organizations are more likely to do these things. They want consistency and control across the org. What they fail to realize is how that same consistency and low level control can be used against them. And, more importantly, the scale of the abuse will be as efficient as the scale of management.

It's sort of like building an encryption backdoor (only for law enforcement) and then to be shocked and surprised when criminals use it against you. Security technologists who know better are not consulted and/or their advice to isolate and diversify is not taken.

Re: Git security vulnerability announced

#238

Post by sharken »

dgellow wrote: post #227
sharken wrote: post #220

Interestingly if you're on Windows, then Chocolatey is the better package manager to use. Microsoft's own package manager Winget only has v2.34.1 right now. Chocolatey https://community.chocolatey.org/packages/git#versionhistory Winget https://winget.run/pkg/Git/Git

winget.run isn't up to date, I do see 2.35.2 by running the winget CLI (note that `winget upgrade git` will run the uninstaller first). $ winget show git.git Found Git [Git.Git] Version: 2.35.2 Publisher: The Git Development Community Publisher Url: https://gitforwindows.org Publisher Support Url: https://github.com/git-for-windows/git/issues Author: Johannes Schindelin Moniker: git Description: Git for Windows focus…

Yes, you're quite right.

For future reference the GitHub manifest page seems to be the better choice:

https://github.com/microsoft/winget-pkgs/tree/master/manifes...

Re: Git security vulnerability announced

#239

Post by dahfizz »

leni536 wrote: post #191
berkes wrote: post #177

Earlier quoted context omitted.

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_s…

This feels like tab completion is a more serious attack vector then?

You need to be root to add a file to the basl completions directory, so not really.

Re: Git security vulnerability announced

#240

Post by avgcorrection »

rswail wrote: post #199
alkonaut wrote: post #162

Don’t make tools use processes for “plug-in behavior”. Do one thing and do it well doesn’t really appeal to me to begin with but “let the first thing do the next thing on its own” is definitely a bastardization of that idea as well. Git has that Unix disease where the go to method of getting anything user configurable done with one program is launching another program . I’d much rather use tools that use huge convolu…

> I’d much rather use tools that use huge convoluted script languages or good plug-in apis than tools that duct tape together with exit codes. The Unix "plug-in API" is pipes and exec and "everything is a file (descriptor)". A "good plug-in API" that doesn't support anything written outside the "huge convoluted script language" is not a plug-in API, it's an internal API of the "convoluted script language". "Do one th…

> "Do one thing and do it well doesn’t really appeal to me to begin with" means that you don't like the Unix model in general.

Yes? Some people don’t like it.

Post reply on HN