Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mad Bugs: Vim vs. Emacs vs. Claude

blog.calif.io

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#41

Post by i_cannot_hack »

lloeki wrote: post #24
i_cannot_hack wrote: post #14

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 h…

> The first one seems to indeed be a real RCE in vim. Barely, since there is little restriction as to what options modelines can set they should be largely considered equivalent to eval (if unintentionally). And generally they are which is why distros typically disable them by default. IMHO in this day and age securemodelines should just be the default. https://www.vim.org/scripts/script.php?script_id=1876

I don't know much about vim, but from the report it sounds like part of the issue was that disabling modelines would not prevent it:

> tabpanel is missing P_MLE Unlike statusline and tabline, tabpanel is not marked with the P_MLE flag. This allows a modeline to inject %{...} expressions even when modelineexpr is disabled.

Edit: Upon re-reading the above I guess disabling modelineexpr is not the same as disabling modelines, and disabling modelines altogether might indeed prevent the issue.

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#42

Post by snarf_br »

cryptbe wrote: post #31
chotmat wrote: post #27

Earlier quoted context omitted.

I don't think this is fair, as it will likely also affect any editor with Git integration (or not?)

Yes, likely. And git is not going to fix it. So isn't it fair to expect the editor maintainers to do something about it, to protect their users, no?

No

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#43

Post by johnisgood »

cryptbe wrote: post #37
eesmith wrote: post #36

Earlier quoted context omitted.

I'm pretty sure the lesson is that at the end of the day, it’s worth being aware of the risks of using git, as security issues intrinsic to git can extend to other tools which use git as a component.

I think we can agree that Git is at least partly responsible for this issue, if not more. That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context. This is why I think editor maintainers should do more to p…

Please read the LLM output critically instead of doubling down on it.

Your defense-in-depth framing makes no sense. If .git/config or similar mechanisms are the attack vector, then adding more editor safeguards would be treating a symptom, as the real problem is git's trust model. The "users don't think about git when using editors" argument also proves too much. Many users also do not think about PATH, shell configs, dynamic linker, or their font renderer either, but you cannot make editors bulletproof against all transitive dependencies...

Seriously, it is actually backwards. Git is where the defense belongs, not every downstream tool that happens to invoke git. Asking editors to sandbox git's behavior is exactly as absurd as it sounds.

And BTW, "technically AV:L but feels like RCE" is your usual blog-post hype. It either is, or is not.

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#44

Post by eesmith »

cryptbe wrote: post #37
eesmith wrote: post #36

Earlier quoted context omitted.

I'm pretty sure the lesson is that at the end of the day, it’s worth being aware of the risks of using git, as security issues intrinsic to git can extend to other tools which use git as a component.

I think we can agree that Git is at least partly responsible for this issue, if not more. That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context. This is why I think editor maintainers should do more to p…

Sure, but you said that was the end of the day analysis, and I didn't think you went far enough in your analysis.

FWIW, I'm not thinking about git at all since I use Mercurial, and never enabled vc hooks in my emacs, which is based on 25.3.50.1, so wasn't affected by this exploit - I tested. I use git and hg only from the command-line.

My end-of-day analysis is to avoid git entirely if you can't trust its security model. ;)

Should the emacs developers also do more to secure emacs against ImageMagick exploits?

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#45

Post by pjmlp »

kstrauser wrote: post #38
pjmlp wrote: post #18

Earlier quoted context omitted.

Those kinds of bugs exist because no-one is accountable for quality like in other industries, unless it is on high integrity computing, or the cyber security laws that are finally coming into place across several countries.

The FSF will give you a full refund for Emacs if you’re not satisfied.

We get what we pay for, as for FSF.

https://fsfe.org/news/2025/news-20251218-01.en.html

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#46

Post by chrismorgan »

cryptbe wrote: post #39
i_cannot_hack wrote: post #35

Earlier quoted context omitted.

But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either. If you don't trust git, you can remove from your system or configure emacs not to use it. If you are worried about unsuspecting people with both git and emacs getting into trouble when downloading and interacting with untrusted malware from the internet, the correct solution is to…

>But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either. That’s fair, but it would be pretty unusual for me to run Git commands in a directory I’m not actively working on. On the other hand, I open files from random folders all the time without really thinking about it, so that scenario feels much more realistic.

It’s extremely common for shell prompts to integrate Git status for the working directory.

Who’s responsible for the vulnerability? Your text editor? The version control system with a useful feature that also happens to be a vulnerability if run on a malicious repository? The thing you extracted the repository with? The thing you downloaded the malicious repository with?

Windows + NTFS has a solution, sometimes called the “mark of the web”: add a Zone.Identifier alternate data stream to files. And that’s the way you could mostly fix the vulnerability: a world where curl sets that on the downloaded file, tar propagates it to all of the extracted files, and Git ignores (and warns about) config and hooks in marked files. But figuring out where the boundaries of propagation lie would be tricky and sometimes controversial, and would break some people’s workflows.

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#47

Post by Ferret7446 »

cryptbe wrote: post #21
i_cannot_hack wrote: post #14

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 h…

When I wget a tarball, unzip, and emacs a.txt inside, I don't expect that it'd execute arbitrary commands. I think people should be aware of this risk, especially when it looks like it's not getting fixed. Disclosure: I didn't find the bugs. I helped wrote the blog post.

If you untar a file and get a git repository, you should absolutely expect malicious behavior. No one does that, you clone repos not tarball them, and cloning doesn't copy hooks for precisely this reason

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#48

Post by drougge »

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

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#49

Post by a456463 »

cryptbe wrote: post #29
snarf_br wrote: post #13

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.

Disclosure: I didn’t discover the bugs, but helped write the blog post. These issues are technically classified as local code execution (AV:L), but they go against a pretty strong user expectation: that opening a file should be safe. In reality, they can be triggered through very common workflows like downloading and opening files, which makes them feel a lot closer to some remote scenarios, even if they’re not stric…

That is not an RCE. That is an RTFM and you need to learn that you don't download stuff you don't know about

Re: Mad Bugs: Vim vs. Emacs vs. Claude

#50

Post by a456463 »

cryptbe wrote: post #37
eesmith wrote: post #36

Earlier quoted context omitted.

I'm pretty sure the lesson is that at the end of the day, it’s worth being aware of the risks of using git, as security issues intrinsic to git can extend to other tools which use git as a component.

I think we can agree that Git is at least partly responsible for this issue, if not more. That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context. This is why I think editor maintainers should do more to p…

Git is also not responsible. Please stop drinking this LLM coolaid and trying to get hype on that.
Post reply on HN