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

271–280 of 302 posts

Re: Git security vulnerability announced

#271

Post by WorldMaker »

jcranberry wrote: post #233
ghewgill wrote: post #33

Earlier quoted context omitted.

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?

The concern here is more on `sudo vi /.git/config` than `sudo vi ~/.git/config`. Someone adding a "root" git config that you don't expect/intend to exist.

If you think things are locked down strongly enough with sudo and never install anything that might add root files you don't expect you are most likely safe.

This release also adds an environment variable you can set that makes certain that git has a "ceiling" that it never crosses when checking for .git/config files. The idea being that you'd never want git to look above `/user/*/` for instance, as you'd never expect to have a "machine-wide" git config.

Re: Git security vulnerability announced

#273

Post by Fnoord »

dahfizz wrote: post #239
leni536 wrote: post #191

Earlier quoted context omitted.

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.

There is no the bash completion directory; there is a default one which happens to be system wide and only root writable (as should be the case in a combination of such circumstances).

Fish allows for custom ones in ~/.config/fish and there is zero reason you cannot install custom ones in ~/.bashrc or user writable (on macOS) /usr/local

Re: Git security vulnerability announced

#274

Post by hsbauauvhabzb »

calvinmorrison wrote: post #260
hsbauauvhabzb wrote: post #157

Earlier quoted context omitted.

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

Because linux has failed almost entirely to meet user level threats. Unlike android - which has per app permissions file permissions, linux is not there yet. I know a lot of people are interested in better incapsulation for specific programs, and I know there's a lot of work being done in the area, but it's nowhere near as effective, in my opinion, as android and other systems. linux follows the unix philosophy on th…

You can download a directory containing a script, cd into that repo and less the file. ‘cd foo’ should never trigger arbitrary command execution. Ever.

Containerisation wouldn’t solve this, bash or similar would almost always be fun with near limitless boundaries.

Re: Git security vulnerability announced

#275

Post by hsbauauvhabzb »

seba_dos1 wrote: post #218
hsbauauvhabzb wrote: post #157

Earlier quoted context omitted.

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

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.

Re: Git security vulnerability announced

#276

Post by legalcorrection »

The more I think about it, the more I think this is the right call. The only alternative would be something like falling back to running with no hooks and printing a warning to stderr indicating that there are disabled hooks. Actions that modify that repository should also be disabled in that case. Then there should be a command like 'git hooks trust' that adds the directory to the user's list of trusted folders.

Re: Git security vulnerability announced

#277

Post by reegnz »

hsbauauvhabzb wrote: post #274
calvinmorrison wrote: post #260

Earlier quoted context omitted.

Because linux has failed almost entirely to meet user level threats. Unlike android - which has per app permissions file permissions, linux is not there yet. I know a lot of people are interested in better incapsulation for specific programs, and I know there's a lot of work being done in the area, but it's nowhere near as effective, in my opinion, as android and other systems. linux follows the unix philosophy on th…

You can download a directory containing a script, cd into that repo and less the file. ‘cd foo’ should never trigger arbitrary command execution. Ever. Containerisation wouldn’t solve this, bash or similar would almost always be fun with near limitless boundaries.

I beg to disagree. I like my https://direnv.net/

As long as it's strictly opt-in, it's fine. But it needs to be opt-in to be secure.

Re: Git security vulnerability announced

#278

Post by jra_samba »

sippycup6 wrote: post #135
jra_samba wrote: post #53

is_path_owned_by_current_uid(const char *path) isn't symlink safe given a multi-component path. Symlinks, the poisonous gift that keeps on giving.

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

I'm going to be giving a talk at SambaXP this year (it's virtual, so you only need to register to attend) explaining why IMHO symlinks have utterly broken the POSIX filesystem API, making it impossible for application developers to write secure applications.

https://sambaxp.org/

It's not just a whine, I'm also going to make some suggestions for fixing it :-).

Re: Git security vulnerability announced

#279

Post by jra_samba »

mishafb wrote: post #265
Thorrez wrote: post #140

Earlier quoted context omitted.

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…

Daemons that care about security setuid temporarily before opening a file and then setuid back

That doesn't always fix it. An attacker can race you to make you write something in a place you didn't intend or expect unless the application is incredibly carefully written.

And by "incredibly" I mean beyond the scope of human endeavour :-).

Re: Git security vulnerability announced

#280

Post by jra_samba »

Thorrez wrote: post #137
jra_samba wrote: post #53

is_path_owned_by_current_uid(const char *path) isn't symlink safe given a multi-component path. Symlinks, the poisonous gift that keeps on giving.

Are you saying this was the bug that was fixed, or that is is a new bug, that's not fixed yet?

I'm not sure it's a new bug, just that if you look up that call you'll find if it's used with any path containing a "/", then it can be raced to check somewhere other that the place the original author intended.

That's why symlinks MUST die.

Post reply on HN