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.
Mad Bugs: Vim vs. Emacs vs. Claude
11–20 of 51 posts
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#12The 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.
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#13Overhyped, 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.
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#14The 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.
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#15I 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?”
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#16I'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 are special lines you can put into files that sets vim options when the file is read by vim. Probably most commonly used to set tab space and tab width.
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#17I'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-industries/zed/pull/49267)) support vim and/or emacs's syntaxes for modelines.
Modelines were disabled by default for security reasons for a long time. It's kind of wild to me that they're enabled in some distributions, but there still isn't much restriction on what settings can be configured; I've never seen a modeline in the wild that did anything other than set `filetype`, `fileencoding`, `tabwidth`, `expandtab` (hard tabs vs spaces), and maybe `tabstop` / `softtabstop`.
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#18> 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.
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.
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#19I 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:
Re: Mad Bugs: Vim vs. Emacs vs. Claude
#20I 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…
Yup, I've had "nomodeline" in my vimrc for years. I used to add the "securemodelines" plugin https://www.vim.org/scripts/script.php?script_id=1876 but just recently removed that too (I think I may have ran into an annoyance after a vim update, and decided I never really use automatic modeline support anyway)