James Endres HowellUhhh, guys? This looks real bad
"GNU Emacs: Multiple Remote Code Execution Vectors on File Open"
https://github.com/califio/publications/blob/main/MADBugs/vim-vs-emacs-vs-claude/Emacs.md
cehteh@jameshowell nice find, but looks more like an git issue to me. emacs is the culprit as it executes `git ls-files` but a user can do the same and wont expect that this executes attacker controlled scripts. Other IDE's probably also calling git ls-files.
The suggested fix is also overly specific. other git mechanisms execute scripts stored in .git too (hooks, diff/merge engines, signing).
Bottom line is: clone git, don't ship/touch/unpack untrusted archives that have a .git included.
Thomas@cehteh Ni, this is an Emacs problem. It's the one calling git unprompted. If it can't do that safely, it's up to Emacs to not*
Arguable that cripples the usefulness (anyone checked #Magit, may have the same problem).
The suggested fix is inadequate at least.
A rather drastic fix would be that git itself maintains a list of trusted repositories (the ones it cloned or initialized itself), plus a UI to add/remove/gc from this list. then only executing content from these .git's and rejects everything else.
One could implement that for emacs alone, keeping a list of trusted git repos and reject git on untrusted one. But thats not a fix on the root of the problem.
@cehteh @jameshowell This is 100% on Emacs to fix, because it is Emacs that is unprompted running git on a repository
I agree that git's design here is the problem, but to run an unsafe tool without asking isn't acceptable. Yes that will reduce the usefulness of vc-mode, but so what? A state of "this is inside a git-controlled workarea, and you'll have to do something to get more information" is really the only safe automatic use of git
Simon Tatham@tfb @cehteh @jameshowell this won't make me popular, but I think there's a git problem _and_ an emacs problem.
Git knows that .git/config is dangerous. It will refuse to do operations that depend on it, if you cd into a git checkout owned by a different user and try to run (even readonly) git commands there. But its starting assumption is that if a git checkout _is_ owned by the current user, then it's trustworthy. And receiving a git repo from someone else in a tarball invalidates that assumption.
An intermediate git user might know about executable things in .git/hooks and realise that, say, 'git commit' is equivalent to running code out of the tarball someone just sent you. But they might still not know about core.fsmonitor (I didn't until today), and think that 'git status' or 'git log' still ought to be safe. And even a novice user, who hasn't learned about git hooks yet, doesn't deserve to be pwned for their ignorance.
I *have* run git commands by hand on .git directories in tarballs people sent me. (Normally in the context of recruitment coding tests a few years ago – if the candidate's solution tarball includes git history then that gives useful insights.) So I'd have been vulnerable to an attack via core.fsmonitor even if I were not an Emacs user at all.
The Emacs issue makes this worse, because even if you knew the git repo was potentially hostile and were carefully not running git commands in it, oops, emacs has run one anyway on your behalf. Worse still, if you didn't even _know_ there was a .git directory there, because it doesn't show up in the default 'ls', emacs *has* noticed, and started using it without you having the chance to decide whether to trust it.