Git security vulnerability announced

Git security vulnerability announced(github.blog)

549 points by delsarto 4 years ago | 273 comments

dang 4 years ago |

All: the originally submitted URL was https://github.com/git/git/commit/8959555cee7ec045958f9b6dd6.... Readers are divided about which link is better, which probably means you should read both to understand the thread.

tommiegannert 4 years ago |

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

bgro 4 years ago | |

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.

wongarsu 4 years ago | | |

I don't think Windows permissions are that complicated, and certainly covers the problem space of actual companies better than unix. The problem is that the original design was somehow opinionated and didn't match what home users were doing.

To oversimplify:

- there's the kernel, which can do anything

- there SYSTEM, which is is kind of like "root" in unix, but only used by services (you can't log in as SYSTEM)

- there are user accounts with Administrator rights, which can do "anything" (can be slightly limited by the above two)

- there are user accounts without Admin rights, kind of like normal user accounts in unix.

There are also more specialized Admin privileges, rights for everything are actually controlled by Access Control Lists and tokens, and your accounts and their rights might exist locally or domain-wide (centrally managed on some server), but unless you're a company you don't care about that.

The problems you describe are mostly due to three things:

- Home users got into the habit of only using one user account with admin credentials. It's convenient, but effectively running everything as root. That's why we now have UAC (that prompt when you try to do admin stuff with an Admin account), and the transition to UAC was pretty rough.

- Some software actually wants some protection from the user (antivirus has to protect itself from processes started by the user, anti-cheat has to protect itself from the user, etc.) Because home users use Admin accounts for everything, the only escape upwards in the hierarchy is into the SYSTEM account or into the kernel, with the latter being much more secure, but much worse if you do it wrong

- In large corporations obviously only IT has Admin accounts. That's how the system is supposed to work. People still want to install software without calling IT, so some software installs in the user folder (in %APPDATA%). That's no different from installing in ~/bin in unix.

The last two points are equally bad in linux, you just don't come across them as often because nobody does anti-cheat and runtime anti-virus on linux, and most linux systems are ultimately used and administrated by the same person

Jenk 4 years ago | | |

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

This is exactly what the "Signed by Windows" MSI feature is for. Of course it is also a cash-in with a prohibitively lengthy and expensive process for publishers though (IMHO)

teh_klev 4 years ago | |

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.

_wldu 4 years ago | | |

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.

beermonster 4 years ago | |

You can run it using something like psexec sysinternals tool or Process Hacker. But it’s not something someone would likely do by accident and it’s a bit orchestrated/non-obvious.

entrep 4 years ago | | |

If the installer is deployed with SCCM or Intune it's very likely being executed in system context.

dgellow 4 years ago | |

Yeah, that's something that should be clarified. I'm almost certain `winget upgrade git` will run the uninstaller first...

WorldMaker 4 years ago | | |

It shouldn't. So much of the (ugly, hideous) complexity of the MSI engine is specifically there because of presumptions that installers don't uninstall previous versions but generally upgrade in place. winget should just defer to MSI norms here for Git for Windows as Git for Windows is a mostly normal MSI-based installer still.

smileybarry 4 years ago | |

IIRC startup scripts and such are run under SYSTEM. Some orgs have incredibly awful startup scripts that take minutes, it's not impossible that one of them has a script of "git-uninstall.exe && git-install.exe" to "ensure" git is installed.

AlbertoAsw10 4 years ago | |

dgellow 4 years ago | | |

What does that mean?

ntauthority 4 years ago |

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

logbiscuitswave 4 years ago | |

The thing about c:\windows\temp is you can’t modify another user’s files but you can create your own.

It’s actually a _really_ common vector to exploit poorly written installers by dropping your own file (like a malicious dll or exe) into that directory as a low rights user in the hope that the high rights installer process will then load that code. That’s presumably what’s happening in this case.

nicce 4 years ago | |

At least on Windows 10 and multi-user installations everyone can access C:\Windows\Temp

How do you define unprivileged?

jve 4 years ago | | |

On my Windows 10 machine, I can't access C:\Windows\Temp as unprivileged user. It makes me press Continue, which will invoke admin rights to set privileges for that folder.

riedel 4 years ago | |

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.

eminence32 4 years ago |

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

krick 4 years ago |

This is bullshit. I mean, ok, you are concerned about somebody using git-enabled PS1. Guess what, not everyone is using git-enabled PS1. Unbelievable, right? I would even mock the fact that you are trying to protect users from the behavior they pretty much explicitly allowed, but this is pointless. Truth is, developers are doing something that can fuck up their system daily. Let's forget about wget | bash and copying completely untrusted git repositories (and it's pretty much guaranteed that everybody using git-enabled PS1 won't shy away from that). Just using composer or npm is enough to compromise your system. "Fixing" this is like introducing DRM: you cannot do arbitrary unsafe stuff without doing arbitrary unsafe stuff. And there simply are people out there, who want to do arbitrary unsafe stuff.

But ok, let's not take it as an excuse. How about fixing git, then? I mean, actually fixing: making it possible to disable hooks & core.fsmonitor & whatever else they fucked up? No, right, let's just disable git instead.

And if I'm reading this correctly, I'm not even allowed to say "I don't care" — I must explicitly mark every shared directory as trusted (I mean, safe.directory = '/' won't work unless / is actually a git directory, right?).

I guess I just shouldn't update git until this "fix" is fixed. Or until git is forked.

jra_samba 4 years ago |

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.

Thorrez 4 years ago | |

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

jra_samba 4 years ago | | |

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.

sippycup6 4 years ago | |

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

Thorrez 4 years ago | | |

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 might be an attacker, so every time you interact with a file, you have to think "this file might be half-owned by an attacker, and half-owned by a victim".

jra_samba 4 years ago | | |

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

zionic 4 years ago | |

I’d love an OS that didn’t even support those.

haolez 4 years ago | | |

I think that was one of Plan9's selling points.

userbinator 4 years ago | | |

DOS? Non-NT Windows?

rst 4 years ago |

Well, depending on exactly how much this blocks, this could get pretty awkward -- typing 'git log' in a repo owned by someone else can be awfully handy, even if file system permissions block changing it at all, and putting together a list of all places you might want to do this in advance could get pretty awkward. (Not running hooks, or allowing operations that would trigger them, from non-owned directories would preserve some of this usage, and still at least mitigate the dangerous cases somewhat.)

It's also not entirely clear to me what this does to site-wide shared remotes, though I suppose if they can be listed in system config, it's at least not a per-user hassle.

thelopa 4 years ago | |

I do this quite often, actually. I have my NixOS system config officially stored in /etc/nixos/ and owned by root. I have a clone that lives in my home directory for WIP changes, but builds always run out of the official copy. Sometimes it’s convenient to quickly run some read-only commands directly in the official copy

db48x 4 years ago | | |

Ultimately you own that repository so just set it as safe in your config. Similarly if you are looking at a coworker’s repository then you can probably trust them. It’s only when you start sharing a computer with people that you don’t really know that you have a problem.

zeroimpl 4 years ago | |

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.

rvwaveren 4 years ago |

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?

antihero 4 years ago | |

I've always used homebrew for git.

lprd 4 years ago | |

No benefits that I’m aware of. I prefer having the latest greatest, so I’ve always used the homebrew tap.

rswail 4 years ago | |

I use the macports version. As far as I am aware, there are no advantages to using the Apple version.

antihero 4 years ago | | |

Out of interest any reason to select macports over brew? Since I started using mac brew seemed like the done thing

1123581321 4 years ago | |

I’m not aware of any benefit to using the system git, as a user.

mlindner 4 years ago |

Did the link get changed? I can't find anything of what anyone is talking about in this github.blog post.

wolfgang42 4 years ago | |

Yeah, dang updated the link: https://news.ycombinator.com/item?id=31010550 (it was previously https://github.com/git/git/commit/8959555cee7ec045958f9b6dd6...)

ineptech 4 years ago | | |

Thank you, I was confused. I'm very curious if the people complaining about this change as being too paternalistic still feel that way after reading the full disclosure link.

kazinator 4 years ago |

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.

saagarjha 4 years ago |

I shouldn’t ask too much of an open source project, etc. etc., but this sounds like something Git should fix themselves rather than just outright disabling. “I want to go into a directory and run git log” is kind of a simple thing to want to do and to not be able to do that sucks. It’s easy to pontificate on this forum but having a “safe” git that doesn’t automatically run hooks or whatever seems like the way forward here, and useful outside of even just a “I want my PS1 to work”.

dcow 4 years ago |

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.

dcow 4 years ago | |

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.

dotancohen 4 years ago |

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

silverwind 4 years ago |

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.

kgeist 4 years ago |

>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 to the machine". As he likes to say, "the gates are already open". If you already have access to the machine and can create files outside of your home directory, what stops you from causing even greater havoc?

keyanp 4 years ago | |

In the case of a multi-user machine, e.g. in a library, you expect there to be low privilege users with filesystem access. This bug introduces a way for them to do privilege escalation and potentially run code as root, which you did not intend.

Generally, you still want these additional protections even if you don't expect others to have access to a machine. Can't say if one or the other is a bigger problem. I think they are all components of having a secure system.

bawolff 4 years ago | |

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)

Dylan16807 4 years ago | |

> If you already have access to the machine and can create files outside of your home directory, what stops you from causing even greater havoc?

These systems don't let you put files in other people's directories. You can only create things in a specific spot, and if that thing is a directory then you and only you can put files inside it. Sometimes the only thing you can make in that spot is a directory.

(Other users can access those files if you explicitly add them to the permissions, of course.)

hsbauauvhabzb 4 years ago | |

Network shares on corporate networks come to mind, they don’t need to be git repositories either (and presumably chowning all files to 1000:1000 would hit the large majority of Linux users even with this fix)

nodesocket 4 years ago |

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_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

hyperman1 4 years ago | |

Same for debian 11 bullseye, which is today on git 2.30.2 . I'm not too worried, if someone besides me manages to create a /home/.git, then I'm already owned. But it's a bit surprising.

m4lvin 4 years ago | | |

I assume the patch will be backported and there will be a point release .30.? including it, but bullseye will probably sticks with 2.30.

However, you can use bullseye-backports to get 2.34.1 if you want: See https://packages.debian.org/git

Edit: None of the debian versions have the patch yet: https://security-tracker.debian.org/tracker/CVE-2022-24765

McP 4 years ago | |

A fix has already been released: https://ubuntu.com/security/CVE-2022-24765

nodesocket 4 years ago | | |

So does that mean git v2.25.1 is patched? That’s what my Ubuntu 20.04 is running now.

alophawen 4 years ago | |

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

faho 4 years ago | | |

It's not windows-specific. It's just that the git-for-windows people are more receptive to the idea of this being a security bug.

The behavior is cross-platform.

McP 4 years ago | | |

CVE-2022-24765 is not Windows-specific.

hda2 4 years ago |

Was this change discussed publicly prior to merge?

I think this is a big mistake. Build environments use separate users for security purposes. It's insane to decrease security for everyone by requiring a single user to do everything because some of your users want to have fancy terminal prompts.

At the very least, let users configure this at a per-user level.

tylersmith 4 years ago | |

Fixing RCE vulnerabilities isn't something that should be debated about publicly.

hda2 4 years ago | | |

Nitpick: This isn't an RCE. An attacker would need 1) write access to a /local/ directory that the target will navigate to in his shell, and 2) convince the target to execute arbitrary git hooks in every directory (or parent directory) he visits by adding git to his shell's PS prompt.

Besides, now that this security issue is patched, git devs should seek a proper solution to that doesn't break git and decrease security for everyone else.

wonnage 4 years ago | | |

This isn't an RCE, you need to have control over the parent directory first which usually implies some sort of admin privileges already

saagarjha 4 years ago | | |

This is just one way to fix the vulnerability. There are others, with different tradeoffs.

Matheus28 4 years ago |

Shouldn't `safe_directory_cb` be checking the key parameter? It's ignoring it completely. So any unrelated config that has a directory in its value will also mark it as safe. Unless I'm misunderstanding something?

cmeacham98 4 years ago | |

Maybe it's intended? If you specify a directory for something in your git config it sounds reasonable to assume you trust it.

That said, if it is intended, I'm surprised there isn't a comment mentioning that because it certainly looks like a bug.

Matheus28 4 years ago | | |

I considered that too... but not sure. There's also the fact that it'll reset is_safe to 0 on each config line... which is likely not intended. Seems like a rushed patch. Unless I'm seriously misunderstanding how that read_very_early_config function works (it calls the cb for each key-value pair in the config, I'm assuming).

