Emacs Arbitrary Code Execution and How to Avoid It

Emacs Arbitrary Code Execution and How to Avoid It

[Christopher Howard]

Hi, I read the interesting write up here:

https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html

I wasn't terribly worried about this, as I don't *automatically* activate Flymake or Flycheck. But the article did mention that "code completion runs arbitrary code", and I was wondering more about that. I do not currently use Completion Preview mode. I have used Company in the past but company-mode is not currently activated. So, if I am just viewing an elisp file, i.e., not typing anything it in, nor running dabbrev commands, is there any danger? Should I setup Emacs to, by default, open all elisp files in View Mode?

Regarding dabbrev, I know dabbrev can search all buffers but I don't know if it does any macro expansion.

I was going to e-mail the author of the post, but cloudflare won't let me see his e-mail address.

-- 
📛 Christopher Howard
🚀 gemini://gem.librehacker.com
🌐 http://gem.librehacker.com

בראשית ברא אלהים את השמים ואת הארץ

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Gerd Möllmann]

Christopher Howard <christopher@librehacker.com> writes:

> Hi, I read the interesting write up here:
>
> https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html
>
> I wasn't terribly worried about this, as I don't *automatically*
> activate Flymake or Flycheck. But the article did mention that "code
> completion runs arbitrary code", and I was wondering more about that.
> I do not currently use Completion Preview mode. I have used Company in
> the past but company-mode is not currently activated. So, if I am just
> viewing an elisp file, i.e., not typing anything it in, nor running
> dabbrev commands, is there any danger? Should I setup Emacs to, by
> default, open all elisp files in View Mode?
>
> Regarding dabbrev, I know dabbrev can search all buffers but I don't know if it does any macro expansion.
>
> I was going to e-mail the author of the post, but cloudflare won't let me see his e-mail address.

There is an envelope icon in the top right (CC'd).

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Eshel Yaron]

Hi,

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Christopher Howard <christopher@librehacker.com> writes:
>
>> Hi, I read the interesting write up here:
>>
>> https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html
>>
>> I wasn't terribly worried about this, as I don't *automatically*
>> activate Flymake or Flycheck. But the article did mention that "code
>> completion runs arbitrary code", and I was wondering more about that.
>> I do not currently use Completion Preview mode. I have used Company in
>> the past but company-mode is not currently activated. So, if I am just
>> viewing an elisp file, i.e., not typing anything it in, nor running
>> dabbrev commands, is there any danger? 

Probably not, but this really depends on the specifics of your setup.
Namely, the "danger" comes from macro-expanding untrusted code, so if
you don't do anything that involves expanding macros, then you're fine.

Regarding completion in particular: ELisp mode adds a function
elisp-completion-at-point to completion-at-point-functions, so whatever
completion mechanism you use that runs completion-at-point-functions may
call elisp-completion-at-point.  Now, when elisp-completion-at-point
thinks that variable names are appropriate completion candidates at the
current position, it returns a completion table that, among other things,
expands macros when the completion mechanism queries it.  So it comes
down to whether or not you "trigger completion", and exactly where.
Again, which actions trigger completion and which don't depend on your
specific setup.

>> Should I setup Emacs to, by default, open all elisp files in View
>> Mode?

Not necessarily.  First, editing files that you control and/or trust
remains perfectly safe: no need to for such measures in you own config,
for example.  Second, you can trigger macro-expansion (and therefore run
into risk in case of a malicious file) even if you do enable View mode:
for example, the elisp-def package sometimes expands macros when you use
it to jump to a symbol's definition.

>> Regarding dabbrev, I know dabbrev can search all buffers but I don't know if it does any macro expansion.

I don't think dabbrev expands macros.


Best,

Eshel

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Jean Louis]

