For Emacs, I agree with the maintainer's analysis that this is really a git bug: what happens is that Emacs runs git ls-files and that triggers a script execution.
So, the attack vector here is the following: attacker provides a malicious script in a .git directory, packaged for download. If the user unpacks the the package and merely opens a file, Emacs runs git ls-files which in turn executes the malicious script.
However, while I agree that this is a flaw in git, and Emacs should rightfully expect that running an "ls" command should be considered harmless, I do not agree with the stance that this does not require a reaction on the part of the Emacs maintainers: Now that you've been made aware of this unfortunate git behavior, I think some steps should be taken to not trigger it. That is, the functionality that runs git ls-files should be double checked (do we really need it? can we avoid the malicious side-effects? etc.)
Overhyped, misnomer as this is not an RCE, and emacs maintainers who are correct as you can trigger the same thing by just running git ls-files to execute things if you configure the .git folder as the exploit does.
The claim is astonishing, given emacs’ continuous use and open source scrutiny for decades. Edit: and turns out to be a problem with git, not emacs.
OTOH it’s really just the core that has been used so widely and so continuously for so long. This integration with git will have been scrutinized far less.
As an emacs user I frequently find myself in territory where I’m seemingly the only person in the world with my use case. In fact that’s half of the value: I can make emacs do whatever I want. Which means there’s security consistent with a bus factor of 1.
I suspect that if you asked ten Vim developers where they’d start looking for this kind of security issue, at least nine of them would say “modeline” (and if one didn’t, it would just be because they forgot about the feature, and would change their answer to that as soon as you mentioned it). There’s a reason popular configurations have disabled it from time immemorial.
As for the Emacs thing, it feels utterly unfair to blame Emacs. The issue is 100% Git, and it’s unreasonable and undesirable for things like Emacs to try to put guard rails around parts of its functionality. Especially guard rails that may harm functionality. They were right to decline the suggested patch.
I don’t know how the sessions actually ran, but the Vim one probably started with “low-hanging fruit, let’s start by seeing if modeline has accidentally become insecure yet again”, and the emacs with “meh, don’t know anything offhand, before delving into code let’s see if… ooh look it runs Git, so can we apply the ol’ fsmonitor chestnut there?”
Doubtful commentary misses the obvious: that, had Calif been slightly more responsible in their harness design -- and in particular, their definition of what constitutes a real bug -- it'd be rather unsurprising if Claude correctly dug some up.
I'd be interested to understand what modelines are for, and if this is a class of bug that can be disabled via vim settings. Also, are there editors which could not be affected by this class of bug?
That's a bit funny to me, because the level of absurdity you get from reading something like that is insane, I have been using vim on a daily bases for more than 5 years now.
One day thought about contributing to vim because was silly enough to believe that the tool shouldn't be that many lines of code, something doable, like in couple thousands, then found out its way way more than that and closer to half a mill, couldn't even dream of understanding anything, not close to be fluent enough to find RCEs.
Those that have some git status information in their shell prompts should probably make sure they are not bitten by the same git issues. I currently have to following (zsh syntax) setup for that:
git=(git -c core.hooksPath=/dev/null)
fsmonitor=$($git config core.fsmonitor)
if [[ -n $fsmonitor && $fsmonitor != true && $fsmonitor != false ]]; then
git+=(-c core.fsmonitor=false)
echo "Worrying git core.fsmonitor setting: $fsmonitor"
fi
The first one seems to indeed be a real RCE in vim.
Also including the emacs one as a "found vulnerability" seems really disingenuous. It basically amounts to "emacs will call git status, and git status will call git hooks that can execute arbitrary code".
1. As the Emacs maintainers point out, it is indeed an issue with git, not emacs, and they are completely right to not address the issue.
2. It is something that has been known for decades. That is the reason hooks are never copied when doing git clone, to prevent this scenario (notice that the author uses wget instead of git clone to get around this).
Funnily enough this posts highlights both the strengths and the hazards of using AI, (1) quickly and easily finding real issues that would have taken a human a laborious audit to find (2) quickly and unthinkingly generating plausible sounding but ultimately meaningless vulnerability reports on some clout chasing mission and overwhelming open source maintainers with AI slop.
> How do we professional bug hunters make sense of this? This feels like the early 2000s. Back then a kid could hack anything, with SQL Injection. Now with Claude.
Lack of accountability.
With other industries, when people aren't happy with their products, they ask for money back, they sue, they switch to the competition.
There are no EULA that assert removal of customer rights if the product is acquired.
47 comments
git ls-filesand that triggers a script execution.So, the attack vector here is the following: attacker provides a malicious script in a .git directory, packaged for download. If the user unpacks the the package and merely opens a file, Emacs runs
git ls-fileswhich in turn executes the malicious script.However, while I agree that this is a flaw in git, and Emacs should rightfully expect that running an "ls" command should be considered harmless, I do not agree with the stance that this does not require a reaction on the part of the Emacs maintainers: Now that you've been made aware of this unfortunate git behavior, I think some steps should be taken to not trigger it. That is, the functionality that runs
git ls-filesshould be double checked (do we really need it? can we avoid the malicious side-effects? etc.)OTOH it’s really just the core that has been used so widely and so continuously for so long. This integration with git will have been scrutinized far less.
As an emacs user I frequently find myself in territory where I’m seemingly the only person in the world with my use case. In fact that’s half of the value: I can make emacs do whatever I want. Which means there’s security consistent with a bus factor of 1.
As for the Emacs thing, it feels utterly unfair to blame Emacs. The issue is 100% Git, and it’s unreasonable and undesirable for things like Emacs to try to put guard rails around parts of its functionality. Especially guard rails that may harm functionality. They were right to decline the suggested patch.
I don’t know how the sessions actually ran, but the Vim one probably started with “low-hanging fruit, let’s start by seeing if modeline has accidentally become insecure yet again”, and the emacs with “meh, don’t know anything offhand, before delving into code let’s see if… ooh look it runs Git, so can we apply the ol’ fsmonitor chestnut there?”
Also including the emacs one as a "found vulnerability" seems really disingenuous. It basically amounts to "emacs will call git status, and git status will call git hooks that can execute arbitrary code".
1. As the Emacs maintainers point out, it is indeed an issue with git, not emacs, and they are completely right to not address the issue.
2. It is something that has been known for decades. That is the reason hooks are never copied when doing git clone, to prevent this scenario (notice that the author uses wget instead of git clone to get around this).
Funnily enough this posts highlights both the strengths and the hazards of using AI, (1) quickly and easily finding real issues that would have taken a human a laborious audit to find (2) quickly and unthinkingly generating plausible sounding but ultimately meaningless vulnerability reports on some clout chasing mission and overwhelming open source maintainers with AI slop.
> How do we professional bug hunters make sense of this? This feels like the early 2000s. Back then a kid could hack anything, with SQL Injection. Now with Claude.
Lack of accountability.
With other industries, when people aren't happy with their products, they ask for money back, they sue, they switch to the competition.
There are no EULA that assert removal of customer rights if the product is acquired.