from Hacker News

Git security vulnerability announced

by delsarto on 4/13/22, 12:02 AM with 273 comments

• by dang on 4/13/22, 4:46 PM

  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.

• by tommiegannert on 4/13/22, 6:52 AM

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

• by ntauthority on 4/13/22, 6:25 AM

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

• by eminence32 on 4/13/22, 1:27 AM

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

• by krick on 4/13/22, 3:23 AM

  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.

• by jra_samba on 4/13/22, 3:02 AM

  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.

• by rst on 4/13/22, 1:21 AM

  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.

• by rvwaveren on 4/13/22, 6:37 AM

  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?

• by mlindner on 4/13/22, 3:35 AM

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

• by kazinator on 4/14/22, 6:41 AM

  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.

• by saagarjha on 4/13/22, 3:07 AM

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

• by dcow on 4/13/22, 12:31 PM

  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.

• by dotancohen on 4/13/22, 6:22 AM

  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

• by silverwind on 4/14/22, 9:12 AM

  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.

• by kgeist on 4/13/22, 5:33 AM

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

• by nodesocket on 4/13/22, 6:15 AM

  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

• by hda2 on 4/13/22, 3:20 AM

  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.

• by Matheus28 on 4/13/22, 2:30 AM

  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?

• by legalcorrection on 4/13/22, 9:12 PM

  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.

• by zmmmmm on 4/13/22, 5:00 AM

  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.

• by jwilk on 4/13/22, 8:41 AM

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

• by ab-dm on 4/13/22, 2:57 AM

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

• by Shalomboy on 4/13/22, 4:57 PM

  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.

• by sharken on 4/13/22, 9:15 AM

  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

• by usrbinbash on 4/13/22, 2:13 PM

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

• by bin_bash on 4/13/22, 2:17 AM

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

• by yuliyp on 4/13/22, 2:23 AM

  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.

• by dataflow on 4/13/22, 2:58 AM

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

• by Dave3of5 on 4/13/22, 8:37 AM

  Awesome thanks for that !

• by alkonaut on 4/13/22, 5:52 AM

  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.

• by bloaf on 4/13/22, 2:50 AM

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

• by fargle on 4/13/22, 2:13 PM

  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.

• by hsbauauvhabzb on 4/13/22, 1:57 AM

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

• by wheybags on 4/13/22, 8:30 AM

  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.

• by RayJSeth on 4/13/22, 1:52 AM

  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.

• by AussieWog93 on 4/13/22, 3:50 AM

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

• by chrismarlow9 on 4/13/22, 4:16 AM

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