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

31–40 of 51 posts

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

#31

Post by cryptbe »

chotmat wrote: post #27
cryptbe wrote: post #21

Earlier quoted context omitted.

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.

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?

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

#32

Post by kleiba »

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.)

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

#33

Post by johnisgood »

lloeki wrote: post #19
chrismorgan wrote: post #15

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…

> We asked Claude to find a bug in Vim. It found an RCE. Just open a file, and you’re owned. Yeah reading the above opening paragraph I was immediately going "oh Claude found out about modelines" modelines are largely considered a (roundabout) equivalent to flat out eval, There's a reason plugins such as securemodelines exist: https://www.vim.org/scripts/script.php?script_id=1876

Right. I am surprised to see this considered to be an RCE. Or a "mad bug" worthy of being here on HN. sighs.

Pretty sure a lot of people have spent lots of tokens into finding RCEs in vim and emacs, he is not the first person to do this.

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

#34

Post by chotmat »

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?

Tested with zed and vscode. They don't seem to have the issue. Probably due to "Restricted Access" mode when opening new folder?

Edit: yeah pwned when clicking the big green trust button

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

#35

Post by i_cannot_hack »

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.

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 add better safeguards in git before executing hooks. But you did not report this to the git project (where even minor research beyond Claude Code would reveal to you that this has already been discussed in the git community).

I suspect that what happened here was that (1) you asked Claude to find RCEs in Emacs (2) Claude, always eager to please, told you that it indeed has found an RCE in Emacs and conjured up a convincing report with included PoC (3) since Claude told you it had found an RCE "in Emacs", you thought "success!", didn't think critically about it and simply submitted Claude's report to the Emacs project.

Had you instead asked Claude to find RCEs in git itself and it told you about git hooks, you probably would not have turned around and submitted vulnerability reports to all tools and editors that ever call a git command.

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

#36

Post by eesmith »

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…

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.

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

#37

Post by cryptbe »

eesmith wrote: post #36
cryptbe wrote: post #29

Earlier quoted context omitted.

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…

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 protect their users. Even if the root cause sits elsewhere, users experience the risk at the point where they open files. From their perspective, the editor is the last line of defense, so it makes sense to add safeguards there.

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

#38

Post by kstrauser »

pjmlp wrote: post #18
zingar wrote: post #5

Earlier quoted context omitted.

I don’t understand the connection to the post, could you elaborate?

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.

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

#39

Post by cryptbe »

i_cannot_hack wrote: post #35
cryptbe wrote: post #21

Earlier quoted context omitted.

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.

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.

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

#40

Post by [deleted] »

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…

[deleted]
Post reply on HN