* Christopher Howard <christopher@librehacker.com> [2024-12-03 20:56]:
> Hi, I read the interesting write up here:
> 
> https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html
> 
> I wasn't terribly worried about this, as I don't *automatically* activate Flymake or Flycheck. But the article did mention that "code completion runs arbitrary code", and I was wondering more about that. I do not currently use Completion Preview mode. I have used Company in the past but company-mode is not currently activated. So, if I am just viewing an elisp file, i.e., not typing anything it in, nor running dabbrev commands, is there any danger? Should I setup Emacs to, by default, open all elisp files in View Mode?
> 
> Regarding dabbrev, I know dabbrev can search all buffers but I don't know if it does any macro expansion.
> 
> I was going to e-mail the author of the post, but cloudflare won't let me see his e-mail address.

In every programming language it is possible to obscure the code and execute arbitrary code.

I do not see it as special security issue, it is common, known.

-- 
Jean Louis

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Steven Allen]

Jean Louis <bugs@gnu.support> writes:
> In every programming language it is possible to obscure the code and execute arbitrary code.
>
> I do not see it as special security issue, it is common, known.
>
> -- 
> Jean Louis

Yes, but opening random text files shouldn't execute arbitrary code. The
concern here is that someone can:

1. Create some "document.txt" file.
2. Start it with ";; -*- mode: emacs-lisp -*-".
3. Include a macro that executes some malicious lisp code.
4. Send it to some unsuspecting victim.

Opening this file will run arbitrary code if flymake is enabled for
emacs-lisp files, even though the file looks like it should be an
innocent ".txt" file.

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Jean Louis]

* Steven Allen <steven@stebalien.com> [2024-12-04 18:05]:
> 
> Jean Louis <bugs@gnu.support> writes:
> > In every programming language it is possible to obscure the code and execute arbitrary code.
> >
> > I do not see it as special security issue, it is common, known.
> >
> > -- 
> > Jean Louis
> 
> Yes, but opening random text files shouldn't execute arbitrary code. The
> concern here is that someone can:
> 
> 1. Create some "document.txt" file.
> 2. Start it with ";; -*- mode: emacs-lisp -*-".
> 3. Include a macro that executes some malicious lisp code.
> 4. Send it to some unsuspecting victim.
> 
> Opening this file will run arbitrary code if flymake is enabled for
> emacs-lisp files, even though the file looks like it should be an
> innocent ".txt" file.

I get it, though similar concepts are in many editors. As you said,
"if flymake is enabled" which means that user enabling flymake should
get informed of it. There is myriad of packages that can be created,
so "if" they are enabled to do specific things on specific triggers
that does not constitute and serious "security hole". It is all
conditional, and there are many conditions that may provide an open
door for malicious friends to execute whatever code. It is anyway
coming by spam. It requires 21st century literacy to recognize
something is wrong. We talk hypothetically, so far there is zero
victims, nothing happened, no damage, just sensationalism.

-- 
Jean Louis

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Christopher Howard]

Jean Louis <bugs@gnu.support> writes:

> I get it, though similar concepts are in many editors. As you said,
> "if flymake is enabled" which means that user enabling flymake should
> get informed of it. There is myriad of packages that can be created,
> so "if" they are enabled to do specific things on specific triggers
> that does not constitute and serious "security hole". It is all
> conditional, and there are many conditions that may provide an open
> door for malicious friends to execute whatever code. It is anyway
> coming by spam. It requires 21st century literacy to recognize
> something is wrong. We talk hypothetically, so far there is zero
> victims, nothing happened, no damage, just sensationalism.

It seems like a "significant" concern, if maybe not a "serious" one. I highly doubt I would every be caught in this way by a spam e-mail attachment. But something I do very frequently is clone random repositories, including obscure new packages and advertised init.el code, and peruse through the elisp code with my Emacs editor. I don't think it is sensational to wonder about whether simply inspecting the code file (find-file) is going to allow for immediate code execution that could do things like delete my ssh keys or paste them to a bin Web site.

With directory local variables, there is a mechanism in place that asks you first if you want to apply the variables. So this sort of thing has been considered a valid concern.

Perhaps, at the moment, a vanilla Emacs setup does not trigger this, but it is something users should be aware of as they are considering various features to enable or install. If completion-preview-mode activates this, which is a built-in feature, that seems worthy of note. And maybe some mitigation could be programmed into Emacs — I'm not sure.

