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

241–250 of 302 posts

Re: Git security vulnerability announced

#241

Post by dgellow »

sharken wrote: post #238
dgellow wrote: post #227

Earlier quoted context omitted.

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...

Yes, that's always good to check but given the size of the repository (the number of directory and files is just massive!) it can be really annoying to navigate. Often faster to just run the winget CLI somewhere.

winget.run should add a link to the manifest directory, that would be useful.

Re: Git security vulnerability announced

#242

Post by dcow »

What is a scenario where you’d be running git in the subdirectory of one owned by a malicious user? Unless a machine is badly configured and administrated, when would one user ever have authority of ownership over /home or /opt or /? And if they have sudo privileges well then they have the authority to do whatever they want. Is this only an issue because of some Windows idiom? I’m somewhat dubious.

Re: Git security vulnerability announced

#243

Post by dcow »

dcow wrote: post #242

What is a scenario where you’d be running git in the subdirectory of one owned by a malicious user? Unless a machine is badly configured and administrated, when would one user ever have authority of ownership over /home or /opt or /? And if they have sudo privileges well then they have the authority to do whatever they want. Is this only an issue because of some Windows idiom? I’m somewhat dubious.

I can think of shell prompt plus exploring /tmp, but the fix for this “vuln” doesn't address that issue and seems to be more of a problem with a prompt that automatically runs git in every directory.

Re: Git security vulnerability announced

#244

Post by db48x »

slavik81 wrote: post #168
db48x wrote: post #145

Earlier quoted context omitted.

It’s possible, but I doubt it. 99% of people use a personal computer with just a single user account on it (or they use a phone with no git client, so let’s just think about git users for now). With only one real user account on the machine they are not very likely to encounter this security measure.

Just about anybody that uses docker and mounts a volume is going to have multiple users accessing their files, even if there's only one real user.

Not exactly. Inside the docker container, the files you have bind–mounted will be owned by the same user who runs the git binary. You’ll never even notice the security check.

Re: Git security vulnerability announced

#245

Post by berkes »

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?

Anything installed through `apt` could be an attack vector, but that is silly, really.

If we start treating "apt get will install software that can change my system" as a security issue, we should stop using all electronic devises right now.

And yea: I know, we should have sandboxing, isolation, chroot and whatnot. And we are heading there. Yet in 2022, the vast majority of computers, servers and such are installed using package managers which install packages that have access to all the system. If you count mobile devises amongst "computers" then I guess a majority (Android) does have sandboxing in packages, which solves this particular issue.

Re: Git security vulnerability announced

#246

Post by zarzavat »

dataflow wrote: post #214
zarzavat wrote: post #206

Earlier quoted context omitted.

> `git branch` can cause git to run programs specified in the git repository’s config file This is the real vulnerability. Why is git branch running random external programs?

I think `git branch` here wasn't intended to be taken literally. If anything, you'd use a plumbing command to get the branch, not a porcelain command. I think they just meant that some commands that might be run might in turn run programs specified in the config file (either now or in the future).

So what's a good example of a git command that you might reasonably run as part of your $PS1 that runs an external program? It's not like people have git push or git commit in their $PS1.

Re: Git security vulnerability announced

#247

Post by sippycup6 »

Thorrez wrote: post #140
sippycup6 wrote: post #135

Earlier quoted context omitted.

I do not understand why symbolic links are "poisonous"? Can I get some context?

I think it's just that they're tricky when it comes to ownership. People who write code that depends on some type of file or directory ownership for security often don't think about the ways symlinks can be used to bypass their security model. You can sort of think of a symlink as having 2 owners: the user that owns the symlink itself, and the user who owns the file pointed to by the symlink. One of those owners migh…

Thank you!

Re: Git security vulnerability announced

#248

Post by faho »

zarzavat wrote: post #246
dataflow wrote: post #214

Earlier quoted context omitted.

I think `git branch` here wasn't intended to be taken literally. If anything, you'd use a plumbing command to get the branch, not a porcelain command. I think they just meant that some commands that might be run might in turn run programs specified in the config file (either now or in the future).

So what's a good example of a git command that you might reasonably run as part of your $PS1 that runs an external program? It's not like people have git push or git commit in their $PS1.

`git status`. This essentially has a "prompt" mode with `--porcelain`, which can even print branch and stash state, so it features all of the information for a prompt. Prompts have been mentioned in adding the v2 porcelain format[0]

It will call the fsmonitor hook configured in core.fsmonitor - this is supposed to speed up figuring out which files to check.

The official git-prompt.sh calls `git diff`, which will do the same[1].

[0]: https://github.com/git/git/commit/00d27937bf0348e7da615f04b6... [1]: https://github.com/git/git/blob/11cfe552610386954886543f5de8...

Re: Git security vulnerability announced

#249

Post by riedel »

ntauthority wrote: post #173

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).

Both vulnerabilities are reported as git for windows vulnerabilities, aren't they?

I do not quite understand what is the 'correct' behaviour considering the parent directory thing. The concrete problem seems rather than that there is no -safe switch to use in prompts, etc.

Re: Git security vulnerability announced

#250

Post by bgro »

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…

On Windows, it's amazing how confusing permissions are.

Seemingly everything needs admin permission to run. If the program can't get admin permission from you, it can probably just ignore that and do stuff like install to %appdata%. Chrome does this, for example, apparently to fix a bug where work place administrators didn't want their users installing programs with administrative permission. Chrome or anyone else can just fix that bug by using a windows-level exploit feature.

You can never really be sure what's happening when you install a mystery .exe file until you just install it. Sometimes you can exploit things with hack tools to take a peak inside I guess, but that doesn't seem to work very well most of the time in my opinion.

This horrible permission management system is why a lot of games only work on Windows. If they want to make sure players aren't cheating, the way they do that is by installing root kit level malware. We call that anticheat. It's amazing how that's a standard procedure that can just work on a computer. It also has a history of entitled devs screwing it up big time (Sony) or even doing it very poorly which causes huge performance drops like we see in most modern recent games.

Modern Warfare 2019 crashed and corrupted my OS which was on an encrypted drive. This lead to a 100% data loss for me. I'm 90% sure the root reason to this was the root kit anti cheat bugging out on top of awful coding / performance and bugginess in general we see everywhere in that game.

I don't understand how Windows still works off of you receiving packages at your door and the only way to verify its safety is guess that the timing of your package syncs up with what you ordered and the packaging looks like what you got, and to have hope that the place that packed it wasn't malicious. While nearly all programs do include bombs (unwanted tracking / malware / bad design), usually they're just fairly harmless firecrackers. The only way to open your package up is to put it on the flammable gas pipe in the middle of the house (a left over design from earlier versions of the house) which has a very heavy flaming chainsaw attached to a 1 inch chain.

Post reply on HN