Comment by i_cannot_hack | Hacker News Reader

Comment by i_cannot_hack | Hacker News Reader

Parent Full thread

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

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

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.

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

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

No

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

Reply on news.ycombinator.com