emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tom Gillespie <tgbugs@gmail.com>
To: Maxim Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Thoughts on the standardization of Org
Date: Tue, 10 Nov 2020 18:08:22 -0500	[thread overview]
Message-ID: <CA+G3_PPfNMdigwSBSmgJyKk4DNMYLmLYJVZSSOUUgwDPyyy+oA@mail.gmail.com> (raw)
In-Reply-To: <roeeio$ct7$1@ciao.gmane.io>

This is a great sub-thread that should probably be its own top level
thread on org security.

Org files are mostly benign unless the user does something extremely
dangerous like
setting enable-local-eval t. However, there are some areas where
arbitrary code can be
executed (as intended) that some users may not be aware of. Consider
the following.

#+begin_src elisp :var lol=(message "If I were evil I could use
call-process here to give you nasal demons")
#+end_src

When is the closure for the variable lol evaluated? The most obvious time is if
you run the block. The less obvious time is if you run org export!

More subtly.

#+name: some-block
#+begin_src elisp
#+end_src

#+call: some-block() :var pwnd=(message "oops!")

When will the closure for pwnd be called? When exporting it happens before
you receive the prompt asking whether you want to execute some-block!
Very easy to fool someone who doesn't know how top level closures work
into goofing on that one. Furthermore even when a file also sets

#+property: header-args :eval no-export

then the closure will still be evaluated!

Or how about

Running org export can execute arbitrary code even if you decline to run blocks
or set default header-args in your config. This means that it is not safe to,
for example, run a public server that transforms arbitrary org files into pdfs.

How about some more fun?

#+name: some-block
#+begin_src elisp :tangle ./itsatrap.el :dir (message "OH NO")
#+end_src

Yep. That does what you think it does. If you tangle the file, arbitrary code
execution. No tangling files from strangers either.

The examples I present here do require user input to fire off the process,
it won't happen without them doing something but it is much easier to
C-c C-e h h or C-c C-v t when you are an expert user, so you have to
be careful. Sharp tools.

Despite these examples, the ability to define values using arbitrary closures
is one of Org's most powerful features.

In the context of standardization, this suggests that it might be nice to
have a dynamic variable that controls whether bare closures will be
evaluated (one might already exist, I have no idea), along with a spec
that says what the failure modes should be if one is encountered that
cannot be evaluated.

In the context of org generally, maybe that variable could also be used like
org-confirm-babel-evaluate and take a function as an argument, ask if t, don't
ask if nil, or ask only if result is t (or was it nil ... regardless match
org-confirm-babel-evaluate). org-confirm-closure-evaluate maybe? (Again if
this already exists, then woo!).

Best!
Tom


  parent reply	other threads:[~2020-11-10 23:09 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01  0:22 Thoughts on the standardization of Org Asa Zeren
2020-11-01  0:40 ` Dr. Arne Babenhauserheide
2020-11-01  3:08   ` Asa Zeren
2020-11-01  4:23     ` Pankaj Jangid
2020-11-01  7:54     ` Tim Cross
2020-11-01  2:28 ` Tim Cross
2020-11-01  3:39   ` Pankaj Jangid
2020-11-02 12:39     ` Eric S Fraga
2020-11-02 14:22       ` Greg Minshall
2020-11-02 14:56         ` Eric S Fraga
2020-11-02 15:23           ` Russell Adams
2020-11-02 15:31             ` TEC
2020-11-02 15:48             ` Eric S Fraga
2020-11-02 16:27               ` Carsten Dominik
2020-11-02 22:05           ` Tim Cross
2020-11-03  3:29           ` Greg Minshall
2020-11-01  5:20 ` Tom Gillespie
2020-11-01 10:25   ` Dr. Arne Babenhauserheide
2020-11-01 10:28     ` TEC
2020-11-01 18:02       ` Jack Kamm
2020-11-01 16:03     ` Asa Zeren
2020-11-01 17:27       ` Dr. Arne Babenhauserheide
2020-11-01 17:29         ` TEC
2020-11-01 18:43         ` Asa Zeren
2020-11-01  6:24 ` TEC
2020-11-01 16:13 ` Russell Adams
2020-11-01 19:46   ` Daniele Nicolodi
2020-11-01 23:10     ` Dr. Arne Babenhauserheide
2020-11-02  8:37       ` Daniele Nicolodi
2020-11-02  9:02         ` TEC
2020-11-02 11:04           ` Daniele Nicolodi
2020-11-02 13:43             ` TEC
2020-11-07 21:20             ` Jean Louis
2020-11-09 14:04               ` Maxim Nikulin
2020-11-09 15:57                 ` Daniele Nicolodi
2020-11-09 15:59                 ` Jean Louis
2020-11-10 16:19                   ` Maxim Nikulin
2020-11-10 20:22                     ` Jean Louis
2020-11-10 23:08                     ` Tom Gillespie [this message]
2020-11-11  0:00                       ` Tim Cross
2020-11-09 21:46                 ` Tim Cross
2020-11-09 22:45                   ` Emails are not safe - " Jean Louis
2020-11-10  4:13                   ` Greg Minshall
2020-11-10  4:49                     ` Tim Cross
2020-11-10  7:12                       ` Greg Minshall
2020-11-10 16:29                     ` Maxim Nikulin
2020-11-10 20:35                       ` Jean Louis
2020-11-10 22:30                         ` Tim Cross
2020-11-11  5:03                           ` Jean Louis
2020-11-11  6:40                             ` Tim Cross
2020-11-27 16:49                             ` Maxim Nikulin
2020-11-27 17:16                               ` Jean Louis
2020-11-11 17:10                         ` Maxim Nikulin
2020-11-11 17:34                           ` Jean Louis
2020-11-12  3:39                             ` Greg Minshall
2020-11-11  3:49                       ` Greg Minshall
2020-11-02  9:53         ` Dr. Arne Babenhauserheide
2020-11-02  1:17 ` Ken Mankoff
2020-11-02  8:12   ` Russell Adams
2020-11-02  9:57     ` Dr. Arne Babenhauserheide
2020-11-03  8:24 ` David Rogers
2020-11-03 12:14   ` Ken Mankoff
2020-11-03 12:27     ` Russell Adams
2020-11-03 13:00     ` Eric S Fraga
2020-11-03 13:31       ` Ken Mankoff
2020-11-03 15:03         ` Eric S Fraga
2020-11-03 20:27           ` TEC
2020-11-03 14:38     ` Devin Prater
2020-11-03 22:03     ` David Rogers
  -- strict thread matches above, loose matches on Subject: below --
2020-11-01 13:34 Gustav Wikström
2020-11-01 18:39 Asa Zeren
2020-11-03 22:30 Asa Zeren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+G3_PPfNMdigwSBSmgJyKk4DNMYLmLYJVZSSOUUgwDPyyy+oA@mail.gmail.com \
    --to=tgbugs@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).