Re: Emacs Arbitrary Code Execution and How to Avoid It

[Eshel Yaron <me@eshelyaron.com>]

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