-- 
Christopher Howard

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This sounds like a grave problem, that we had better correct ASAP.
Can we reproduce it?  Can we see how it happens that Emacs
evals code that the user did not specifically say to eval?

Users writing Lisp code can cause any sort of vulnerability and it is
no use trying to prevent that.  But I think we should make sure that
no use of advertised features will eval code that the user did
specifically say to eval.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Did the person who posted this

    https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html

send us mail, or do anything to report the bug?
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Jim Porter]

On 12/5/2024 8:47 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> Did the person who posted this
> 
>      https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html
> 
> send us mail, or do anything to report the bug?

According to this message, Eshel had discussed this with Stefan Kangas 
privately (and possibly the other maintainers?) first: 
<https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00749.html>.

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 05 Dec 2024 23:47:10 -0500
> 
> Did the person who posted this
> 
>     https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html
> 
> send us mail, or do anything to report the bug?

Yes.

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 23:47:01 -0500
> 
> This sounds like a grave problem, that we had better correct ASAP.

A solution is in the works.

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Eli Zaretskii]

> Date: Thu, 5 Dec 2024 21:30:41 -0800
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 12/5/2024 8:47 PM, Richard Stallman wrote:
> > 
> > Did the person who posted this
> > 
> >      https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html
> > 
> > send us mail, or do anything to report the bug?
> 
> According to this message, Eshel had discussed this with Stefan Kangas 
> privately (and possibly the other maintainers?) first: 
> <https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00749.html>.

Yes.

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Did the person who posted this
>
>     https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html
>
> send us mail, or do anything to report the bug?

Yes, I saw <m1a5dltb04.fsf@macbookpro.home> on the mailing list a week
ago.

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I get it, though similar concepts are in many editors. As you said,
  > "if flymake is enabled" which means that user enabling flymake should
  > get informed of it.

I firmly disagree.  For Emacs to spontaneously execute code in files
that users did not say should be executed is simply unaccetable.
Warning users that this may happen is not sufficient -- we need to
_fix_ the problem.

I have never used Flymake, so I can't suggest, so I can't 
propose a fix that would seem reasonable ot users of Flymake.

But I think it should involve somehow explicitly specifying the
namss of all files that Flymaoe can treat as Elisp source to be
loaded automatically.  If a file has not been labeled that way,
Flymake should never spontaneously load any of that file.

WDPT?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks for sending a clear description of what leads up to the
failure.

  > Regarding completion in particular: ELisp mode adds a function
  > elisp-completion-at-point to completion-at-point-functions, so whatever
  > completion mechanism you use that runs completion-at-point-functions may
  > call elisp-completion-at-point.  Now, when elisp-completion-at-point
  > thinks that variable names are appropriate completion candidates at the
  > current position, it returns a completion table that, among other things,
  > expands macros when the completion mechanism queries it.

However, the crucial poiht seems not to be included.
It appears that something reads and evals macro definitions automatically.
Is that true?  If so, what triggers that -- and what fix can prevent it?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >     https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html
  > >
  > > send us mail, or do anything to report the bug?

  > Yes, I saw <m1a5dltb04.fsf@macbookpro.home> on the mailing list a week
  > ago.

I am glad that perse did the right thing.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > A solution is in the works.

Would you please post a brief summary of the planned fix?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
> Date: Sun, 08 Dec 2024 23:57:59 -0500
> 
>   > A solution is in the works.
> 
> Would you please post a brief summary of the planned fix?

I don't think it's wise to post that publicly, at least not yet.

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Daniel Radetsky]

On Fri, Dec 06, 2024 at 11:23:20PM -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I get it, though similar concepts are in many editors. As you said,
>   > "if flymake is enabled" which means that user enabling flymake should
>   > get informed of it.
>
> I firmly disagree.  For Emacs to spontaneously execute code in files
> that users did not say should be executed is simply unaccetable.

