Re: Thoughts on the standardization of Org

[Tim Cross]

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