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.
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`.
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
/* vim: set showtabpanel=2 tabpanel=%{%autocmd_add([{'event'\:'SafeStateAgain','pattern'\:'*','cmd'\:'!id>/tmp/calif-vim-rce-poc','once'\:1}])%}: */If you believe that then you have hardly scratched the surface of what your editor is capable of doing.
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.
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.
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.
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.
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.
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?”
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:
grimm8080•1h ago
virtue3•1h ago
Basically the worst possible thing.
snarf_br•1h ago
It is code execution.
chrismorgan•1h ago
This, however, is mislabelled: it’s not remote code execution at all, only local. It would only become RCE if there was some path to remotely triggering Vim to open the attack file, or Emacs the attack repository, or if a normal way of fetching a repository automatically set up and executed the hook.