GNU bug report logs - #48676
Arbitrary code execution in Org export macros

Previous Next

To reply to this bug, email your comments to 48676 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: Arbitrary code execution in Org export macros
Date: Wed, 26 May 2021 11:52:04 -0400

Package: emacs,org-mode
Version: 28.0.50
Severity: important
Tags: security

emacs -Q hello.org, where hello.org contains:

#+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
Hello. {{{hello}}}

Then:
M-x org-export-dispatch
t A

-> now /tmp/HELLO exist, with no prompting.

This seems contrary to normal Emacs practice for risky local variables,
and to the section "Code Evaluation and Security Issues" in the Org manual
(which does not mention macros).

Message #6 received at 48676 <at> debbugs.gnu.org (full text, mbox):

From: Tom Gillespie <tgbugs <at> gmail.com>
To: Timothy <tecosaur <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 48676 <at> debbugs.gnu.org,
 emacs-orgmode <emacs-orgmode <at> gnu.org>
Subject: Re: bug#48676: Arbitrary code execution in Org export macros
Date: Wed, 26 May 2021 11:00:09 -0700

Hi Glenn,
     The definition for local variables doesn't cover things like org
macros, though the spirit of the policy is something worth keeping in
mind. Running M-x org-export-dispatch and hitting two keys means that
the user has to do something to trigger code execution, much like they
would have to intentionally accept certain risky local variables.

That said, the fact that many org operations can run arbitrary code is
definitely something that needs clearer documentation. It might make
sense to add a setting to detect closures that appear in org files to
ask for permission before running, but it likely should not be on by
default.

For a fairly extensive discussion of code execution in org see this
thread from Nov 2020.
https://orgmode.org/list/robi94$ma$1 <at> ciao.gmane.io/#t
Best,
Tom

Message #9 received at 48676 <at> debbugs.gnu.org (full text, mbox):

From: Timothy <tecosaur <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 48676 <at> debbugs.gnu.org, emacs-orgmode <at> gnu.org
Subject: Re: bug#48676: Arbitrary code execution in Org export macros
Date: Thu, 27 May 2021 01:07:27 +0800

Thanks for reporting this.

Glenn Morris <rgm <at> gnu.org> writes:

> This seems contrary to normal Emacs practice for risky local variables,

Hmm, correct me if I'm wrong but the issue with risky local variables is
that they affect Emacs before the user sees them in the file? If this is
an important distinction, it means this particular type of concern does
not apply to Org #+macro statements, as they are not executed when the
user opens the file.

That said, if one were making say an automated Org file exporter or
something, I could see this being problematic. Perhaps a var set to
allow macros by default could be a good idea.

> and to the section "Code Evaluation and Security Issues" in the Org manual
> (which does not mention macros).

Looks like this should be updated regardless of the above.

--
Timothy

Message #12 received at 48676 <at> debbugs.gnu.org (full text, mbox):

From: Greg Minshall <minshall <at> umich.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 48676 <at> debbugs.gnu.org
Subject: Re: bug#48676: Arbitrary code execution in Org export macros
Date: Thu, 27 May 2021 05:54:04 +0300

Glenn,

thanks for the report.

i guess my take is that macro-evaluation, and that of other forms,
should be subject to the same restrictions as that of source block
evaluation.  i.e., prompting for permission to execute, subject to
=org-confirm-babel-evaluate= (or, more specific variables).

cheers, Greg

> Package: emacs,org-mode
> Version: 28.0.50
> Severity: important
> Tags: security
> 
> emacs -Q hello.org, where hello.org contains:
> 
> #+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
> Hello. {{{hello}}}
> 
> Then:
> M-x org-export-dispatch
> t A
> 
> -> now /tmp/HELLO exist, with no prompting.
> 
> This seems contrary to normal Emacs practice for risky local variables,
> and to the section "Code Evaluation and Security Issues" in the Org manual
> (which does not mention macros).

Message #15 received at 48676 <at> debbugs.gnu.org (full text, mbox):

From: Rafael Ramirez Morales <rafael.ramirezmorales <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 48676 <at> debbugs.gnu.org
Subject: Re: bug#48676: Arbitrary code execution in Org export macros
Date: Thu, 27 May 2021 09:02:20 +0200

[Message part 1 (text/plain, inline)]

Just a couple of questions:
who is the owner of the HELLO file?
OR
who is the owner of the "touch" process?

Is the owner the unprivileged user or the "emacs" system?

Thanks.

On Wed, 26 May 2021 at 17:53, Glenn Morris <rgm <at> gnu.org> wrote:

> Package: emacs,org-mode
> Version: 28.0.50
> Severity: important
> Tags: security
>
> emacs -Q hello.org, where hello.org contains:
>
> #+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
> Hello. {{{hello}}}
>
> Then:
> M-x org-export-dispatch
> t A
>
> -> now /tmp/HELLO exist, with no prompting.
>
> This seems contrary to normal Emacs practice for risky local variables,
> and to the section "Code Evaluation and Security Issues" in the Org manual
> (which does not mention macros).
>
>

[Message part 2 (text/html, inline)]

Message #18 received at 48676 <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <mkupfer <at> alum.berkeley.edu>
To: 48676 <at> debbugs.gnu.org
Subject: Re: bug#48676: Arbitrary code execution in Org export macros
Date: Mon, 20 Jun 2022 17:37:30 -0700

I just verified that this issue is still present in Emacs master
(4ae315f7c3).

mike

Message #21 received at 48676 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: Glenn Morris <rgm <at> gnu.org>, 48676 <at> debbugs.gnu.org
Subject: Re: bug#48676: Arbitrary code execution in Org export macros
Date: Fri, 7 Feb 2025 14:11:45 -0800

Glenn Morris <rgm <at> gnu.org> writes:

> Package: emacs,org-mode
> Version: 28.0.50
> Severity: important
> Tags: security
>
> emacs -Q hello.org, where hello.org contains:
>
> #+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
> Hello. {{{hello}}}
>
> Then:
> M-x org-export-dispatch
> t A
>
> -> now /tmp/HELLO exist, with no prompting.
>
> This seems contrary to normal Emacs practice for risky local variables,
> and to the section "Code Evaluation and Security Issues" in the Org manual
> (which does not mention macros).

Ihor, could you please look into this bug?

Message #24 received at 48676 <at> debbugs.gnu.org (full text, mbox):

From: Max Nikulin <manikulin <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>,
 Ihor Radchenko <yantar92 <at> posteo.net>
Cc: Glenn Morris <rgm <at> gnu.org>, 48676 <at> debbugs.gnu.org
Subject: Re: bug#48676: Arbitrary code execution in Org export macros
Date: Sat, 8 Feb 2025 11:17:51 +0700

On 08/02/2025 05:11, Stefan Kangas wrote:
> Glenn Morris writes:
>> #+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
>> Hello. {{{hello}}}
>>
>> Then: M-x org-export-dispatch t A[...]> Ihor, could you please look into this bug?

Disclaimer: I am not Ihor.

In my opinion, it is an important, but not an urgent issue.

I do not see a way to unintentionally invoke export in default
configuration. It requires C-x C-e and a couple of extra keys
to select format. User can abort the process after accidental
starting export dispatcher. So this issue is less severe than
e.g. CVE-2024-53920 (indirectly related to bug#32495 completion
and bug#37656 flymake) when it is enough to open some file
to cause execution of embedded code.

I admit there are user configurations and some packages that
may add easy access binding e.g. to copy selection as HTML
or as MarkDown that run org-export under the hood.

Execution of code really may be surprising for novices,
but for experienced Org users it is a powerful feature.
I not mind that a warning related to macros may be added to
(info "(org) Code-Evaluation-Security")
and linked from (info "(org) Exporting") subsection
(info "(org) Macro-Replacement").

What may help to mitigate the issue is the recently introduced
`trusted-content' variable (that still may be renamed to
`macros-always-safe' or to something even more confusing).
Maybe more flexible settings should be implemented.
I expect, Glenn does not assume that `org-export'
should be affected by user options related to
(info "(emacs) File-Variables"),
and it was just an example of a similar approach.

There was an attempt to fix this kind of issues in Org.
Unfortunately a naive approach caused severe user inconvenience
and the changes were reverted. I am afraid, as a consequence,
some users even disabled existing protection related to `org-babel'.
I recall a discussion on the emacs-orgmode mailing list
how to manage degree of trust for specific Org mode documents.

I do not think it would harm to put eval macros behind
`trusted-content' when this variable is available,
but it would not be a complete fix. Org supports previous
Emacs releases.

Message #27 received at 48676 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 48676 <at> debbugs.gnu.org
Subject: Re: bug#48676: Arbitrary code execution in Org export macros
Date: Sat, 15 Mar 2025 17:36:20 +0000

Stefan Kangas <stefankangas <at> gmail.com> writes:

>> #+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
>> Hello. {{{hello}}}
>>
>> Then:
>> M-x org-export-dispatch
>> t A
>>
>> -> now /tmp/HELLO exist, with no prompting.
>>
>> This seems contrary to normal Emacs practice for risky local variables,
>> and to the section "Code Evaluation and Security Issues" in the Org manual
>> (which does not mention macros).
>
> Ihor, could you please look into this bug?

This is a known problem.
I do not see it as a bug (user needs to execute a command), but indeed
code evaluation control should eventually be improved. It should just be
designed properly.

See more discussion in https://list.orgmode.org/orgmode/87edsd5o89.fsf <at> localhost/

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.