waynecochran 4 years ago | |

It's using it here on line 1042?

     git_config_pathname(&interpolated, key, value)

Matheus28 4 years ago | | |

Yes but that's a general use function, it won't check for safe.directory inside of it

db48x 4 years ago | |

That does seem like a mistake, upon a cursory examination.

Matheus28 4 years ago | | |

I submitted a PR on github https://github.com/git/git/pull/1235. Supposedly there's a bot who will send an email, but I don't have permissions to use it... mhm...

legalcorrection 4 years ago |

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.

zmmmmm 4 years ago |

And .... there go probably tens of thousands of person-hours of human effort due to fixing this across huge numbers of systems.

It's fascinating to me that we have people out there just casually making these kind of decisions with enormous cost implications with barely any thought to the downstream implications. Then meanwhile, we need approval in our org to claim a $30 taxi voucher as an expense.

hyperman1 4 years ago | |

Some nature documentary explained why ants easily fall prey to anteaters. Why don't they evolve more defenses? It turns out the risk of anteaters is so low, that additional defenses are not worth the cost of e.g. slower foraging. Better count on the law of numbers, spread the risk over all ants, and get on with your life until you get unlucky.

I think the same thing is going on with non-security reviewed software. The additional cost of thoroughly reviewing everything is so high and software is generally so good, that we can rely on word of mouth and past project behavior to make guesses that make economical sense.