As I understand it, the issue is that the user has already
said "execute elisp code in any elisp-mode files," and that
it is common for the user to have said this. This is why the
reporter mentioned that popular emacs distros like doom
enable this behavior by default. I don't believe there was
any suggestion that vanilla emacs allowed this.

> Warning users that this may happen is not sufficient -- we need to
> _fix_ the problem.

If the user has already asked emacs to execute elisp, the
only thing that could IMO count as a fix is to _prevent_
them from doing this. Or at least to require that they
reconfirm that this is what they want when emacs wants to
execute the elisp, like with disabled commands.

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Eshel Yaron]

Hi,

Daniel Radetsky <dradetsky@gmail.com> writes:

> On Fri, Dec 06, 2024 at 11:23:20PM -0500, Richard Stallman wrote:
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > I get it, though similar concepts are in many editors. As you said,
>>   > "if flymake is enabled" which means that user enabling flymake should
>>   > get informed of it.
>>
>> I firmly disagree.  For Emacs to spontaneously execute code in files
>> that users did not say should be executed is simply unaccetable.
>
> As I understand it, the issue is that the user has already
> said "execute elisp code in any elisp-mode files," and that
> it is common for the user to have said this. 

That's not quite right.  Users do not say "execute arbitrary ELisp in
any elisp-mode buffer".  They often say something like "diagnose issues
(e.g. with Flymake) in all such buffers".  The fact that this feature
involves arbitrary code execution is a security defect, not a necessity.
Moreover, Emacs never mentions (in the docs, warnings, or otherwise)
that using this feature comes with the risk of arbitrary code execution.

> This is why the reporter mentioned that popular emacs distros like
> doom enable this behavior by default. I don't believe there was any
> suggestion that vanilla emacs allowed this.

Not exactly: even in "vanilla" emacs -Q, macro expansion is unsafe, and
important features rely on macro expansion.  emacs -Q is only safer in
the sense that it doesn't enable these important features automatically.
But they remain important for anybody that actually wants to use Emacs
to edit ELisp.

>> Warning users that this may happen is not sufficient -- we need to
>> _fix_ the problem.
>
> If the user has already asked emacs to execute elisp, the
> only thing that could IMO count as a fix is to _prevent_
> them from doing this. Or at least to require that they
> reconfirm that this is what they want when emacs wants to
> execute the elisp, like with disabled commands.

Emacs could (and should) facilitate safe macro expansion, so features
that require macro expansion could carry on without exposing the user to
such hazards.

Safe macro expansion means restricting the set of things that macros can
do (sandboxing), such as denying network access.

For example, SWI-Prolog has a nice safe mode for executing untrusted
code, see https://www.swi-prolog.org/pldoc/doc/_SWI_/library/sandbox.pl


Best,

Eshel

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Jean Louis]

* Eshel Yaron <me@eshelyaron.com> [2024-12-11 11:37]:
> That's not quite right.  Users do not say "execute arbitrary ELisp in
> any elisp-mode buffer".  They often say something like "diagnose issues
> (e.g. with Flymake) in all such buffers".  The fact that this feature
> involves arbitrary code execution is a security defect, not a necessity.
> Moreover, Emacs never mentions (in the docs, warnings, or otherwise)
> that using this feature comes with the risk of arbitrary code execution.

Send me the working example of dangerous macro, that I can see how it
works, thank you. Make 

-- 
Jean Louis

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Daniel Radetsky]

On Wed, Dec 11, 2024 at 12:25:24PM +0300, Jean Louis wrote:
> Send me the working example of dangerous macro, that I can see how it
> works, thank you. Make

(rx (eval (call-process "touch" nil nil nil "/tmp/owned")))

see also:

https://eshelyaron.com/posts/2024-11-27-emacs-aritrary-code-execution-and-how-to-avoid-it.html

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Jean Louis]

* Daniel Radetsky <dradetsky@gmail.com> [2024-12-11 12:37]:
> On Wed, Dec 11, 2024 at 12:25:24PM +0300, Jean Louis wrote:
> > Send me the working example of dangerous macro, that I can see how it
> > works, thank you. Make
> 
> (rx (eval (call-process "touch" nil nil nil "/tmp/owned")))

