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 will pick up and call/run, even on simple operations like displaying the prompt.
It's not doing it on it's own, I believe what they're referring to is a a pre-configured distribution of a shell packaged with some distributions of Git, for some OSes.
I'm aware, which is why I phrased it like I did. A lot of folks don't know or understand the distinction when they're installing Git (or installing something else that happens to bring Git with it).
The overarching point is that the shell itself is not installing anything at shell runtime. E.g. it's the Git Bash installer, not opening `bash`.
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:
On Ubuntu those aren't installed into bash by default, but you need to add it yourself to your ~/.bashrc (or zsh or whatever, but those aren't the default in Ubuntu).
The mechanisms aren't in place for a package to inject itself into your prompt, but it isn't unthinkable (though maybe unwanted) to have that. Similar to how tab-complete for bash is handled:
The `git` package installs a file `/usr/share/bash-completion/completions/git` which is picked up by bash, on Ubuntu, as a pluggable way to extend autocomplete on bash. Many packages do this, on my machine there's 960 files in there (ls -1 /usr/share/bash-completion/completions/ | wc -l).¹
It would be trivial to have a similar mechanism for `bash_rc.d` which allows for a pluggable system to extend and modify your bash. Again, I presume this to be unwanted. I would oppose it.
¹ This is why I was surprised to learn that people like zsh for the reason that it offers tab-completion: I always presumed bash did that out of the box for any installed package already. Turns out it is Ubuntu (or better: Debian) doing this for me.
> It would be trivial to have a similar mechanism for `bash_rc.d` which allows for a pluggable system to extend and modify your bash.
There is /etc/profile.d/ which serves much the same purpose for login shells, though PS1 is normally a non-exported shell variable so it wouldn't be inherited. You can configure most other aspects of the shell this way, however. And there is also /etc/bash.bashrc which is read before ~/.bashrc, though it doesn't provide a convenient directory for drop-in scripts by default the way /etc/profile does. It would be trivial to add that if desired. (All based on Debian; YMMV.)
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.
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
Command shells assume a lot of things, such as your preferred text editor, locale, input and output devices, etc. Most of these things can be configured, but the default install makes assumptions based on common configurations.
Yeah, I'm familiar with PS1, but I was a bit surprised to learn that simple things that a PS1 script might do (git status, perhaps) are attack vectors. It seems that one big concern is the core.fsmonitor option (which I just learned about now). From the git-config man page:
> 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.
That’s where you should have been concerned. Just typing a bare return will run some arbitrary code, as you, wherever you might be in the filesystem. If all of that isn’t under your control, someone can do anything to you.
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.
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?)
I can cheerfully confirm that I've absolutely never:
- received a git repo as an archive from someone, and then
- changed to root with "su" before unpacking it somewhere, such that
- the chosen location was above the home directory layer of a multi-user system.
- in such a way that one of the directories of the /path/to/home path has a .git/ subdirectory as a direct child, and not as an unpacked-tarball/.git grandchild which would not be accidentally found by git. I.e. that one of these directories exists, which might be found by someone running "git" in their home:
which will not be found by someone running "git" in their home directory.
If I did such a thing, I'd care more about what happens when I happen to step on one of the malicious hooks in that repo as root, and less about what happens if users step on it.
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 this sort of. OK, you're a user, with some shell script, maybe git, maybe bash and it's PS1, I don't care, all I see as a kernel is that, you have permissions to edit this, upload this, send a packet, whatever, have fun!
From that perspective, nothing is wrong. That was my point. You could download s script that does 'rm / -Rf' and there's no security issue. User are given access to do as they please with files.
The issue is users can no longer reasonably trust the software on their system, from home-dialing marketing information and tracking, to having all sorts security issues in their virtual machines and sandboxes, running random code from websites constantly, we need a better way to encapsulate per file, per folder, per camera, per whatever, permissions, implemented at a system level.
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.
The source machine may not be set up as a server, or you may not have an account there. Sending a .zip file could be simpler than pushing the repo to a third system the receiver does have access to.
Sure, mailing binaries can also be the right thing sometimes, but just as with git repos, you definitely shouldn't be taking them from untrusted sources.
(and I bet that many people don't even realize how easy using `git push` to mirror a repo actually is, since git is very commonly used in a centralized fashion)
I don't think I ever did. I usually have an opposite problem and sometimes accidentally zip/tar a repo when it shouldn't be included (at least there's `--exclude-vcs`).
In any case, this doesn't sound like a good idea at all, as git hooks exist.
You’re right but also I’m mad that you’re right. I need to check what hook functions there are, but I knew about hooks and still overlooked them, which to me thinks that they’re non obvious. Maybe git should prompt you on first run, which is either whitelisted on your host or signed by your git keys or similar