So git has proven a good enough steward in the past, and society swallows the cost of this update. Organizations trusting humans with $30 at scale has proven not to work out, so red tape grows like mushrooms in that region. And log4j2 might be an example of all of us stopping for a moment and evaluating if the cost is still worth it.

rectang 4 years ago | |

It boggles the mind that someone thinks security decisions like these are made casually.

Staying sane as an open source maintainer means ignoring such thanklessness as best you can.

zmmmmm 4 years ago | | |

Perhaps "casual" is the wrong word since it does have a pejorative implication. Put more neutrally, what I find fascinating is the asymmetry b/w the weight of process applied compared to impact. I am sure the individuals concerned thought very hard about it (I could not find the discussion on the mailing list, but from what I can see it may have been kept off the public list due to the security aspect).

avgcorrection 4 years ago | | |

Isn’t git Hamano’s day job?

tgsovlerkhgsel 4 years ago | |

Are you talking about stuff getting broken by this fix, or the patching effort required?

This is relatively low risk so I would expect the mitigation to consist of "let your existing automation update it".

zmmmmm 4 years ago | | |

No, much more thinking of broken CI systems and other deployment scenarios where a shared user setup is presumed.

jwilk 4 years ago |

Related: https://blog.sonarsource.com/securing-developer-tools-git-in... ("Securing Developer Tools: Git Integrations")

