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

21–30 of 51 posts

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

#21

Post by cryptbe »

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.

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

#22

Post by lloeki »

Roguelazer wrote: post #17
normie3000 wrote: post #6

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?

modelines allow you to put a special comment in your file (typically on the first or last line of the file, and [for vim] of the format `# vim: set ts=2:`) to configure a subset of editor settings automatically whenever that file is opened in a buffer. They're very common, especially in codebases where there are lots of different styles in different files. Many editors (e.g., Zed (as of https://github.com/zed-industr…

> I've never seen a modeline in the wild that did anything other than

Hence the securemodelines plugin

https://www.vim.org/scripts/script.php?script_id=1876

> if this is a class of bug that can be disabled via vim settings.

    set nomodeline
That is, as parent mentioned, if it's not done already by your distro or OS.

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

#23

Post by eterm »

Roguelazer wrote: post #17
normie3000 wrote: post #6

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?

modelines allow you to put a special comment in your file (typically on the first or last line of the file, and [for vim] of the format `# vim: set ts=2:`) to configure a subset of editor settings automatically whenever that file is opened in a buffer. They're very common, especially in codebases where there are lots of different styles in different files. Many editors (e.g., Zed (as of https://github.com/zed-industr…

They no doubt predate .editorconfig, but the problem as described is now better solved by .editorconfig, which can be used to configure directory and file specific configuration and works cross-editor too.

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

#24

Post by lloeki »

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

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

#26

Post by 152334H »

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.

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

#27

Post by chotmat »

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.

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

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

#29

Post by cryptbe »

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 strictly RCE.

At the end of the day, regardless of how you classify them, it’s worth being aware of the risks when opening untrusted files in editors like Vim or Emacs.

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

#30

Post by teiferer »

Andebugulin wrote: post #11

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, co…

> shouldn't be that many lines of code, something doable, like in couple thousands

If you believe that then you have hardly scratched the surface of what your editor is capable of doing.

Post reply on HN