5 ms·

Long time Emacs Lisp coder here. Here is a summary of the vulnerability described in the OP: Anyone wishing to inspect an untrusted file of Emacs Lisp code is

Long time Emacs Lisp coder here. Here is a summary of the vulnerability described in the OP: Anyone wishing to inspect an untrusted file of Emacs Lisp code is likely to use Emacs to do the inspecting, but if either of the popular packages Flymake and Flycheck is enabled, merely opening the untrusted file gives the author of the file the ability to run arbitrary code (because macros are tricky). Even if an Emacs user avoids Flymake and Flycheck, the standard emacs facility for "completing" the names of functions and variables has the same basic vulnerability. Specifically, if the user uses Emacs to open the file, then types the start of the name of a function or variable, then types M-tab (i.e., presses the escape key, then presses the tab key) which attempts to fill in the rest of the name so that user does not have to manually type out the whole name, the arbitrary code is run. It is clear to me (who was never tempted to use Flymake or Flycheck) what remediation I want: namely I want this "M-tab" functionality (which I have been using and probably most Emacs users have been using) to refrain completely from expanding any macros even though doing so will prevent it from finding out the names of some of the functions and variables I might be trying to insert with the result that sometimes I will have to type out the full name of the function or variable, without assistance. >AFAICT the earliest public discussion about the security implications of Emacs Lisp macros started in August 2018, when Wilfred Hughes noted that code completion can lead to arbitrary code execution via macro-expansion. The fact that the maintainers have yet to fix this is one more sign added to a list of 5 or 6 other signs that make me want to migrate away from Emacs.

bee_rider 2y ago
Doesn’t vim also have some ability, easily abused, to put a script at the top of a file, and it’ll just run when you open the thing? This seems like a really useful functionality to have in the context where you actually do trust the files, but it is wildly insecure and an unexpected trapdoor, to have simple files executing things when you open them with a simple text editor…
- taeric 2y ago
  Emacs has that, too. There are protections in that case, though. See: https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Sa... Probably going to add similar protections here? Basically, I'd assume if it is your first time visiting a file, macros won't be expanded during autocompletion.
  - bee_rider 2y ago
    I dunno. I can see why this functionality might be useful, but I kinda think distros should disable it by default/make it whitelist-only. I think the implications are really unexpected for “new” users (where “new” could be pretty generously defined, I mean, I know a couple people who use vim IRL, I think they would not expect this… it is the sort of thing you know about if you are somebody who goes online to talk about text editors I think). And these are also the sort of users who are used to seeing shebangs and other line noise at the top of files, not understanding it, and ignoring it. I think we’re only being protected by the fact that spreading a virus though command-line text editors is… going to result in not a ton of hits.
    - taeric 2y ago
      I'm confused. Per the doc, it is disabled by default? Specifically, the first time it is encountered on a file, it will ask the user if they want to allow it. And they flat out don't ever do things like "eval" during these values.
- magic_smoke_ee 2y ago
  A common pitfall of IDE integration for dynamic languages is that it tends to execute the code under test to provide contextual completion or may decide to run doctests, etc. This has been/is a problem with editing Ruby code, and perhaps Python code and more too too. I'm unsure if this is a problem editing vimscript or lua with NeoVim with the only non-evidence is that I haven't heard of it.
- hollerith 2y ago
  That's a different potential vulnerability. I knew about that one (and had disabled the running of such scripts). I didn't know about this one till today. Helping me finish typing the name of a function or variable ("completion") is not the sort of thing I expected (till today) the maintainers of Emacs to be so eager to do that they'd start running code that I never asked to be run.
  - lmz 2y ago
    It's that Lisp data is code, code is data thing.
    - hollerith 2y ago
      No, it is not.
uludag 2y ago
Giving the maintainers the benefit of the doubt, I think the optimal solution solution would require a lot of thought and work. While I have no doubt that Elisp is an environment especially ripe for these kinds of exploits, it's by no means unique to Emacs. Just look at VSCode's solution to this problem: https://code.visualstudio.com/docs/editor/workspace-trust https://code.visualstudio.com/docs/editor/workspace-trust .
- hollerith 2y ago
  I strongly prefer vscode's solution to the current state of affairs in Emacs.
  - uludag 2y ago
    I have no doubt that VSCode has a much less risk of executing code by opening something. Ironically however, it seems that VSCode's extension is the most effective channel to distribute malware in the history of code editors. [1] [2] Not that MELPA couldn't be used to distribute malware either, I just think, as another poster mentioned, these problems are almost more social than technical. [1] https://www.bleepingcomputer.com/news/security/malicious-vscode-extensions-with-millions-of-installs-discovered/ https://www.bleepingcomputer.com/news/security/malicious-vsc... [2] https://arxiv.org/html/2411.07479v1 https://arxiv.org/html/2411.07479v1
    - alwayslikethis 2y ago
      If anything, Emacs users are probably much more likely to inspect the code of whatever extension they are using, since with every help page there is a link to the source code. It helps that it's much less popular and so not as big of a target.
      - deleted 2y ago
        [deleted]
  - dietr1ch 2y ago
    Emacs is just too old to be architected with security in mind. It's a great editor, but has baggage that IMHO can't be addressed on the spot. Working on a codebase where you can't (heavily?) break things between any commit imposes such a slow pace that it's not completely unreasonable to start from the ground up and just study what made Emacs great and what didn't work too well. It's surprising how long Emacs has been around and how good of an editor it is. It really makes rewrite attempts such a long stretch that it exhausts the motivation and time out of spirited folks that give it a go, but I think that given how complexity is being modularised and moved out (LSP, DAP, grammars) and newer languages make packaging easier that Emacs will eventually be replaced, definitely without covering everything it can do, but being strong at the average editing session.
quotemstr 2y ago
You could also macroexpand in a sandbox, e.g. via LSP.
- hollerith 2y ago
  That would involve a rewrite because the way it is now, the relevant code does not use LSP.
  - quotemstr 2y ago
    Okay, but software is infinitely malleable
throwanem 2y ago
I'm a lot less worried about this than I am about MELPA packages being targeted. But any other editor that incorporates a package manager exposes the same threat surface, and just about all of them are a lot more popular (thus more worth targeting) than Emacs.
- SoftTalker 2y ago
  Yes, it boils down to "be careful with untrusted code" no matter where it comes from. This is certainly not unique to emacs.
  - EasyMark 2y ago
    I'm starting to get "return to notepad++" vibes from HN today.
    - SoftTalker 2y ago
      Well I use mostly stock emacs. If that's already owned, then I guess I'm screwed. I'm very selective about adding additional packages or using other "uninspected" elisp code.
_verandaguy 2y ago
The Church of Vim is always accepting new disciples. Jokes aside, if you're considering Vi-like editors (and assuming you haven't already done your research -- which by the sounds of it, you may well have): - I recommend going for Neovim over classic Vim at this point. The first-class Lua support for building out your configs and working with extensions is a big quality-of-life improvement over just VimL, and it's a more portable skill with fewer surprises. As a bonus, this gives you access to a world of shockingly high-quality extensions that require Lua to run. - If you want a decent starting point before you start tweaking a ton of settings, Spacevim is it. I haven't used it extensively but I've only heard good things. - I recommend against trying to use Emacs bindings in Vim if you can help it. I used these when I initially moved over (at this point about a decade ago) and they were clunkier than both Emacs's bindings and Vim's native bindings. Learning how to work with Vim's modes is an investment that pays off as quickly as a few days with intense use, or a few weeks with more casual use. - `vim-arpeggio` (or the native chording support in newer versions of Neovim) is your friend for avoiding `<Esc>`-induced repetitive-strain injury.
- sevensor 2y ago
  As a schismatic from the Church of Vim, I’m compelled to recommend kakoune here. Unless you’re running in a peculiar legacy platform like Windows or Amiga, the selection oriented editing and smooth Unix integration are a delight.
  - samatman 2y ago
    I've considered it from time to time. The conclusion I keep drawing is that, if I were going to benefit from a selection-oriented editing paradigm, I would use Visual mode more than I do. The multi-cursors, those I want. But I'm willing to wait for Neovim to get them.
    - sevensor 2y ago
      That’s entirely reasonable; I switched in part because I was using visual mode so much. That being said, if you want a more vi-like experience in kakoune, you can always pipe your whole buffer through sed :)
nojs 2y ago
What are the other 5, out of curiosity?
nine_k 2y ago
It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited, should not be a lot of work, or at least doable. Disable it in your config, get a nerfed-down but shields-up elisp editing mode. Am I missing anything here? E.g. should I expect pieces of C code that handle completion in elisp mode?
- chlorion 2y ago
  Would you mind explaining how you could do this?
  - nine_k 2y ago
    I expect that the entire mode is implemented in elisp-mode.el. It's based on lisp-data-mode, but I don't expect that to handle macros (should check though). Looking at elisp-completion-at-point and likely deeper into elisp--completion-local-symbols, I'd try to find where macroxpansion occurs, and make it conditional. Same for the explicit emacs-lisp-macroexpand. I would also search for `(eval ` in general and maybe put it under a buffer-local flag, too, so that you won't press C-x C-e or C-M-x and execute malicious code by mistake, when you know you're working on a piece of malicious code. Maybe instead of a defcustom, it should rather be a minor elisp-paranoid-mode which would do all kinds of things to prevent execution of the code in the buffer, or the code the buffer refers to, etc.
- G3rn0ti 2y ago
  > It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited Probably, yes. „org-babel“ can execute shell code inside an org document but always asks the user before it does. You can disable this if you want to. No big deal. Should totally work like this in elisp-mode, too.
mfld 2y ago
Good call to prevent macro expansion. Does also no big harm nowadays as there are several other ways to get good auto completion, e.g. copilot. Other than that no need to restrict functionality for power users.
iLemming 2y ago
> 5 or 6 other signs that make me want to migrate away from Emacs. Sure, Emacs is not without deficiencies. But what are the alternatives? Name one option that can do things in the way that Emacs allows you to? Don't say 'Vim' - as a die-hard vimmer who uses both daily, I can confidently tell you - it may take decades until Vim becomes sufficiently good to replace Emacs for me. And if you say 'VSCode', I'd simply laugh coughing up org-mode structured headings.
- dark-star 2y ago
  sure, if you're looking for something that can perfectly replicate what Emacs does, then you'll never find an alternative... Every alternative has obvious shortcomings, at least on first glance, that you have to get used to. I have never used Emacs (other than briefly starting it up in the 90s, waiting 5 minutes for it to load on my old 386, just to be completely overwhelmed and closing it again) but I have used other tools that I replaced (sometimes multiple times) over the years. And it has never been "smooth". The first few days are full of compromises until you get into a mode of working "with" the new software instead of "against" it. Then it usually begins to make sense and after a week or two you've in business
  - iLemming 2y ago
    Okay, but you know what? During my career as a software developer, I have wasted over a decade "getting used to" things being shitty, passively accepting mediocrity and suboptimal solutions. Learning Emacs (and Vim too) finally made me realize that I was doing things wrong - I needed to be in charge. As a computer programmer, I should be commanding software, not being constrained by it. Emacs has granted me that power by acting like glue. I don't turn away from useful software; I do use it. I just do it through Emacs, not instead. With Emacs, I make my own rules and I dictate what makes sense. Most recent practical example? I just joined a team that uses Jira. Lots of people hate Jira (and for good reasons), in my case, I have no choice. So, instead of complaining how cumbersome and stupid Jira is, I decided to use it from Emacs. But instead of wasting time building a "native" extension, I just delegated things to go-jira - a command line client. Now, I can basically type 'FOO-31415' and Emacs automatically, contextually recognizes it as the 'jira ticket number', despite it being plain text. From that point I can retrieve its summary, turn it into a markdown link, browse the ticket, change its fields and status, etc. While anyone else have to waste their time opening Jira in the browser, I can perfectly do things without losing my focus, directly from my editor. That's working "with" software instead of letting software to fight "against" you.

bee_rider 2y ago

Doesn’t vim also have some ability, easily abused, to put a script at the top of a file, and it’ll just run when you open the thing? This seems like a really useful functionality to have in the context where you actually do trust the files, but it is wildly insecure and an unexpected trapdoor, to have simple files executing things when you open them with a simple text editor…

taeric 2y ago
Emacs has that, too. There are protections in that case, though. See: https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Sa... Probably going to add similar protections here? Basically, I'd assume if it is your first time visiting a file, macros won't be expanded during autocompletion.
- bee_rider 2y ago
  I dunno. I can see why this functionality might be useful, but I kinda think distros should disable it by default/make it whitelist-only. I think the implications are really unexpected for “new” users (where “new” could be pretty generously defined, I mean, I know a couple people who use vim IRL, I think they would not expect this… it is the sort of thing you know about if you are somebody who goes online to talk about text editors I think). And these are also the sort of users who are used to seeing shebangs and other line noise at the top of files, not understanding it, and ignoring it. I think we’re only being protected by the fact that spreading a virus though command-line text editors is… going to result in not a ton of hits.
  - taeric 2y ago
    I'm confused. Per the doc, it is disabled by default? Specifically, the first time it is encountered on a file, it will ask the user if they want to allow it. And they flat out don't ever do things like "eval" during these values.
magic_smoke_ee 2y ago
A common pitfall of IDE integration for dynamic languages is that it tends to execute the code under test to provide contextual completion or may decide to run doctests, etc. This has been/is a problem with editing Ruby code, and perhaps Python code and more too too. I'm unsure if this is a problem editing vimscript or lua with NeoVim with the only non-evidence is that I haven't heard of it.
hollerith 2y ago
That's a different potential vulnerability. I knew about that one (and had disabled the running of such scripts). I didn't know about this one till today. Helping me finish typing the name of a function or variable ("completion") is not the sort of thing I expected (till today) the maintainers of Emacs to be so eager to do that they'd start running code that I never asked to be run.
- lmz 2y ago
  It's that Lisp data is code, code is data thing.
  - hollerith 2y ago
    No, it is not.

uludag 2y ago

Giving the maintainers the benefit of the doubt, I think the optimal solution solution would require a lot of thought and work. While I have no doubt that Elisp is an environment especially ripe for these kinds of exploits, it's by no means unique to Emacs. Just look at VSCode's solution to this problem: https://code.visualstudio.com/docs/editor/workspace-trust https://code.visualstudio.com/docs/editor/workspace-trust .

hollerith 2y ago
I strongly prefer vscode's solution to the current state of affairs in Emacs.
- uludag 2y ago
  I have no doubt that VSCode has a much less risk of executing code by opening something. Ironically however, it seems that VSCode's extension is the most effective channel to distribute malware in the history of code editors. [1] [2] Not that MELPA couldn't be used to distribute malware either, I just think, as another poster mentioned, these problems are almost more social than technical. [1] https://www.bleepingcomputer.com/news/security/malicious-vscode-extensions-with-millions-of-installs-discovered/ https://www.bleepingcomputer.com/news/security/malicious-vsc... [2] https://arxiv.org/html/2411.07479v1 https://arxiv.org/html/2411.07479v1
  - alwayslikethis 2y ago
    If anything, Emacs users are probably much more likely to inspect the code of whatever extension they are using, since with every help page there is a link to the source code. It helps that it's much less popular and so not as big of a target.
    - deleted 2y ago
      [deleted]
- dietr1ch 2y ago
  Emacs is just too old to be architected with security in mind. It's a great editor, but has baggage that IMHO can't be addressed on the spot. Working on a codebase where you can't (heavily?) break things between any commit imposes such a slow pace that it's not completely unreasonable to start from the ground up and just study what made Emacs great and what didn't work too well. It's surprising how long Emacs has been around and how good of an editor it is. It really makes rewrite attempts such a long stretch that it exhausts the motivation and time out of spirited folks that give it a go, but I think that given how complexity is being modularised and moved out (LSP, DAP, grammars) and newer languages make packaging easier that Emacs will eventually be replaced, definitely without covering everything it can do, but being strong at the average editing session.

quotemstr 2y ago

You could also macroexpand in a sandbox, e.g. via LSP.

hollerith 2y ago
That would involve a rewrite because the way it is now, the relevant code does not use LSP.
- quotemstr 2y ago
  Okay, but software is infinitely malleable

throwanem 2y ago

I'm a lot less worried about this than I am about MELPA packages being targeted. But any other editor that incorporates a package manager exposes the same threat surface, and just about all of them are a lot more popular (thus more worth targeting) than Emacs.

SoftTalker 2y ago
Yes, it boils down to "be careful with untrusted code" no matter where it comes from. This is certainly not unique to emacs.
- EasyMark 2y ago
  I'm starting to get "return to notepad++" vibes from HN today.
  - SoftTalker 2y ago
    Well I use mostly stock emacs. If that's already owned, then I guess I'm screwed. I'm very selective about adding additional packages or using other "uninspected" elisp code.

_verandaguy 2y ago

The Church of Vim is always accepting new disciples. Jokes aside, if you're considering Vi-like editors (and assuming you haven't already done your research -- which by the sounds of it, you may well have): - I recommend going for Neovim over classic Vim at this point. The first-class Lua support for building out your configs and working with extensions is a big quality-of-life improvement over just VimL, and it's a more portable skill with fewer surprises. As a bonus, this gives you access to a world of shockingly high-quality extensions that require Lua to run. - If you want a decent starting point before you start tweaking a ton of settings, Spacevim is it. I haven't used it extensively but I've only heard good things. - I recommend against trying to use Emacs bindings in Vim if you can help it. I used these when I initially moved over (at this point about a decade ago) and they were clunkier than both Emacs's bindings and Vim's native bindings. Learning how to work with Vim's modes is an investment that pays off as quickly as a few days with intense use, or a few weeks with more casual use. - `vim-arpeggio` (or the native chording support in newer versions of Neovim) is your friend for avoiding `<Esc>`-induced repetitive-strain injury.

sevensor 2y ago
As a schismatic from the Church of Vim, I’m compelled to recommend kakoune here. Unless you’re running in a peculiar legacy platform like Windows or Amiga, the selection oriented editing and smooth Unix integration are a delight.
- samatman 2y ago
  I've considered it from time to time. The conclusion I keep drawing is that, if I were going to benefit from a selection-oriented editing paradigm, I would use Visual mode more than I do. The multi-cursors, those I want. But I'm willing to wait for Neovim to get them.
  - sevensor 2y ago
    That’s entirely reasonable; I switched in part because I was using visual mode so much. That being said, if you want a more vi-like experience in kakoune, you can always pipe your whole buffer through sed :)

nojs 2y ago

What are the other 5, out of curiosity?

nine_k 2y ago

It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited, should not be a lot of work, or at least doable. Disable it in your config, get a nerfed-down but shields-up elisp editing mode. Am I missing anything here? E.g. should I expect pieces of C code that handle completion in elisp mode?

chlorion 2y ago
Would you mind explaining how you could do this?
- nine_k 2y ago
  I expect that the entire mode is implemented in elisp-mode.el. It's based on lisp-data-mode, but I don't expect that to handle macros (should check though). Looking at elisp-completion-at-point and likely deeper into elisp--completion-local-symbols, I'd try to find where macroxpansion occurs, and make it conditional. Same for the explicit emacs-lisp-macroexpand. I would also search for `(eval ` in general and maybe put it under a buffer-local flag, too, so that you won't press C-x C-e or C-M-x and execute malicious code by mistake, when you know you're working on a piece of malicious code. Maybe instead of a defcustom, it should rather be a minor elisp-paranoid-mode which would do all kinds of things to prevent execution of the code in the buffer, or the code the buffer refers to, etc.
G3rn0ti 2y ago
> It looks like adding a defcustom that would disable macro expansion, and basically any attempts to eval the code being edited Probably, yes. „org-babel“ can execute shell code inside an org document but always asks the user before it does. You can disable this if you want to. No big deal. Should totally work like this in elisp-mode, too.

mfld 2y ago

Good call to prevent macro expansion. Does also no big harm nowadays as there are several other ways to get good auto completion, e.g. copilot. Other than that no need to restrict functionality for power users.

iLemming 2y ago

> 5 or 6 other signs that make me want to migrate away from Emacs. Sure, Emacs is not without deficiencies. But what are the alternatives? Name one option that can do things in the way that Emacs allows you to? Don't say 'Vim' - as a die-hard vimmer who uses both daily, I can confidently tell you - it may take decades until Vim becomes sufficiently good to replace Emacs for me. And if you say 'VSCode', I'd simply laugh coughing up org-mode structured headings.

dark-star 2y ago
sure, if you're looking for something that can perfectly replicate what Emacs does, then you'll never find an alternative... Every alternative has obvious shortcomings, at least on first glance, that you have to get used to. I have never used Emacs (other than briefly starting it up in the 90s, waiting 5 minutes for it to load on my old 386, just to be completely overwhelmed and closing it again) but I have used other tools that I replaced (sometimes multiple times) over the years. And it has never been "smooth". The first few days are full of compromises until you get into a mode of working "with" the new software instead of "against" it. Then it usually begins to make sense and after a week or two you've in business
- iLemming 2y ago
  Okay, but you know what? During my career as a software developer, I have wasted over a decade "getting used to" things being shitty, passively accepting mediocrity and suboptimal solutions. Learning Emacs (and Vim too) finally made me realize that I was doing things wrong - I needed to be in charge. As a computer programmer, I should be commanding software, not being constrained by it. Emacs has granted me that power by acting like glue. I don't turn away from useful software; I do use it. I just do it through Emacs, not instead. With Emacs, I make my own rules and I dictate what makes sense. Most recent practical example? I just joined a team that uses Jira. Lots of people hate Jira (and for good reasons), in my case, I have no choice. So, instead of complaining how cumbersome and stupid Jira is, I decided to use it from Emacs. But instead of wasting time building a "native" extension, I just delegated things to go-jira - a command line client. Now, I can basically type 'FOO-31415' and Emacs automatically, contextually recognizes it as the 'jira ticket number', despite it being plain text. From that point I can retrieve its summary, turn it into a markdown link, browse the ticket, change its fields and status, etc. While anyone else have to waste their time opening Jira in the browser, I can perfectly do things without losing my focus, directly from my editor. That's working "with" software instead of letting software to fight "against" you.