I see it executes and makes the file by opening ex.el with the
above. It doesn't work with .txt file though.

I hope there are no toher issues like that.

-- 
Jean Louis

Re: Emacs Arbitrary Code Execution and How to Avoid It

[tomas]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On Wed, Dec 11, 2024 at 01:38:44PM +0300, Jean Louis wrote:
> * Daniel Radetsky <dradetsky@gmail.com> [2024-12-11 12:37]:
> > On Wed, Dec 11, 2024 at 12:25:24PM +0300, Jean Louis wrote:
> > > Send me the working example of dangerous macro, that I can see how it
> > > works, thank you. Make
> > 
> > (rx (eval (call-process "touch" nil nil nil "/tmp/owned")))
> 
> I see it executes and makes the file by opening ex.el with the
> above. It doesn't work with .txt file though.

Believing in "file extensions" is yet another recipe for disaster
(remember those ".jpg.exe"?

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Daniel Radetsky]

On Wed, Dec 11, 2024 at 01:38:44PM +0300, Jean Louis wrote:
> I see it executes and makes the file by opening ex.el with the
> above. It doesn't work with .txt file though.

;; -*- emacs-lisp -*-

Re: Emacs Arbitrary Code Execution and How to Avoid It

[tomas]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

On Wed, Dec 11, 2024 at 04:50:41AM -0800, Daniel Radetsky wrote:
> On Wed, Dec 11, 2024 at 01:38:44PM +0300, Jean Louis wrote:
> > I see it executes and makes the file by opening ex.el with the
> > above. It doesn't work with .txt file though.
> 
> ;; -*- emacs-lisp -*-

What I said :)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > As I understand it, the issue is that the user has already
  > said "execute elisp code in any elisp-mode files," 

Does the user literallky say that. or does the user say something
different which you _interpret_ as _tentamount_ to saying that?

It makes a big difference here.

  > If the user has already asked emacs to execute elisp, the
  > only thing that could IMO count as a fix is to _prevent_
  > them from doing this.

Preventng this is the sort of fix I have in mind.  But I have not yet
come across a message explaining precisely what user actions activate
that behavior.  Until I learn that, I won't fully understand the
issue.  I asked for that info, and I hope I soon come across a
response.

But it looks like this conequence came as a surprse.  So I think we
did not anticipate, when adding the feture, that it would have this
effect.  We did not intentinally add the feature as a way for users to
say, "Go ahead and randomly execute Elisp code from any of my visited
files."

If we actually want to offer a command by which the user says to
execute unpredictably parts of whatever Elisp files get visited, Emacs
should warn per that "this is dangerous" and ask per to confirm with
`yes'.  We should not let users risk stumbling into this mode without
knowing what care they will have to take in this mode.

But even wth understanding, it would be unwise to accept.  Everyone
who uses Emacs and looks at Emacs Lisp code will occasionally visit a
file of Elisp code which is _not_ part of per own work.  So even if
perse wants this feature for all of a certain project, perse could
fall into a trap by enabling it for _all_ Elisp files that are
visited.

THis leads me to think of settig up a more selective interface
whereby you would enable this for source files of a specific project.

Maybe that would give enough control that it could be safe and yet
still convenient.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs Arbitrary Code Execution and How to Avoid It

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2024-12-12 07:48]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > As I understand it, the issue is that the user has already
>   > said "execute elisp code in any elisp-mode files," 
> 
> Does the user literallky say that. or does the user say something
> different which you _interpret_ as _tentamount_ to saying that?
> 
> It makes a big difference here.

I was first under impression that such user would be aware of it, but
after reviewing Flymake, no, user will not be aware of it.

Even though condition would rarely happen, Flymake purpose is to
verify Emacs Lisp programming for correctness, I don't think many
would be verifying other people's files for correctness, normally
one's own files.

Though the problem may exist in other packages as well. It should
simple be disabled.

Jean Louis