Re: Thoughts on the standardization of Org

[Jean Louis <bugs@gnu.support>]

* Maxim Nikulin <manikulin@gmail.com> [2020-11-10 19:22]:
> > * Maxim Nikulin [2020-11-09 17:06]:
> > > 2020-11-08 Jean Louis wrote:
> > > > That is right, I am using it since years in ~/.mailcap that works well
> > > > for mutt email client.
> > > > 
> > > > text/org;	emacsclient %s; nametemplate=%s.org;
> > > > text/x-org;	emacsclient %s; nametemplate=%s.org;
> > > 
> > > Just for curiosity, couldn't it lead to execution of arbitrary code
> > > placed into elisp table expressions, some macro, etc.?
> 
> My question is solely concerning content of an org file. Let's assume
> default emacs and org mode settings or customization that does not bring
> more weakness.
> 
> I consider an attack through content of an org file obtained from network.
> It may be a message from a person even from usual contact list whose
> computer was infected by some malware. Imagine that botnet developers would
> notice new RFC on org mode and would add a plugin capable to add specific
> payload (fetching and launching its agent using elisp) if org files noticed
> in the host owner mailbox. I would not like to see org next to office files
> in security warnings.
> 
> The reason why I am afraid to add emacs as a MIME handler for org files is
> the following. Nowadays vim is shipped with disabled (at least by default)
> modeline that was used to specify e.g. tab width for the particular file,
> but it allows to change too much settings. After skimming through the org
> manual, my impression is that org mode allows to override a lot of settings
> through "#+setup:" and other directives. I do not have a solid notion
> related to all possibilities to inject elisp code so I am not sure that no
> elisp code embedded into received file is executed during opening of the
> file without any user action.

Quite understandable and I appreciate your awareness on safe
computing.

That question is solved when there is clear answer if anything gets
executed automatically from #+SETUP line when opening an Org file.

‘#+SETUPFILE: file’
     The setup file or a URL pointing to such file is for additional
     in-buffer settings.  Org loads this file and parses it for any
     settings in it only when Org opens the main file.  If URL is
     specified, the contents are downloaded and stored in a temporary
     file cache.  ‘C-c C-c’ on the settings line parses and loads the
     file, and also resets the temporary file cache.  Org also parses
     and loads the document during normal exporting process.  Org parses
     the contents of this document as if it was included in the buffer.
     It can be another Org file.  To visit the file—not a URL—use ‘C-c
     '’ while point is on the line with the file name.

I have tried to execute file by using:

#+SETUPFILE: ~/tmp/message-me.el in Org file and:

message-me.el:
(message "I have been executed.")

But I did not see message executing. 

> Viewing received file I would prefer a restricted mode at least to avoid
> obviously dangerous actions:
> - C-c C-c for src blocks

See file local variables in manual. They can also be dangerous and
unsafe. Emacs is environment with programming language and executing
many things is possible when user desires so.

Safety of files should be decided from viewpoint of what Emacs does by
default

Question is if anything would be executed by default when Org file is
opening?

> I could miss some possibilities to activate arbitrary code. Just
> speculations, maybe such options are safe without modification of init.el:
> custom link handlers, dynamic blocks, column view.

As activating any code is not by default and is left to user, there is
no need to prevent that generally.

You are aware that it can be executed if you invoke some key presses,
so you can control it by not invoking it or by inspecting it before
invoking it.

> There was a thread concerning "security considerations" section of RFC
> discussing if the similar section of MarkDown document is suitable for org.
> My impression that org is much more complex.

Org is much more complex.

Of course there are ways how some markdown implementations could
execute external programs. Markdown is meant to create HTML. It was
not meant originally to share information directly in Markdown and yet
people do it.

We just need to make sure that nothing by default executes when any
Org file is opened and that is it.

> My worries if arbitrary code could be executed during just opening
> of a file are not directly related to standardization. However I do
> not think that argument on low attack probability due to negligible
> popularity is appropriate in the thread with discussion that
> standardization could make org more wide spread.

Emacs allows any file-local-variables in any type of a document. Then
it asks user if user would like to accept such variables or not:

Hypothetical and untested example:

> Local Variables:
> compile-command: "rm -rf ~/*"
> End:

Many users may not know what "rm -rf ~/*" mean and would say
Y. Automated or hidden attack on many users could be initiated by
implementing a shiny theme, making it popular and having few banal
variables to be accepted, and later introducing change that: captures
users' private information, passwords, contact address book for
spamming or similar. rm -rf would be too obvious. It could download
backdoor shell and have attacker browse files.

> I do not see why it is relevant. Joking colleagues and angry students is
> another attack vector. Mail reader and emacs almost certainly have
> privileges to put something to user's autostart. Passwords are not involved.
> What could help is running a dedicated emacs used as MIME handler inside a
> container with restrictive mount and network namespaces.

chroot, jails (BSD), or running program over shell in other user space
could be possibilites. See example how DragonflyBSD author recommends
how to run browser safely:

How to Run a More Secure Browser
https://www.dragonflybsd.org/docs/handbook/RunSecureBrowser/

> > For the same reason one shall be cautious of any packages coming from
> > various popular package repositories as such are not verified for
> > safety issues.
> 
> I would prefer to not touch the subject of degree of trust in respect to
> external packages. Let's limit the scope to org "core", maybe even as a part
> of emacs distribution.

I am getting you fully.