Git security fixes released
source link: https://lwn.net/Articles/891112/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Git security fixes released
On multi-user machines, Git users might find themselves unexpectedly in a Git worktree, e.g. when another user created a repository in `C:\.git`, in a mounted network drive or in a scratch space. Merely having a Git-aware prompt that runs `git status` (or `git diff`) and navigating to a directory which is supposedly not a Git worktree, or opening such a directory in an editor or IDE such as VS Code or Atom, will potentially run commands defined by that other user.
(Log in to post comments)
Git security fixes released
Posted Apr 13, 2022 8:39 UTC (Wed) by tamiko (subscriber, #115350) [Link]
For example, one a Linux machine user A can simply create a git repository in /tmp and when user B comes along who happens to have a shell command line showing a git repository status it is game over. I remember discussing this with someone years ago...
Git security fixes released
Posted Apr 13, 2022 16:15 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
Git security fixes released
Posted Apr 13, 2022 17:09 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Git security fixes released
Posted Apr 13, 2022 21:47 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
> If set, the value of this variable is used as a command which will identify all files that may have changed since the requested date/time. This information is used to speed up git by avoiding unnecessary processing of files that have not changed.
… which seems like a natural fit for a command like `git status`.
Perhaps configuration options which define external commands such as this should only be honored in the system and user global configuration files, and not the ones in the repos? (This would also include aliases, diff tools, filters, etc.)
Git security fixes released
Posted Apr 13, 2022 22:09 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Please no. I enable LFS per-repo because I don't want to clone a repo and get smacked with tons of data I don't care about because I'm fixing a typo. Fedora's `git-lfs` package now has a(n opt-in) mechanism to stop it from installing its filter configuration on the system because I asked for it :) .
At $DAYJOB, we also use repo-local aliases which call scripts in the repo so that we can maintain them sensibly.
Git security fixes released
Posted Apr 13, 2022 17:26 UTC (Wed) by jthill (subscriber, #56558) [Link]
You can't alias builtins for obviously good reason, I think it's that a planted config could define aliases that will override the user's possibly in a way that's hard to detect, so the user might use `git st` whether in their prompt generator or otherwise. Computer labs full of teenage boys . . . yeah, okay.
The check is only on auto-discovered repos, easy enough to shut it off by specifying the repo in GIT_DIR when you know the one you want.
Seems to me the safe-directory entries should support globbing, making trusted environments hard to administer is legitimately objectionable.
Git security fixes released
Posted Apr 13, 2022 9:32 UTC (Wed) by ceplm (subscriber, #41334) [Link]
So, what has actually changed?
Git security fixes released
Posted Apr 13, 2022 10:19 UTC (Wed) by nye (guest, #51576) [Link]
The thing that confuses me is why all the talk about this seems to imply that it's especially bad on Windows, which seems rather counterfactual - on Windows you're a great deal less likely to be using a directory under some shared common directory like /tmp, so this is essentially limited to "attacks" from an administrator who can change system directories. But an administrator could just modify your files without bothering with this "exploit", so...
Git security fixes released
Posted Apr 13, 2022 12:11 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
On Unix it's possible to set PS1 to use git, but it's not something I've actually seen used, so most users would need to proactively invoke git to get into trouble.
The other vulnerability is specific to the Uninstaller utility for Git on Windows and so doesn't exist on platforms where that's not how you uninstall software.
Git security fixes released
Posted Apr 13, 2022 12:55 UTC (Wed) by k3ninho (subscriber, #50375) [Link]
I have a lot of colleagues who do this, and the Ubuntu ec2 I'm running hash a .bashrc that pulls in /usr/lib/git-core/git-sh-prompt to add the branchname to the shell prompt. I guess it's popular enough that core git package supplies the __git_ps1 function. "it's 1337, u kno."
Git security fixes released
Posted Apr 13, 2022 12:57 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Git security fixes released
Posted Apr 13, 2022 13:27 UTC (Wed) by jdisnard (subscriber, #90248) [Link]
According to my anecdotal experience, it's very very common. I've seen dozens of developers have such a prompt in their bash or zsh shell environment.
The idea is so common that the upstream GIT project documented how it works:
https://git-scm.com/book/en/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Bash
Git security fixes released
Posted Apr 13, 2022 15:00 UTC (Wed) by ceplm (subscriber, #41334) [Link]
Git security fixes released
Posted Apr 13, 2022 18:21 UTC (Wed) by dskoll (subscriber, #1630) [Link]
I use PS1 to set the git branch in my prompt, but I don't actually invoke git to find the branch. I wrote my own program that traverses up to / looking for .git/HEAD. It's way smaller and faster than git and also much simpler.
Git security fixes released
Posted Apr 13, 2022 18:35 UTC (Wed) by dtlin (subscriber, #36537) [Link]
But does it know how to follow git-worktree to the base repository? There's no .git/HEAD there.
Git security fixes released
Posted Apr 13, 2022 19:26 UTC (Wed) by dskoll (subscriber, #1630) [Link]
Well, I guess it would fail. But so far it works for all of my use-cases. The source, if anyone is interested, is at gitquickbranch.c.
Git security fixes released
Posted Apr 14, 2022 2:36 UTC (Thu) by NYKevin (subscriber, #129325) [Link]
1. The right, but difficult way: Spawn a daemon or daemon-like process (running as yourself, e.g. using systemd's --user functionality, or just by persuading your shell to fork off a coprocess somehow) which knows how to find all of the information that your shell needs to print out its prompt, and then have your shell asynchronously send "I cd'd to a new directory" notifications to this daemon and asynchronously read updated prompt information from the daemon via some pipe/socket nonsense. Then you can get away with running heavy stuff like Git or Mercurial in the daemon, and your shell updates its prompt when the daemon eventually gets back to it.
2. The wrong, but easy way: Take shortcuts such as looking for .git, .hg, etc. by hand, hard-coding paths that you "know" have certain semantics in practice (e.g. "I know that the Git repos always live under /foo/bar/ on this system, so I will match ${PWD} against that prefix and then do [[ -d /foo/bar/$WHATEVER_WE_MATCHED/.git ]] to see whether we're in a Git repo"), etc., and never, ever spawn any more subshells than absolutely necessary (e.g. if a shell function has to return a string, do REPLY="$value" instead of printf "%s\n" "$value", and then you don't need to run it in a command substitution).
Tooling for (1) exists (e.g. zsh-async), but it's slightly more of a PITA to set up compared to just doing (2) everywhere (and also, I don't like running random GitHub code at $WORKPLACE unless it's in the package repository and somebody has vetted it), so you end up with horrible spaghetti code all over your .bashrc/.zshrc/what-have-you. It's a problem, but I wouldn't call it a big problem because ultimately it's just a shell prompt, it doesn't (directly) make $WORKPLACE money or anything like that.
Git security fixes released
Posted Apr 13, 2022 12:48 UTC (Wed) by draco (subscriber, #1792) [Link]
Git security fixes released
Posted Apr 13, 2022 12:59 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Git security fixes released
Posted Apr 13, 2022 14:26 UTC (Wed) by Karellen (subscriber, #67644) [Link]
IIRC one of the reasons that Windows started creating paths with spaces by default back in the '90s (e.g. "My Documents", and later "Documents and Settings") was so that apps would have to support spaces in paths if they wanted to be capable of moving away from legacy FAT "mydocu~1" altnames.
The idea that there are Windows applications - and not just in-house LOB apps, but actual development tools like build systems - in the 2020s that don't support spaces in paths is mind-boggling.
Git security fixes released
Posted Apr 13, 2022 17:06 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Which was naive. Instructions just said to go to `C:\foo` instead. This may have worked for a while, but then `Documents and Settings` made it easy to run into path length limits (MSVC still has problems with some long filenames) which made projects run back to `C:\foo` and lose their spaces-in-paths test cases.
> but actual development tools like build systems - in the 2020s that don't support spaces in paths is mind-boggling.
IME, the issues actually usually come from autoconf-based (or raw Makefile) packages where quoting those `$(topdir)` and such expansions is pretty lax. In CMake, you're usually OK, but sometimes someone does something that tries to pass paths around without any thought about "might be seen as two words later".
Git security fixes released
Posted Apr 14, 2022 2:39 UTC (Thu) by NYKevin (subscriber, #129325) [Link]
Git security fixes released
Posted Apr 13, 2022 15:40 UTC (Wed) by nye (guest, #51576) [Link]
That's pretty horrifying but I suppose there are compatibility concerns that would make it hard to fix now.
Git security fixes released
Posted Apr 13, 2022 14:13 UTC (Wed) by nickleverton (subscriber, #81592) [Link]
Git security fixes released
Posted Apr 13, 2022 22:42 UTC (Wed) by hmh (subscriber, #3838) [Link]
Including in git itself. Look at the reply to the announcement message...
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK