emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Thoughts on the standardization of Org
Date: Wed, 11 Nov 2020 11:00:54 +1100	[thread overview]
Message-ID: <87v9ecwymh.fsf@gmail.com> (raw)
In-Reply-To: <CA+G3_PPfNMdigwSBSmgJyKk4DNMYLmLYJVZSSOUUgwDPyyy+oA@mail.gmail.com>


Tom Gillespie <tgbugs@gmail.com> writes:

> 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!).
>

Another one, which I think is even a little more subtle, is table
formula evaluation. Using the advanced features of tables, you can
define a table that will automatically run formulas (which could be a
calc expression OR an elisp function) when you navigate through a table,
such as by hitting tab to move to the next column. I imagine this is
something you could easily do as tabbing through a table is a
convenient way to browse the contents.

While by default, org is pretty good, the real risk is that I suspect
many will have tweaked the evaluation settings - I know I have and while
I would not evaluate or export anything in an org file I was sent until
I had assessed it, mistakes do happen and I could easily hit C-c C-c in
the wrong context and cause a block to be evaluated without any
prompting for confirmation.

Given the complexities of dynamic content evaluation in org, perhaps a
simple solution would be to add a special MIME handler function which
would open an org file in a restricted mode, ignoring user settings
affecting code evaluation and preventing any form of evaluation, even if
the user asks for it. Basically, allow viewing, folding, navigation of
the org file, but no evaluation. If the user wants to export or tangle
or update tables etc, they would be forced to save the file and then
re-open it as a normal org file. It would be this handler function you
would configure in your MIME types as the function to run to view an org
attachment etc.

You could take it one step further an allow the definition of a 'tursted
senders' list. When opening an org attachment, this list is checked and
if the sender is in the list, normal org open process is applied,
otherwise the restricted MIME open function is applied. This would be
similar to the Gmail approach for handling images.

--
Tim Cross


  reply	other threads:[~2020-11-11  0:02 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
2020-11-11  0:00                       ` Tim Cross [this message]
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=87v9ecwymh.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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).