ab-dm 4 years ago |

Ah, so this is why my simple github release action randomly stopped working today... awesome

db48x 4 years ago | |

Surprise!

Shalomboy 4 years ago |

There's something super jarring about the format of this blog post. I think my brain has been trained to glaze over whenever it runs into corporate abstract art at the top of a page.

sharken 4 years ago |

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

dgellow 4 years ago | |

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 focuses on offering a lightweight, native set of tools that bring the full feature set of the Git SCM to Windows while providing appropriate user interfaces for experienced Git users and novices alike.
    Homepage: https://gitforwindows.org
    License: GNU General Public License version 2
    License Url: https://raw.githubusercontent.com/git-for-windows/git/main/COPYING
    Copyright: Copyright (C) 1989, 1991 Free Software Foundation, Inc.
    Copyright Url: https://raw.githubusercontent.com/git-for-windows/git/main/COPYING
    Installer:
    Type: inno
    Download Url: https://github.com/git-for-windows/git/releases/download/v2.35.2.windows.1/Git-2.35.2-64-bit.exe
    SHA256: 8d33512f097e79adf7910d917653e630b3a4446b25fe258f6c3a21bdbde410ca

sharken 4 years ago | | |

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

usrbinbash 4 years ago |

When people ask me why I don't have a "git-aware" PS1, I shall point them to this CVE in the future.

grumple 4 years ago | |

Would be pretty incredible if the git branch command had a vulnerability.

On the other hand, having a git aware PS1 would also immediately alert you to the fact that a user had created a top level .git folder, thereby allowing you to prevent the first cve here.

usrbinbash 4 years ago | | |

> having a git aware PS1 would also immediately alert you to the fact that a user had created a top level .git folder,

And to the fact that someone other than me had write access to my disk, in which case git is probably the least of my worries.

bin_bash 4 years ago |

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

saagarjha 4 years ago | |

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

rswail 4 years ago | | |

Homebrew's mecahnisms are inherently "fail-unsafe". It really has no excuse.

bin_bash 4 years ago | | |

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

yuliyp 4 years ago |

This feels like a thing that should be introduced default-off, allowing users to opt in to it first, and once it's been in place update the default, rather than break things suddenly when updating without being able to share a git config between systems which don't upgrade simultaneously.

dataflow 4 years ago |

I feel like this doesn't have much to do with Git specifically. Seems to me like PS1 needs to avoid accessing files that aren't owned by the current user. Easier said than done though...

db48x 4 years ago | |

That’s partly true, but it is more relevant to Git than to other things because there are malicious ways to configure a git repository that will end up running programs written by someone else under your user id.

legalcorrection 4 years ago | | |

Why are you setting your ps1 to run arbitrary code in any directory? Don’t do that!

Dave3of5 4 years ago |

Awesome thanks for that !

alkonaut 4 years ago |

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 convoluted script languages or good plug-in apis than tools that duct tape together with exit codes.

rswail 4 years ago | |

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

alkonaut 4 years ago | | |

> means that you don't like the Unix model in general.

Absolutely correct. While it does have benefits in some situations, writing cross platform command line tools isn’t a place where it shines.

avgcorrection 4 years ago | | |

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

Emanation 4 years ago | |

Modular design is bad for profit, amirite

bloaf 4 years ago |

Deep inside some large enterprise company:

Jr Engineer: "Hey, I know we've always managed our little dotnet application via email and shared-network-drive, but I've been reading about a thing called "git" that we should probably use."

Sr Engineer: "Change is scary and bad, also we are not a software company. We're not going to learn some newfangled whatsit. Just email me the .vba files when you want me to review the changes with the one copy of visual studio 2008 that our team has access to."

Jr Engineer: "C'mon, give it a chance! We can leave everything the way its always been, but have better tracking of changes. Remember that time Bruno hard coded the tool to point to the C: drive? Git would let us just undo that, instead of having to search our emails for the last-most-recent version."

Sr Engineer: "Ok fine, I've got 10 minutes, show me."

Jr Engineer: "Ahh! Well I just got it installed, so let me go to the network drive... and then I think I have to git init our project folder... huh? Let me just... Maybe if I..."

Sr Engineer: "Times up! Looks like this "git" thing isn't compatible with our setup after all. Those modern dev types never make anything that works in a real enterprise environment."

sosodev 4 years ago | |

The premise of this story is one I lived. I was a web dev intern for a local government office and they actually emailed each other zips of dotnet apps.

The only difference is that my git pitch went really well and they promised they would start using it. They never started using it.

legalcorrection 4 years ago | | |

Local government software dev is making half of what they could make doing barely anything at a private sector operation. Not surprising there’s an IQ problem.

xarope 4 years ago | |

We joke, but actually the legacy team I took over a few years ago, used to do this (email each other stuff, and versioning/branching was basically copying folders around). I had to drag them kicking and screaming into git (and self-hosted gitlab - thanks gitlab; no, seriously, I do really appreciate it), and now they wonder how they ever survived.

codetrotter 4 years ago | |

Time to preemptively post this to StackOverflow and self-solve the question for some of that sweet sweet StackOverflow rep. jk

JetAlone 4 years ago | |

I can relate to both of the engineers in this puppet theater.

fargle 4 years ago |

It mildly bugs me that things like this are reported as "Git Security Vuln".

CVE-12345: insecure use of consumer grade operating system in multi-user role when expecting any form of real isolation

CVE-12346: faulty system administration techniques, including running anything as SYSTEM, can cause things to run with elevated privileges

CVE-12347: failure to secure root (C:) and important system directories can allow malicious actors to access them. This can be exploited to trick other parts of the system into doing ... things.

I don't mind patching git for windows to workaround these things, but sheesh, the root cause of both of these is people using Windows incorrectly/insecurely.

AndrewUnmuted 4 years ago | |

> people using Windows incorrectly/insecurely.

Let me fix that for you:

> people using Windows.

hsbauauvhabzb 4 years ago |

This is silly. Fix PS1, I can’t trust all repos I clone. I also want to cross-user access git log/blame etc.

megous 4 years ago | |

Can't you? What kind of foreign code can be executed that way?

Clonning will not copy .git/hooks/ nor .git/config which is the main danger here, I guess. But I'd sure want to hear about other risks.

Maybe an env variable to disable hooks execution and .git/config parsing would be nice to have for safer use of git repositories you didn't clone yourself as part of shell prompt customizations.

hsbauauvhabzb 4 years ago | | |

Git clone doesn’t mean I’m blindly executing the code inside it.

kadoban 4 years ago | |

You don't have to trust repos you clone, if I understand correctly. You just need to trust ones you're given in other ways. The difference is, clone won't let you set up arbitrary config (or malformed internal data or etc.)

hsbauauvhabzb 4 years ago | | |

Can you store a .git/config filepath in a git repository, either via the cli or manually hacking the repo data files?

megous 4 years ago | |

Also, looks like you didn't read the linked page. The first thing there is a git config option to disable this check on select directories.

saagarjha 4 years ago | | |

Obviously adding every single repo you will ever work with into the config is not workable.

wheybags 4 years ago |

This feels really pointless. If I can create /.git, I have root already. Any other parent-directory-escalation that I can think of would be so obscure as to be not worth caring about, and would also probably require having access to an already-higher-privilege account.

And of course the unspoken: almost nobody uses git on multi user systems, and when they do, most of the time every single user already has sudo.

RayJSeth 4 years ago |

This certainly came as a surprise to my team today.

We operate some number of repositories and the majority of them use https://github.com/actions-ecosystem/action-get-latest-tag - or more specifically, a fork of that repo which more or less works the same way.

Midday today our CI/CD started failing. We must have hit this so soon because the `apk add git` in that Dockerfile grabbed the new git version. Evidently the SID that ultimately executed the git command inside the included actions' dockerfile was not the same as the one that owned `/github/workspace` on the runner.

We were able to patch around using the new `safe.directory` option, but I'm curious to see if there's more fallout since CI/CD environments in particular create this sort of shared repository.

__turbobrew__ 4 years ago | |

This is why I pin all dependencies in CI/CD.

AussieWog93 4 years ago |

Fuck. Now the security guys are going to break all my shit.

chrismarlow9 4 years ago |

Just run your git checkouts in a container and then link the volume to other containers! /s